Does exist a ddraw "performance tester"?

[nadir2102]

Hi Narzoul, for unknown reasons I find myself with a strange slow playback even without the use of your ddraw.dll. I probably have a global problem with the operating system or with the graphics card, something that is not right with the current version of windows 10. Do you have a tester program that measures the performance of use of ddraw? in my case I need to playback video files that have HD resolution: 1920x1080 - 25 fps. If possible I'm looking for a program-tester that tell me if the general performance of the machine is ok or not for use ddraw, thanks

[nadir2102]

however I reboot machine and now all seems run well, maybe only a defaiance of windows build 1602

Sorry Narzoul .. be patient: referring to ddraw.dll v. 0.2.0 "b" that you kindly have give me

ddraw.zip the one with this diff diff.txt

can I ask you if is there a way to build the same thing but with a different V-SYNC (?) method? or with others method of playback which affect the "fluidity" of reproduction. Summarily the playback seems fine, seems flowing fluid but in some moments it seems almost, in a very slight way, to have little "bounce" that may be confused in the the screen. So I need to understand if is there a way to test other type of "scan", always if your ddraw.dll supports these changes. THANKS A LOT

[narzoul]

For windowed mode apps I don't think you'll find any tools that can measure presentation performance because it can't be measured in a generic way. Windowed mode DirectDraw applications can't use page flipping so they present directly on the screen via blits or locks and they can use many of those per "frame". There is no external way of telling where a frame begins or ends, only the app itself knows.

As for fluidity of windowed presentation in DDrawCompat, there's definitely an issue that I've noticed myself as well (e.g. with Unreal in windowed mode), but I have only recently been able to fix it in the experimental version. However, backporting that to v0.2.0b is far from trivial and I generally don't have time to spend on maintaining old versions. I hardly have enough time even for developing the latest one. Just take a look at the open issues list, most of them are more than a year old and I still haven't got around to fixing them.

[nadir2102]

I thank you anyway and I hope the experimental version may be born soon, compatibly with your commitments. If possible with a configuration file that allows to enable or disable the various options so as to mediate the complexity of adaptation necessary to the various different programs.

In any case, I'd be curious to know how using different Graphics Cards, programs that use ddraw are supported or not? I have a laptop HP Envy J113EL (year 2013) with a INTEL 4600HD graphic card that fully support my program that use ddraw and all works well without any "adapters" such this fantastic DDraw Compat that you have developed. My actual laptop that have an nVidia GTX1060 - a graphics card with certainly not modest performances - seems don't support (at least in terms of graphic quality) programs that use DirecDraw: why this? Nevertheless a old graphic card nVidia GT 640 on Windows XP (and ONLY on XP) allows programs that use directdraw to work well in performance and quality, the same GT640 on Windows 7 - 8 and 10 have bad quality. So what is the problem: nVidia don't want to keep the compatibility with "old" programs? Microsoft don't have afraid for old programs? Or strange different reasons? many many thanks

[narzoul]

There are a couple of differences between Windows version and drivers with respect to DirectDraw that I'm aware of:

• Windows XP uses a different driver model than Vista and above. XP still had direct driver support from vendors for DirectDraw while Vista+ uses a unified Direct3D 9 driver for all versions of DirectX graphics up to Direct3D 9 (including DirectDraw).
• DirectDraw doesn't specify the stretching mode used for blits, so drivers are free to choose whatever method they like, with the most common ones probably being either point filtering (simple pixel duplication/elimination, looks more "jagged") or bilinear filtering (smoother, but gets blurrier as the stretch factor increases).
• Locking surfaces for direct CPU access is usually a lot slower on modern systems, though I'm not sure how much of that depends on the hardware, the driver and the version of Windows. Some DirectDraw applications use a lot of surface locking, especially in full-screen mode.
• Vista introduces a desktop compositor (DWM) so direct access to the screen in windowed mode is now usually redirected to off-screen window textures, sometimes via GDI operations, which could be responsible for some quality and performance differences as well. DWM can still be disabled on Windows Vista and 7 however, so you could experiment with that to see if it makes a difference.
• Starting with Windows 8.1, color depths lower than 32 bits are no longer supported natively, so those display modes are emulated by Windows, often at a significant performance loss.
• Most full-screen DirectDraw applications actually run in windowed mode (since Windows 8?) by default which can reduce performance as well.

[nadir2102]

I understand but at this point, hoping not to abuse your patience, I would ask you if in your version of direcdraw.dll (in my case the variant 0.2.0b) in consideration of the fact that some modern graphic cards are able to handle a great complexity of computation - in hypothesis - would it be possible to relieve (unburden) the CPU from the load and discharge this work to the GPU?

For example, see my case

44% CPU and "only" 20% GPU

In hypothesis can the ddraw controls and decide to get the GPU working at 90% instead and in place of the CPU ? thank you

[narzoul]

In general, no. It's not a simple flip of a switch. Especially if the application uses its own "software rendering" implementation then there is no way to change that to GPU rendering without rewriting the application itself to use some hardware accelerated API (like Direct3D).

For simple 2D stuff, forcing all surfaces to be created in video memory might speed up some blits but it could also slow down accesses via locks (including GDI access). It's usually not necessary anyway because 2D is often fast enough even when using CPU only. For example, I was able to run Icewind Dale at 4k resolution entirely on the CPU without any noticeable performance issues. And in the above case, based on the logs you sent me the application itself already creates all surfaces in video memory so nothing further could be gained.

I think 20% is not so strange, 2D rendering isn't really GPU intensive. For the CPU usage, the parts that consume most of the CPU time are probably not related to rendering, but rather to other video processing code (like decoding the video) which most likely can't be done with DirectDraw.