WPF 3.5 中的抗锯齿不一致
我在使用 FluidKit 的 ElementFlow 控件的 WPF 应用程序中遇到奇怪的别名行为。我们在工作中使用应用程序中的控件来呈现内容，当 ElementFlow 的元素倾斜时，边缘别名如下图所示： 
为了避免锯齿，我们决定摆脱倾斜角度，所以我创建了一个快速测试应用程序，我将倾斜角度、项目间隙和弹出距离绑定到滑块，这样我就可以找出看起来最好的。
然而，在使用相同设置的测试应用程序中，边缘很好地消除了锯齿： 
我假设 XAML 层次结构中的某处有一些设置正在控制这一点，但我我尝试过在设计时和运行时（使用绑定和 Snoop 等工具）在各种元素和样式上设置 SnapsToDevicePixels ，但均无济于事。
ElementFlow 的 XAML 如下：
<ListView.ItemsPanel>
<ItemsPanelTemplate>
<Fluid:ElementFlow
x:Name="ContentElementFlow"
SelectedIndex="{Binding SelectedIndex}"
Focusable="True"
TiltAngle="15.95"
ItemGap="0.722"
FrontItemGap="0.052"
PopoutDistance="1.631"
HasReflection="False"
Background="Transparent"
CurrentView="{StaticResource CoverFlowView}"
ElementWidth="175"
ElementHeight="250"
>
<Fluid:ElementFlow.Camera>
<PerspectiveCamera
FieldOfView="60"
Position="0,0,6"
LookDirection="0,0,-6"
UpDirection="0,1,0"
/>
</Fluid:ElementFlow.Camera>
</Fluid:ElementFlow>
</ItemsPanelTemplate>
</ListView.ItemsPanel>
我还在两台不同的计算机上尝试了这两个应用程序（一台运行 XP Pro，一台运行 XP Embedded，两者都有不同级别的专用图形），并且都在一个应用程序中演示了锯齿，在一个应用程序中演示了抗锯齿功能。另一个。
有谁知道可用于控制此问题的任何设置或 XAML 属性？
I am getting strange aliasing behaviour in a WPF app using FluidKit's ElementFlow control. We are using the control in an app at work for presenting content, and when the elements of the ElementFlow are tilted, the edges alias as per the following image:
In order to avoid the aliasing, we decided to get rid of the tilt angle, so I created a quick test app where I bound the tilt angle, item gaps, and popout distance to sliders so I could find out what looked best.
However, in the test app using the same settings, the edges are nicely anti-aliased:
I am assuming there is some setting somewhere up the XAML hierarchy that is controlling this but I've tried setting SnapsToDevicePixels on various elements and styles, both at design time and run time (with bindings and tools like Snoop) to no avail.
The XAML for the ElementFlow is as follows:
<ListView.ItemsPanel>
<ItemsPanelTemplate>
<Fluid:ElementFlow
x:Name="ContentElementFlow"
SelectedIndex="{Binding SelectedIndex}"
Focusable="True"
TiltAngle="15.95"
ItemGap="0.722"
FrontItemGap="0.052"
PopoutDistance="1.631"
HasReflection="False"
Background="Transparent"
CurrentView="{StaticResource CoverFlowView}"
ElementWidth="175"
ElementHeight="250"
>
<Fluid:ElementFlow.Camera>
<PerspectiveCamera
FieldOfView="60"
Position="0,0,6"
LookDirection="0,0,-6"
UpDirection="0,1,0"
/>
</Fluid:ElementFlow.Camera>
</Fluid:ElementFlow>
</ItemsPanelTemplate>
</ListView.ItemsPanel>
I've also tried both apps on two different machines (one running XP Pro, one XP Embedded, both have differing levels of dedicated graphics) and both demonstrate aliasing in one app and anti-aliasing in the other.
Does anyone know of any setting or XAML attribute that can be used to control this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
微软金融服务公司 (MSFT) 的布伦丹·克拉克 (Brendan Clark) 表示：
您是否尝试过为 ElementHeight 设置不同的值？
Brendan Clark from MSFT says:
Have you tried to set different values to ElementHeight?
如果我没记错的话，WPF 3.5 中有一个关于这种情况下的别名的错误，我一生都找不到相关信息，但据我所知，这是一个 Direct X 标志，WPF 没有正确设置。
我记得发现如果将有问题的元素包装在某些类型的父元素中，似乎可以解决问题。例如，我认为将有问题的元素包装在空边框中可以解决问题吗？再说一次，我一生都无法再次找到这些信息，但如果我找到它，我会更新我的答案。
我认为您在应用程序之间看到的差异与此有关。在显示别名的应用程序中，ItemTemplate 中的项目是否包装在某种父元素中（而测试应用程序则不是）？或者反之亦然？
抱歉，我无法提供更多帮助，仍在寻找信息，但今天我的 Google 能力似乎很弱。
更新：好吧，我找到了我的想法。
http://social .msdn.microsoft.com/Forums/en-US/wpf/thread/7382637b-b4bc-4a46-8bed-f36250a65385/
这与效果有关，所以也许这与您看到的不是同一件事，但值得一枪。
If I remember correctly there is a bug in WPF 3.5 regarding aliasing in this scenario, I can't for the life of me find the relevant information, but from what I remember it was a Direct X flag that was not being set correctly by WPF.
I remember finding that if you wrap the offending element in certain types of parent elements it seemed to fix the problem. For instance I think wrapping the offending element in an empty border fixes the problem? Again, I can't for the life of me find the information again, but if I find it I will update my answer.
I assume the differences you are seeing between applications are related to this. In the app that show aliasing are the items in the ItemTemplate wrapped in some sort of parent element (where as the test app they are not)? Or vice-a-versa?
Sorry I can't be of more help, still looking for the information but my Google powers seem weak today.
UPDATE: Ok I found what I was thinking of.
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/7382637b-b4bc-4a46-8bed-f36250a65385/
This was related to effects so maybe this isn't the same thing you are seeing but worth a shot.
需要考虑的一件事是 ElementFlow 控件的位置。如果它的排列矩形不在整个像素上，则可能会破坏所有内容。 SnapToDevicePixels 不会帮助排列矩形。
当您使用 TextBlock 时，通常会发生这种情况，因为它们的高度/宽度通常不是整数。
在 .NET 4 中，有一个新的 FrameworkElement.UseLayoutRounding 解决了这个问题。
One thing to consider is the location of the ElementFlow control. If it's arrange rect isn't on a whole pixel, that may throw off everything. SnapToDevicePixels will not help with the arrange rect.
This generally happens when you use TextBlocks, since their heights/widths are generally not whole numbers.
In .NET 4, there is a new FrameworkElement.UseLayoutRounding that fixes this issue.
这是 WPF 3D 的常见问题。 FluidKit 的 ElementFlow 使用 WPF 3D。控件中的项目是实际的 3D 对象（Viewport3D、ContainerUIElement3D）。子像素渲染问题、LayoutRounding 和 SnapToDevicePixels 不适用于 3D 内容。当性能不正常时，WPF 会恢复为别名 Viewport3D 内容。因此，您有问题的应用程序很可能消耗了太多资源（CPU、GPU、内存）。根据我的经验，这种情况在 Windows XP 下发生的频率比 Vista/Windows 7 下要高得多。对于 Windows XP，设置 抗锯齿注册表项。除了提高应用程序的性能之外，您无能为力。
This a common problem of WPF 3D. FluidKit's ElementFlow uses WPF 3D. The items in the control are acutal 3D objects (Viewport3D, ContainerUIElement3D). Subpixel rendering issues, LayoutRounding and SnapToDevicePixels do not apply to 3D content. WPF reverts to aliased Viewport3D content when the performance is not right. So most likeley your problematic app is consuming too much resources (CPU, GPU, memory). I have made the experience that this happens much more freqeuntly under windows XP than under Vista/Windows 7. For Windows XP it helps a bit to set the antialiasing registry key. Other than that and improving the perfomance of your app, there is not much more you can do about it.