GetPixel calls slow under Aero?
Folks,
I've been working with a 3rd party skinning API called The Ultimate Toolbox... and have noticed that rendering menus is incredibly slow under Aero... but everything runs fine under Classic theme. I narrowed the problem down to ::GetPixel() which is VERY, VERY slow. I created an MFC commandline app to prove this... walking 100 pixels through GetPixel took 4-6 seconds under Aero.. but milliseconds under Classic Theme in Vista 2 Beta.
Does this sound familiar to anoyone? I'm running an nVidia Quadro NVS 285.. with the latest beta drivers.
Any help would be greatly appreciated. The code I'm working with actually does the GetPixel off a HDC from the Desktop.
Thanks.
-Jeff
Yes, this is expected. Reading back from the screen is considerably more expensive when desktop composition is enabled (as with the Aero theme) than when it is not (as in Classic). If you can avoid readback altogether, that's best. Per-pixel transparent (layered) windows are very fast when the desktop compositor is running, compared to Classic, so that's a better way to achieve blending, if that's what you are trying to achieve, though I realize you are using a library over which you may not have control. If you truly must read from the screen, doing it in large chunks will be much better than one pixel at a time, because the extra cost of the readback is largely per call, not per pixel. Calling GetPixel in a tight loop is the worst case scenario, I'm afraid.
Thanks for the reply Leonardo.
Hmm... that's pretty unfortunate that there's this backwards incompatibility with Aero. Is this something that will be fixed before the final product? .. or just one of the issues that developers will have to deal with moving forward?
I have the source code for the library.. and unfortunately, it is calling GetPixel in a very tight loop. Bummer.
-Jeff
We've done our best to preserve functional compatibility, so your app will look the same as it always has. We are also still doing a lot of tuning, so you can expect performance improvements, but we won't be able to reach performance parity for screen read-back, and reading pixel-by-pixel is really about the worst-case scenario.
The ultimate, last-resort measure for applications that absolutely rely on this functionality and can't be modified is to turn off the composition engine for the duration of the running of the app, which can be done by the app itself with an API call or via the compatibility UI in the property pages for the app. So even those apps will work well in Vista if they are so marked, although unfortunately they won't be able to get glass frames or participate in Flip 3D.
i am also comming with the problem.
though i need only 64 pixel to get ,it works under Aero ca. 6s,but without Aero it need only 1~2 ms
With Aero enabled, Windows doesn't need to maintain an actual bitmap of the display. It simply maintains polygons that hold individual window contents and lets the compositor handle mixing them in the correct way. As soon as you make a call to GetPixel, it is forced into rendering all the windows into a single bitmap so that it can figure out what colour that pixel is. Doing this is always going to be very, very slow in comparison.
As mentioned above, the best thing to do is use layered windows if you need per-pixel transparancy as that is blindingly fast with the DWM enabled and no slower than the getpixel method if it isn't. If that isn't an option, then you can always force the DWM to shut down via the API, though that's not a particularly elegant approach.
