Windows mobile 或 CE 设备上的 GDI 性能
我有一个 Windows CE 应用程序，它使用大量矢量图形，并且有时速度相当慢。 我目前正在使用 GDI 通过位图进行渲染，以实现无闪烁刷新。 通常，我会查看大型 3D 地图的一部分。 在某些设备（例如 166mhz SH4）上，对于大数据集，刷新时间会变慢，刷新时间为 3-5 秒。 我的问题是这样的；
有人对 Windows mobile 和 Win32 上图形操作的相对速度进行过比较吗？ 换句话说，假设我们只查看 GDI 调用，则适用于 WinCE 版本的 Win32 版本软件的分析结果。
是否有人尝试过在 WinCE 平台（C++ 应用程序）上进行机上分析，如果是，使用什么工具。
是否有谁知道有什么方法可以提高 Windows CE 上的绘图速度。 我目前正在根据上一个问题的反馈查看FastGraph，但这是一个稍微长期的解决方案。 糟糕的是，尽管如此，我正在为即将发布的版本寻找更快的实现方法。
I have a Windows CE application that uses a lot of vector graphics and in places is quite slow. I'm currently using GDI for rendering via a bitmap for flicker free refreshes. Typically, I'm windowing in on part of a large 3d map. On some devices (e.g. 166mhz SH4), this gets slow with 3-5 second refresh times for big datasets. My question is this;
Has anyone done any comparisons on the relative speed of graphic operations on Windows mobile versus Win32. Put another way, are profiling results from a Win32 version of the software applicable to a WinCE version, assuming we are only looking a GDI calls.
Has anyone tried profiling onboard on a WinCE platform (C++ app), if yes, using what tools.
Is anyone aware of any methods to improve drawing speed on Windows CE. I'm currently looking at FastGraph following feedback from a previous question, but this is a slightly longer term solution. Bad and all as it is, I'm looking for something faster to implement for an upcoming release.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 Windows CE 6.0 之前（因此包括所有 Windows Mobile/Windows Embedded Handheld 版本），图形代码是在另一个进程 (GWES.EXE) 中实现的，每次进行 GDI 调用时都需要跨进程调用。 CE 5.x 跨进程调用比桌面上便宜得多，但仍然比普通函数调用或内核模式调用昂贵。
在桌面上，GDI从NT 4.0开始以内核模式实现。 在最初的NT 3.1中，它就像CE模型一样，跨进程调用。 为了减轻跨进程调用或用户/内核模式切换的开销，桌面 GDI 会在用户模式端批量操作，直到您执行需要刷新队列的操作 - 例如选择不同的笔或画笔，或使用一个返回除
BOOL以外的内容的旧函数 - 或者缓冲区已满，或者您通过调用GdiFlush显式刷新它。Windows CE 不具备这种批处理功能 - 所有调用都会导致对 GWES 进程的直接调用，从而使其速度慢很多。 您可以通过在每次调用中执行尽可能多的工作来缓解这种情况。 如果您需要复杂的线，请考虑 Polyline 而不是单独的 MoveToEx/LineTo 调用。 尝试只触摸每个像素一次，而不是渲染重叠的对象，并利用无效区域仅绘制需要重新绘制的屏幕部分（使用
GetUpdateRgn或GetUpdateRect但在调用BeginPaint之前执行此操作，这标志着该区域有效）。CE 图形加速模型相当基础，基于位块传输。 它不支持 Windows 2000 型号桌面设备驱动程序支持的更多功能。 是否提供加速取决于硬件是否具有加速器芯片 - 许多设备将使用嵌入在应用处理器中的 LCD 控制器，该控制器通常不进行任何加速。
您可以通过禁用批处理来模拟 CE 在桌面上的行为，使用 GdiSetBatchLimit 将限制设置为 1。还可以考虑使用 SVGA 图形驱动程序来禁用加速。 在 Windows Vista 或 Windows 7 上，如果您使用 Aero 环境，则 GDI 不会加速，所有操作都在软件中实现，尽管 Windows 7 添加了一些新的位块传输硬件加速功能。
Windows CE 6.0有一个新的内核和进程模型，它将GDI移动到内核模式，就像桌面Windows（Vista之前）一样，因此调用GDI函数的成本应该会稍微降低。 仍然没有批处理。
Before Windows CE 6.0 - therefore including all Windows Mobile/Windows Embedded Handheld versions - the graphics code was implemented in another process (GWES.EXE), requiring a cross-process call every time you make a GDI call. CE 5.x cross-process calls are much cheaper than on the desktop, but still more expensive than a plain function call or a call into kernel mode.
On the desktop, GDI is implemented in kernel mode since NT 4.0. In the original NT 3.1, it was like the CE model, cross-process calls. To mitigate the overhead of cross-process calls or user/kernel mode switches, desktop GDI batches up operations on the user-mode side until you do something that requires it to flush the queue - like selecting a different pen or brush, or using one of the legacy functions that returns something other than
BOOL- or the buffer is full, or you explicitly flush it by callingGdiFlush.Windows CE does not have this batching capability - all calls result in a direct call to the GWES process, making it a lot slower. You can mitigate it by doing as much work as possible in each call. If you need a complex line, consider Polyline rather than individual MoveToEx/LineTo calls. Try to only touch each pixel once rather than rendering overlapping objects, and make use of the invalid region to only paint parts of the screen that need repainting (use
GetUpdateRgnorGetUpdateRectbut do it before callingBeginPaint, which marks the region valid).The CE graphics acceleration model is fairly basic, being based around bit-blits. It doesn't support the larger set of capabilities that Windows 2000-model desktop device drivers support. Whether any acceleration is available depends on whether the hardware even has an accelerator chip - many devices will use the LCD controller embedded in the application processor, which usually doesn't do any acceleration.
You can simulate CE's behaviour on the desktop by disabling batching, using
GdiSetBatchLimitto set the limit to 1. Also consider using the SVGA graphics driver to disable acceleration. On Windows Vista or Windows 7, GDI is not accelerated if you're using the Aero environment, all operations are implemented in software, although Windows 7 added back some new bit-blit hardware acceleration capabilities.Windows CE 6.0 has a new kernel and process model, which moves GDI into kernel mode as on desktop Windows (before Vista), so the cost of calling a GDI function should be slightly reduced. There is still no batching.
我对图形方面的知识不多，但从经验来看，如果你想在某些特定硬件相关的事情上快速进行，那么越接近“金属”，你就能获得越快（并且变得越难！ ）。 因此，您可以考虑使用 Direct Draw 或 Direct 3D（尽管我认为他们正在放弃 D3D 并转向 WM7 的 OpenGL ES） 。 您可能想了解游戏开发人员使用的方式。
关于配置文件的问题，我还没有找到任何配置文件，但我确实构建了我的
I don't have a lot of knowledge of the graphics side of things but from experience, if you want to be fast at some specific hardware related things, the closer to "metal" the faster you can get (and the harder it gets!). So you could look into using Direct Draw or Direct 3D (altho I think they are dropping D3D and going over to OpenGL ES for WM7). You may like to look into way Game Developers use.
On the question of Profiles, I haven't found any but I do build my own.
我已经做了很多这样的基准测试，GDI 操作在 WinCE 上比常规 Win32 慢，但只是与 WinCE 设备上较慢的处理器成比例。 换句话说，在 WinCE 中使用 GDI 似乎不会对性能造成任何额外的影响。
抱歉，我无法回答您最后两个问题。
I've done a lot of this kind of benchmarking, and GDI operations are slower on WinCE than regular Win32, but only slower in proportion to the slower processors on WinCE devices. In other words, there doesn't seem to be any additional performance hit from using GDI in WinCE.
Sorry, I don't have answers to your last two questions.