基于WPF矢量的界面 [英] WPF Vector based interface
问题描述
我正在使用WPF开发新的C＃应用程序。我的印象是WPF是基于矢量的，并且文本/按钮将以与分辨率无关的方式绘制。运行我的应用程序时，很明显，没有使用矢量绘制我的应用程序。一些文本变得相当块状，使用Windows放大镜时，您可以看到所有物体上的粗糙边缘。
我的应用程序中需要做一些特别的事情吗？打开矢量绘图？还是我的特定机器有问题？ （我正在使用最新的图形驱动程序运行Windows Vista x64）
我打算将此添加为注释，但是我希望它能被正确引用和注脚。
Windows Vista中的Mangifier可访问性工具 使用 可以感知WPF。如果缩放WPF内容，您会看到该应用程序的放大版本-表明WPF实际上是基于矢量的。
Tim Sneath是Microsoft的技术宣传人员，，解释说放大镜不再具有此技巧。放大镜将专门检测WPF应用程序，并知道如何要求它们进行缩放。他们消除了对WPF的依赖。似乎放大镜依赖于WPF中他们想带走或贬低的东西：
bp和约瑟夫·库尼'已经
注意到使用内置操作系统
放大镜放大WPF
内容不再解析
内容的独立缩放。
该观察是正确的。
由于一系列变化
太多，无法在此处描述
，因此OS放大镜不再是
了 WPF感知，并且像其他内容一样进行位图缩放
。
尽管我们确实失去了此功能，但我们
认为，如果没有使放大镜以
WPF特定方式工作的依赖项
，我们可以更加灵活地使用
请注意，以上只是 个，大约
-过程放大。当
在您自己的WPF应用程序中进行
缩放（通过缩放）时，
渲染将继续以更高的比例重新栅格化
，因此
一切都保留了在大多数
常见场景中都比较顺利。严格来说，此更改是
，是关于使用外部
放大镜的。
因此，放大镜以前曾经拥有它，但是不再。
在第9频道的视频 Greg Schechter：Windows Presentation Foundation（WPF）体系结构，Greg Schechter谈到了放大镜如何用于提供此功能。
放大镜和DWM一起工作。放大镜修改了DWM场景图，以使其客户区域实际上指向场景图的桌面根。 DWM然后知道了放大镜，并且知道如何避免那种可怕的将摄像机对准显示摄像机的电视效果。
修改：2018年9月7日。来自 Ian Griffiths的答案：
在Vista首次发布时以及WPF在3.0版上，使用内置放大镜进行
缩放实际上会基于矢量进行
缩放。
当WPF 3.5 Service Pack 1出厂时，它停止工作。 （它在sp1之前在3.5中的
起作用。）在此之前起作用的原因是DWM
（桌面窗口管理器）-Windows的一部分，负责
呈现您在屏幕上看到的所有内容-使用MILCORE.DLL进行
渲染。 WPF的3.0和3.5版本也使用相同的组件进行
渲染-这意味着所有WPF内容都是本机内容，因此对于
而言。 （实际上，在没有DWM的Windows XP上，
MILCORE.DLL是WPF为了自己的
利益而放入系统中的东西。但它内置在Vista和Windows 7中。）当WPF使用
MILCORE.DLL在Vista上进行渲染时，DWM施加的任何效果（例如
缩放）也将以您想要的WPF方式应用-实际上，
缩放确实没有像素化
不幸的是，情况不再如此。原因是WPF
开始添加新的渲染功能。在3.5 sp1中，
问题中的新功能是对自定义像素着色器的支持。为此，Microsoft
必须发布MIL的更新。 （媒体集成
层-完成实际渲染的位。）但是，它们并不是真正可以更新MILCORE.DLL的
位置，因为这是
Windows的一部分-您在屏幕上看到的所有内容如何显示在屏幕上。
发行新版本的MILCORE.DLL实际上意味着向Windows推出
更新。 Windows的发布时间表与.NET的发布时间表无关，因此WPF团队可以合理地添加新功能的唯一方法是发布新的MIL。 （从理论上讲，他们可以通过Windows Update来完成
的操作，但是由于WPF现在由Microsoft的
部门与Windows属于不同的
部门，这种情况似乎不会在
中发生
从.NET 3.5 sp1开始，MIL位于另一个名为
wpf_gfx_vXXXX.dll的DLL中，其中vXXXX是版本号。在.NET 4.0中，它是
wpf_gfx_v0400.dll。
好处是WPF会为每个
新版本添加新的呈现功能，而无需需要Windows本身进行更新。
的缺点是WPF的渲染不再像Vista刚推出时那样短暂地与Windows紧密集成。如您所见，放大后的
并不像以前的
那样有趣。
I'm working on a new C# application using WPF. I was under the impression that WPF was vector based and that text/buttons would be drawn in a resolution independent way. When running my application it’s fairly obvious that my application isn’t being drawn using vectors. Some of the text gets fairly blocky, and when using the windows magnifying glass you can see rough edges on everything.
Is there something special I need to do in my application to turn vector drawing on? Or is something wrong with my specific machine? (I'm running Windows Vista x64 with the latest graphics drivers)
i was going to add this as a comment, but i want it to be properly quoted and footnoted.
The Mangifier accessibility tool in Windows Vista used to be WPF aware. If you zoomed WPF content you would see a sharp magnified version of the app - demonstrating that WPF is indeed vector based.
Tim Sneath, a technology evanglist with Microsoft, blogged about this in 2006:
6/25/2011: Original image gone. Replaced with another image showing same effect.
Greg Schechter answers some commenters on this blog, explaining that magnifier no longer has this trick. Magnifier would specially detect WPF applications, and know how to ask them to render themselves scaled. They removed a dependancy on WPF in magnifier. It seems that magnifier had a dependancy on something in WPF that they wanted to take away or depricate:
Both 'bp' and 'Joseph Cooney' have noticed that magnification of WPF content using the built in OS Magnifier no longer does resolution independent zoom of content.
That observation is correct.
As a result of a series of changes that are too numerous to describe here, the OS magnifier is no longer "WPF-aware", and does bitmap scaling just like it does of other content. Although we do lose this feature, we believe that without the dependencies that enabled Magnifier to work in a WPF-specific way, we can be more agile in what we provide to WPF customers moving forward.
Note that the above is only about out-of-process magnification. When you do zooming (via scaling) within your own WPF application, the rendering continues to be re-rasterized at the higher scale, so everything remains smooth in that most common scenario. This change is strictly about using the external magnifier.
So the magnifier used to have it, but no longer.
In the the Channel 9 video "Greg Schechter: Windows Presentation Foundation(WPF) Architecture", Greg Schechter talked about how Magnifier used to provide this functionality.
Magnifier and DWM worked together. Magnifier modified the DWM scene graph to make it's client area actually point to the desktop root of the scene graph. DWM then knew the magnifier was there and knew how to avoid that horrible "pointing a camcorder at a television showing the camcorder" effect.
Edit: 9/7/2018. From Ian Griffiths' answer:
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
这篇关于基于WPF矢量的界面的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
