「玩一玩」换个思路更简单：方便好用的文字描边效果实现方法

最近做的玩意儿走的是艺术路线，大量底图，文字不容易看清，所以需要描边效果。但是网上搜了一圈，都没有让我满意的，于是自己实现。在做的时候，想到能不能用最简单的谁都会的方法来做，于是有感而发，写了这篇帖子，大家一起探讨。

© 版权所有 野比 2012

当我们需要在色彩丰富的图片上显示文字的时候，由于背景色变化的关系，文字往往不能清晰呈现。就像很多早期电影使用纯白色字幕，在蓝天白云的画面下常常看不清楚字幕。这时候，我们就需要文字描边这种能够突出显示文字的效果了，就像这样。



（动画截图 by Wong Shao Voon）

 那么，怎样实现这样的效果呢？下面我粗略介绍下目前常见的几种方法。最后介绍我构思的一种简单而实用的实现方法。
一般方法
第一种思路：文字即图片
 1.将TextBlock 转换为WriteableBitmap
 2.对WriteableBitmap 的Pixels 进行循环,判断每一个像素点的值最终达到描边的效果。
参考《Silverlight字体描边》
野比点评：
这种思路将文字转为图片，根据判断图片上每个像素点，效率低下，最终效果简单，如下图所示。


第二种思路：像素着色器
该方法基本思路为：假定只会对TextBlock应用像素着色器，那么TextBlock是一个矩形，文字所在像素的 alpha分量必定大于0,否则必定是透明像素。判断如果当前像素的上，下，左，右任意一个像素不透明，则说明本像素需要被描边，否则就输出文字颜色。由于需要知道相邻像素，所以还需要传入TextBlock的ActualWidth和ActualHeight。 这样， 当前位置的 x+ 1/width 就是相邻像素的坐标，就可以用tex2D函数来提取它的颜色值。还需要输入描边的颜色，还有文字的颜色。
参考《SILVERLIGHT像素着色器编写简明指南 附送文字描边效果》
野比点评：
仍然是一个「大炮打蚊子」的思路，将文字进行逐像素的处理。和思路1唯一的区别在于使用了像素着色器，让把部分工作交给GPU来完成，「看起来」很高效很快速。但是如果禁用了硬件加速呢？就变成和1一样了。下面是该方法的效果截图。


第三种思路：GDI+路径绘图
这种方法不再是逐像素处理了。其基本思路是将文字字符串添加到GDI+的绘图路径中（GraphicsPath），然后再DrawPath()。利用不同的笔刷，这种方法可以「画」出非常华丽的描边效果，就像这样。


野比点评：
这是扩展性最好的方法。由于利用了GDI+的高级特性，所以可以利用不同的笔刷如纹理、渐变，以及多次绘图等方法做出非常精美的描边、阴影等效果。唯一的遗憾就是代码量较大（比前面2种要少很多了）。
参考文章《C# 水印图片+文字描边+发光文字。看示图及Demo》
关于该方法的高级效果设计，参考《Outline Text》一文（Code Project「Best C++/MFC article of Sep 2009」比赛获奖文章）。

野比的简易方法
又到了野比的偷懒时间。
看了前面几种设计思路后，你有没有一头雾水的感觉？或者眼花缭乱的感觉？难道我们只有这样实现吗？需要「描边」文字，就一定要「描」吗？
其实完全没有必要。曾经我在山寨Safari时，介绍过一种简单的通过重复绘制文字实现高光效果的方法（参见《一步一步玩控件：TabControl——从制作山寨Safari窗体开始》）。
如下图所示。当底层文字和顶层文字相差1px时，就会呈现出不同的阴影/高光效果。那么我们如果把这个思路拓展下，把上、下、左、右四个方向的偏差结合到一起，就会像下图最后显示的效果一样，得到了「描边」文字的效果。

接下来在GDI+里面实现它。

C# code

// Code by Conmajia
     // txtPoint是绘制文字的定位点
     txtPoint.Offset(-1, 0);  // 绘制左背景文字
     e.Graphics.DrawString(this.Text, this.Font, backBrush, txtPoint);
     txtPoint.Offset(2, 0);  // 绘制右背景文字
     e.Graphics.DrawString(this.Text, this.Font, backBrush, txtPoint);
     txtPoint.Offset(-1, -1);  // 绘制下背景文字
     e.Graphics.DrawString(this.Text, this.Font, backBrush, txtPoint);
     txtPoint.Offset(0, 2);  // 绘制上背景文字
     e.Graphics.DrawString(this.Text, this.Font, backBrush, txtPoint);
     txtPoint.Offset(0, -1);  // 定位点归位
 
     // 绘制前景文字
     e.Graphics.DrawString(this.Text, this.Font, foreBrush, txtPoint);

下面请欣赏效果


结语
这篇文字，重点不在于技术，而是如何简单方便的在我们能力范围之内实现我们想要的效果。
这两天在网上看到有「高手」数落新人没用标准架构标准技术标准手法，有感而发。
比如一个C#新手，他/她也许刚接触C#，学了一点点GDI+，现在就需要做描边文字。但是他/她根本还没学到什么Shader、什么GraphicsPath这样的高级内容，你觉得该怎么办？
我的信条是，让标准流「滚他奶奶的蛋」，在实用主义的道路上，没有所谓的「标准做法」。谁说的一定要把边描出来？谁说的一定要多线程？谁说的一定要三层？只要我做出来，只要「看起来和用起来」没问题，谁会管你具体怎么实现的啊，你以为用户也是程序猿，还要看你源代码啊？骚年，省省别2了吧
很多时候，我们遇到问题，不需要完全跟着问题走。就像这次，我们需要「描边」，但谁说的，我们非得要「描」边呢？我们要的只是效果，而不是过程，所以要跳出问题表象的禁锢，就能获得更加宽广的视野。
© 版权所有 野比 2012
（全文完）


以上蓝字内容很冲，最近感染了喷子病毒。。标准流鄙视流请尽情的喷吧，让我甘拜下风。

------解决方案--------------------
其实我觉得，图比文字好看
------解决方案--------------------
你好像是因为“效率”问题而放弃前两种处理方法的。但是绘4次文字，不知道你对效率测试过没有。最好有个测试数据。如果数据上证明你只能这样写，那么当然可以这样写。其实不一定是别人都让你钻到套套里，说不定是你自己最没有信心才会先入为主地自嘲这种方式是野路子。

wpf/slverlight等都不是基于gdi+的，所以你的方法没有吻合.net最近5年的界面编程技术发展方向。
------解决方案--------------------
如果是在老式的winform、gdi+中编程，那么就没有什么可说的了。如果是在wpf/silverlgiht中编程，当然要使用Effect。

而且，我们不仅仅是显示一种TextBlock，随便说比如HyperLinkButton等等，都需要描边的。
------解决方案--------------------
很好的思路
------解决方案--------------------

探讨