fast screen capture musings

odd, but

http://www.mdxinfo.com/resources/screencapture.php

may have some clues, as also

vdub is supposed to be able to do it. http://www.virtualdub.org/blog/pivot/entry.php?id=290

Here’s some code that touts itself as super fast:

http://www.mdxinfo.com/resources/screencapture.php

http://spazzarama.wordpress.com/2009/02/07/screencapture-with-direct3d/

says “if you use getRenderTargetArea…”

http://www.codeproject.com/KB/dialog/screencap.aspx?fid=23443&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=151

says “use a Video Miniport driver, Mirror Driver”

http://tmhare.mvps.org/downloads.htm

actually contains some directshow screen capture code

that “one” downloadable is actually quite fast tho…hmm…

33 thoughts on “fast screen capture musings

  1. it might vary dependent on graphics card, OS, app…hmm…
    also apparently there’s an opengl way to grab, to complement the directx way. Which is fast, dunno…

  2. faster than GetFrontBufferData()? Reply Quote
    read back from the GPU is not fast, nor is it every likely to be fast. Trying to round-trip the data like you are doing above is always going to be incrediably slow.

    WDDM-based APIs like Direct3D 10.x and Direct3D 11 are a bit faster than the XPDM …

  3. http://social.msdn.microsoft.com/Forums/fi-FI/windowsdirectshowdevelopment/thread/2cbe4674-e744-41d6-bc61-3c8e381aa942

    mentions the mirror again…might be good for catching changes, but maybe not so good for knowing when a new frame has finished…

    maybe upping the priority during the bitblt to make it avoid tearing?

    maybe warn if they don’t have 2 cores? 3 possibly even better? hmm…

    also maybe could use memcpy instead, or a tight loop? (someplace mentioned they do that…)

  4. might be able to poll “4x as often” for “top 1/4 of screen, then 2nd 1/4 of screen” … or interleaved 32 4ths or whatever…

  5. maybe if you can figure out how to only grab the part of the screen that has changed…hmm…what if you do “teeny stripes” bit blt’ing is that as fast as one large one, that might be one way…hmm…or possibly leverage the tightvnc server to know which areas have changed…

  6. multi-thread so that “exactly every x fps, it already has one [just] ready to send down the chain” (or chained multi-thread, or what not, just pull the latest one)…

  7. maybe use “Flip” then hook into the “Present” method to ‘know’ when the thing occurs, instead of having to busy wait (or sleep loop wait? though sleeping 1ms might not hurt too bad :P especially since you can catch it “in the middle of” a scan refresh which should be a good time to grab ) waiting for the WaitForVerticalBlank method to return…hmm

Leave a Reply

Your email address will not be published. Required fields are marked *


seven − = 4

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>