locked
Perforator: How does it work RRS feed

  • Question

  • 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?
    Tuesday, November 17, 2009 3:07 PM

Answers

  • 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
    Wednesday, November 18, 2009 1:05 AM

All replies

  • 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
    Wednesday, November 18, 2009 1:05 AM
  • 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.
    Thursday, November 19, 2009 9:41 PM
  • 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?)

    Thanks guys!
    Friday, November 20, 2009 6:08 PM