WPF中材质制作——图片和矢量图之争

如果要做下面这样的一个东西作为背景。你会如何做呢？



图
1. 目标背景效果

方案一，用
PS画出来。然后把这个
PNG图片作为背景色。这个方案可以，但是如果想让这个线的颜色可配置呢？如何线的粗细不确定呢？无论哪个问题，用像素图的方式都不好
解决。

方案二，用
WPF的矢量图绘制。这个方案可以比较容易地解决上面两
个问题。

但是无论我们用哪种方式，都不会把整个图的大小画出来。而是画是一个最小的图元，然后重复。
标量图方案

对于
PS画的标量而言，有下面这样的一个图就可以了。然后在要绘制
的区域内无限重复。尤其是做网页的上的材质都是这样，要知道图片的大小可不是比文字，全部绘制出来的话图片可能会很大。而且
Visual
Designer改起来也会比较累。



图
2. PNG材质图片（放大后）

比如这个图叫
Twill.png，大小是
6*6。那么在
WPF中使用这个图元来建立图
1中材质的代码如下。

<

DrawingBrush

x

:

Key

="PicTwillBrush"

Stretch
="Fill"
TileMode
="Tile"

Viewport
="0,0,6,6"
ViewportUnits
="Absolute">

<

DrawingBrush.Drawing

>

<

ImageDrawing

ImageSource

="Textures/Twill.png"

Rect

="0,0,6,6"/>

</

DrawingBrush.Drawing

>

</

DrawingBrush

>

默认情况下，这个用方案一实现的材质很完美，和图
1完美一样。但是
如果用
ViewBox把这个图片放下之后会出现下面的现象。



图
3. 实现渲染效果（
ViewBox放大）

能看出图片已经是一块块的了。你可以把这个看作
WPF的
Bug。如果我是
QA我就会这么认为。虽然我也很理解这是平滑处理
+TitleMode渲染的结果——平滑算法没有把这个大图当成整个的一个图处理，而是单独地处理每一小块。但是我也相信这不是什么难以解决的问题。
所以它就是一个
Bug，没有什么好说的。只不过这是个小
Bug，不
Fix也就算了（因为有其它更严重的
Bug等着
MS的
Dev们），反正
有办法解决的。

一个不完全解决方案，可以使这个分块的视觉效果弱化
50.00%。
就是把图元改成这个样子。



图
4. 更好的
PNG材质

不一定是一块俩像素，一块
4个像素。不过两者个数之差越小越好。所
以最好是两条
3像素的线。然后视觉图会变成下面这个样子。



图
5. 显示效果（
ViewBox放大）

比之前要好一些。至于原因读者自己分析一下吧。（包括那个
50.00%是
如何计算出来的）

所以有经验的材质设计者，即使能用简单的角衔接，也不会用，而只使用边衔接。（当然他们主要并不是为了这个原因）

上面讨论完了位图的作法。如果你的图片不需要支持缩放，而且又不嫌
PNG占用空间大的话，用
PNG图片还是很不错的方案的。

矢量图的实现方案

有人会觉得在
WPF做个矢量图太简单了。不就是用
Expression
Design画么？对，没有错，但是问题你要画成什么个样子？因为矢量图的画法就多了。矢量的一个特点就是，图像不
再是以像素为单位的。而是一个完完整整的图形。我的第一感觉是这样的。（也许你的不是）



图
6. 向量材质图（根本不可行）

有人可能一眼就看出问题了，这种做法里，线的两头不是方的。多个这样的小图接起来，线看上去也不会是连续的。解决办法
和标量图的是一样的。就是使用边衔接。把图中的一条线分成两条。下面是两条做法。请读者自行判断哪种更好，并解释原因。





图
7. 可选向量材质图

上图的代码分别是：

<

StreamGeometry

x:Key

=

"SimpleTwill
">
M3,0 L4,0 0,4 0,3 Z M3,6 L4,6 6,4 6,3 Z</
StreamGeometry
>

和

<

StreamGeometry

x:Key

=

"BestTwill
">
M2.5,0 L3.5,0 0,3.5 0,2.5Z M2.5,6 L3.5,6 6,3.5
6,2.5 Z</
StreamGeometry
>

如果一开始你是用
Expression Design来画这个东
西，相信代码一定不会这么简洁的。
Expression Design最让人不能忍受的就是生成出来的
数据，常常有
1.00001这样的东西。

对应的
Brush代码是：

<

DrawingBrush

x:Key

=

"SimpleTwillBrush">

Stretch

=

"Fill
"
TileMode
=
"Tile
"

Viewport

=

"0,0,6,6
"
ViewportUnits
=
"Absolute
">

<

DrawingBrush.Drawing

>

<

GeometryDrawing

Brush

=

"Red
"
Geometry
=
"{StaticResource SimpleTwill}
"/>

</

DrawingBrush.Drawing

>

</

DrawingBrush

>

但是无论向量图自身的定义是多么的“平滑”，不幸的是它最终还是要被渲染到以像素为单位的显示器上。更不幸的是，由于
向量图的定义一般不与显示器的像素格匹配，所以在渲染的过程中，势必要做处理。结果渲染出来的就是下面这个熊样了。



图
8. 向量材质渲染效果

最上面一条是期望的效果，下面两条就分别是由那两个向量图元定义出来的渲染效果。如果看不清楚，下面是他们俩的放大
图。（请读者自行判断上面的结果分别是基于哪个向量图元绘制的）



图
9. 向量材质渲染效果（放大图）

从图中可以看出，最终的渲染结果没有对齐到像素，严格来讲就是渲染结果不正确。（顺便说一下，请不要提
SnapsToDevicePixels这个属性，如果你觉得这个属性可以解决这个问题，只说明你还没有搞清楚这个属性是在什么时候发挥作用的。其实即使我这样说了，我
感觉还是会有人回复说要用这个属性，因为他们没有认真看文章。）
关于向量图的性能问题

而且，向量没有对齐到像素的另一个严重问题就是性能。这个性能差异用肉眼就可以看得出来。如果你拖拽窗口，会发布由上
面这两个向量渲染出来的背景在闪。（此测试方法理论上只在低配置系统上可行。）为什么会闪，因为它比对齐到像素的方式至少多计算
1倍的像素点，而且每个像素点的颜色都要重新计算一遍。这个计算量是很大的。

所以很多用
WPF做过开发的人，会发现如果直接用
Design绘制出来的复杂向量图做整个程序的背景，程序就会变得很卡，如果先转成
PNG之
类的图片，再用图片做背景，性能就会好得多。原因就在于此。使用向量，每个像素点的信息都要重新计算出来。而使用图片，如果图片大小和背景大小一样，则只
需要原模原样地把图片上的像素信息搬到显示器上就行了，不需要计算什么。

但是这并不能说向量图就一定性能低下。如果能把向量图，做得与像素点能对应起来，向量图也一样可以具有很好的性能。比
如上面的向量图闪，如果我们把向量图定义成下面这个样子就不会闪了。
高性能向量图方案



图
10. 像素对齐的向量材质图

这个向量的定义需要更多的代码，如下所示：

<

StreamGeometry

x:Key

=

"PixelTwill
">
M0,2 L1,2 1,3 0,3 Z M1,1 L2,1 2,2 1,2 z M2,0
L3,0 3,1 2,1 Z M3,5 L4,5 4,6 3,6 Z M4,4 L5,4 5,5 4,5 Z M5,3 L6,3 6,4 5,4
Z</
StreamGeometry
>

虽然看上去代码更多了，但是由于它对齐到了像素点，所以其实性能更好。根据肉眼观测，完全看不到闪烁现象。

但是这样的向量图已经失去了向量图的意义了，向量图的一个重点特点就是无极缩放。放大之后图像依然平滑。但是这个向量
图其实就和一个标量图的效果是一样的了——放大之后就会有锯齿出现。但是如果一个向量图不会放大，用这样方式还是很不错，既提前了性能，又保证了图像的清
晰、锐利。但是这样做的成本很高，做个小图还可以，做个大图就很不现实了。
图片模糊

无论是标量图还是矢量图，实现项目中常常会出现模糊。下一篇将会为大家介绍几种常见的导致模糊的情况和解决办法。

源地址：http://www.cnblogs.com/nankezhis ...
exturesolution.html