Does anybody know how the Perforator tool works under the hood? For instance, it's able to get the dirty regions for the target WPF application, which leads me to believe it's interacting straight with the underlying Direct3D device. Does it use undocumented functions to achieve this?
The basic answer is that Perforator doesn’t ‘know’ about dirty regions, it’s tweaking a debug control in the target process to force the WPF engine itself (in proc) to tint dirty regions. This’ll work with hardware and software and is not related to Direct3D.SDET : Deployment/Hosting
The basic answer is that Perforator doesn’t ‘know’ about dirty regions, it’s tweaking a debug control in the target process to force the WPF engine itself (in proc) to tint dirty regions. This’ll work with hardware and software and is not related to Direct3D.SDET : Deployment/Hosting
Matt is correct. The WPF graphics engine exposes hooks to toggle the dirty region overlay, tint for software rendering, etc. It is also reporting the frame rate, vid memory usage (estimated) etc. DX is not involved at all.
I see. So Perforator doesn't interact with Direct3D at all for anything whatsoever? (On a similar note, if one wanted to, could you get the Direct3D device handle out from the WPF application without employing crazy hooking techniques?)
