33 thoughts on “fast screen capture musings”

1. tweak the GDI code to be more efficient? All C based?

2. tweak whatever code it is to “search” for changes and only grab those? (quadrantize…) ?

3. sample every other line/only specific area/use better screen options/resolution…

4. 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…

5. does nvidia have its own, fast[er] way? what about enabling/disabling aero? enabling/disabling optimizations/acceleration?

6. interlacing (only take a few pixels…)
   could possibly add output filters…

7. Or disable Overlay video output.

   from http://forum.videolan.org/viewtopic.php?f=14&t=80153&p=264957&hilit=desktop#p264957

8. http://www.virtualdub.org/blog/pivot/entry.php?id=282
   http://www.virtualdub.org/blog/pivot/entry.php?id=290

   some mirror thing?

9. http://stackoverflow.com/questions/2814843/fast-screen-capture-and-lost-vsync might be interesting…

10. does camstudio have any tricks up its sleeve?

11. make bitblt faster: http://betterlogic.com/roger/?p=3037

12. ffdshow is said to capture faster…NB

13. profile guided optimization for capturer? ffdshow? vlc?

14. maybe transmit it to some other box for transcoding?

    http://forum.videolan.org/viewtopic.php?f=4&t=82143

15. java’s robo capture…is that super fast…?

16. here’s how fraps does it, apparently:

    http://stackoverflow.com/questions/2814843/fast-screen-capture-and-lost-vsync
    http://www.gamedev.net/topic/359794-c-direct3d-hooking-sample/

    Also VNC has a mirror output display…maybe that could work?

17. 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 …

18. stretchrect faster than bitblt (?): http://www.ureader.com/msg/14641021.aspx and also http://spazzarama.wordpress.com/2009/02/07/screencapture-with-direct3d/ recommends it. These are just for direct3d though.

19. http://stackoverflow.com/questions/5069104/fastest-method-of-screen-capturing

20. Sufrace.fromSurface() was slow
    what worked much much better was
    Device.StretchRectangle()

    do they have C equivalents?

21. using windows media encoder might also be fast, but that doesn’t feel too flexible…
    http://forum.videolan.org/viewtopic.php?f=4&t=58200

22. maybe tight vnc server has a mirror or something useful in it, speed-wise?
    http://stackoverflow.com/questions/6236499/how-to-capture-desktop-on-windows-so-that-it-would-capture-both-directx-and-norma

    appears it may not be open source? http://www.tightvnc.com/driver.html though the server code is…hmm…

23. forcing the mouse to be hidden might help? (http://stereopsis.com/blttest –quite fascinating program, actually, and it’s really fast and is open source, so I wonder if they’re doing anything special to ensure BitBlt’ing is at its fastest…)

24. some tips on using bitblt: http://www.codeguru.com/forum/showthread.php?t=324303 (though for me switching resolution didn’t help).
    http://www.experts-exchange.com/Programming/System/Windows__Programming/Q_20583862.html says to use memcpy instead of bitblt also says to turn *off* hardware acceleration and it might become faster…

25. multi-threading several bitblt’s might help (?) http://blog.tedd.no/index.php/2010/08/16/c-image-analysis-auto-gaming-with-source/

26. 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…)

27. “DESKTOP” or 0 versus HWND ? hmm… fast timer methods perhaps needed?

28. 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…

29. VIDIX ? http://mplayerxp.sourceforge.net/

    ‘-af lp’ as reasonable alternative of framedropping or -af resample

    See also http://betterlogic.com/roger/2010/07/how-to-make-bitblt-faster

30. 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…

31. 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)…

32. http://stackoverflow.com/questions/7154574/bitblt-performance-with-aero-enabled/7155431#7155431

33. 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 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