PixelGetColor "lag" on DirectX applications

[gravisrs]

I'm writing a script to automate importing 3d models (and categorize them by colours actually) and found strange behaviour.

I was looking at some previous posts regarding errors when using PixelGetColor function and I think I've localized strange bug that might answer some questions.

If you try to use PixelGetColor from directx 9 or directx 11 application

Spoiler

in 3d max 2016 you can change them in Customization > Preferences > Preference Settings dialog > Viewports tab > Display Drivers group > Choose Driver

you may get a color that was rendered there a while ago. Sometimes its one second, sometimes just few milliseconds.

Looks like PixelGetColor reads some old buffered frame instead what is actually displayed on the screen. However everything seems fine when you use OpenGL or software rendering - so it's a just a matter of DirectX 9 and 11 (and probably other versions as well).

 

To reproduce this bug you may want to write some kind of DirectX app that eg. changes the colour of a pixel on purpose and you can use looped  "while.. PixelGetColor.." statement to observe the lag. The longer the script runs - the bigger lag. I believe that PixelGetColor might be asynchronously invoked by interpreter, or invoked ahead ? Such things may produce such behaviours.

My PC is 8-core 4GHZ machine, graphic card from top of the list, SSD disks, Windows 7 etc - decent machine so it's rather not a problem with hardware choking. I've also tested it on other machine (decent hardware, windows 8) - same results.

Apart this bug report - Is there other way to get color of the pixel ? Executing some other app from AutoIT maybe ?