[FFmpeg-devel] [PATCH] Add Win32 GDI-based screen grabbing

[Don Moir]

----- Original Message ----- 
From: "Calvin Walton" <calvin.walton at kepstin.ca>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, April 02, 2014 2:36 PM
Subject: Re: [FFmpeg-devel] [PATCH] Add Win32 GDI-based screen grabbing


> On Tue, 2014-03-25 at 05:30 -0400, Don Moir wrote:
>> ----- Original Message ----- 
>> From: "Eli Kara" <eli at algotec.co.il>
>
>> > I just have to mention something with regards to capturing from the
>> > screen. As far as modern operating system go, i.e: Win7 with
>> > desktop composition and Windows 8 (where desktop composition cannot
>> > even be disabled),
>> > the performance will *always* be far from optimal. Copying from
>> > video memory back to system memory is an inherently expensive
>> > operation, sometimes in the order of tens of milliseconds.
>> > Additionally, it will inevitably
>> > stall the entire GPU and WDM pipes. Actually, due to this, capturing
>> > this way is even slower than it used to be in Windows XP
>> > (this is documented).
>> >
>> > Just a point to keep in mind..
>
> This is of course true of any composited desktop system, on Windows or
> Linux. A simple fact of life; fortunately, doing live screen capture
> isn't something most people do that often, and they're pretty much given
> to expect that it'll have a hit on desktop performance.
>
>> With Vista and up, GDI is not hardware accerated when Aero is on.
>> Don't know about Win 8. Turn Aero off and with Vista and Win 7,
>> GDI goes back to hardware acceleration. It can have a radical effect
>> on performance. Anything using GetPixel and SetPixel too often
>> can bring a fast computer to a crawl with Aero on. Try the MS utility
>> zoomin.exe with Aero on and off in Win 7. BitBlt can also
>> suffer quite abit. With Aero off or in XP, BitBlt goes right to screen
>> memory. With Aero on, it's layered in software.
>
> It's GDI is actually (partially) hardware accelerated in Aero on Windows
> 7 and later... take a look at
> http://msdn.microsoft.com/en-us/library/windows/desktop/ff729480%
> 28v=vs.85%29.aspx
> which reports that with a WDDM 1.1 driver, some GDI operations (notably
> text rendering, BitBlts, AlphaBlend, TransparentBlt, and StretchBlt) are
> accelerated while the compositor is running.

I think you are pretty safe with BitBlt in general. I was mostly implying with the copy from video ram, it should not be used 
outside of XP or with Aero on. It is much faster to either acqurie a lock or use some other access method and move the bits in this 
case.

> Naturally, Eli's comments about performance due to the copy from video
> to system ram still apply!
>
> -- 
> Calvin Walton <calvin.walton at kepstin.ca>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel