Window Capture Framerate could be based off target window framerate

[ocbaker]

Hey,

In regards to your capture framerate I suggest you might want to consider scraping the framerate from the target window and use that or the user selected framerate (whichever is lowest).

For example, Capturing Chrome at over 60FPS is nearly pointless, especially if the window is only rendering at 5 FPS or something. A lot of Windows applications have their framerate tied to updates. So if the window is doing nothing it will only render at maybe even 1FPS, but as soon as you do something it will jump up to process that action.

This might help prevent unnecessary rendering.

[Hotrian]

That's a good idea, but I don't know how to grab the current FPS of other windows :x It would likely vary depending on the draw method being used.

Either way, I should definitely adjust the per-application-save-system so that it also saves the last used FPS in addition to the window crop settings, but as for now you'll have to change the FPS manually when you switch applications.

[ocbaker]

Another idea is you could possibly offload your desktop capture and bitmap preparation into a separate thread as it is quite costly and lucky for you refresh rate of your capture and render targets are not tied together.

If you had a worker looping on a thread preparing a small buffer (or no buffer) for your render thread to consume you might get some more performance.

It would be interesting to see some performance metrics and where the performance costs are in this application. Your biggest cost is likely just that you are using managed code.

In terms of getting the Framerate of an external window I believe you can hook into DirectX for that.

[Hotrian]

Thanks for the suggestions.

Regarding hooking DirectX, it should be relatively easy, but I'm concerned it could look bad to certain games, and potentially get users banned for "modding the client". It would just be the same thing that popular programs such as FRAPS do, but I'm still concerned nonetheless.

/u/frontier_support implied that it should be okay, but that it also might get users banned. They suggested I submit my program to them to get whitelisted, which I'll definitely do if I go down that route, but it might just be opening a can of worms to implement it at all.

With all the new games coming out constantly, it would be a lot of work to submit it to every relevant game to either get the OK or blacklist hooking on that application. I definitely don't want to be getting users banned.

Also, I just added a primitive FPS counter a few hours ago that should give you a basic idea on performance. It's made in Unity so you can run the profiler against it if you want, but there isn't much to see. Basically the GDI stuff, along with Garbage Collection, make up the majority of work done.

There are definitely some performance enhancements to be made, but I've been working to weed out all the bugs before I go ahead and introduce more ;]

Edit: Also I realize that we're trying to capture the FPS of the mirrored window here, not the game we're mirroring into, but my concern is that games will have anti-cheat protection that will scan for things like D3D hooking; plus it only takes a single miss click for someone to accidentally mirror from one of these games, causing it to hook and poll FPS, potentially raising flags with their anti cheat system.

I'm still going to look into this and other methods of capture, but I'm also still concerned, nonetheless.