Investigate d3d9 GDI overhead with >2005 (< ?) directx sdks

[mirh]

Follows #164 (comment) and assuming d3dx is even something that you (can) care.
It turns out that my weird observation is the result of a directx sdk change. Up until the december 2005 version, I get the high numbers.
Starting with the one from february 2006 (not sure about the latest, but still) I'm getting half if not even less the framerate.
Under wine, there is still a nominal difference, but it's leaps and bounds lower.

This is the breakdown of the sample internals:

While this is the stack for every one of those d3dx9_29.dll calls

Is there something that could (and should) be done to avoid this?

[elishacloud]

Sorry for the delay in responding. I think what is probably happening is what is outlined here that the "game uses GetDC to obtain a DC to draw on multiple times per frame. Since each such use requires locking the surface for CPU access, the performance overhead could be significant."

I have seen this issue already with one Direct3D7 game called Arx Fatalis. For dd7to9 I already added the same solution that DDrawCompat has to "caches a CPU side copy of video memory surfaces, so repeated locks have no extra overhead unless the GPU also writes to the surface in between."

This issue could happen with any Direct Draw or Direct3D game all the way up to DX9. I only put the shadow caching into the dd7to9 feature. But I could add this to the Direct3D9 wrapper. This would allow it to work with dd7to9, d3d8to9 and Direct3D9 games.