Screen Capture & Manipulation, what's the best method/performance?

Posted on 2012-08-30
Last Modified: 2012-09-10
I've coded an application using GDI to do screen capture using BitBlt.

In my application, i'm doing theses operations:
Desktop Screen Capture
Masking using Regions to hide some part of the capture
Image comparisons to see if there's any changes
"DownScale" the images if desired (from 32 bits down to 8 bits palette)
Sending the image over network stream

I would like to know if there's better alternative than GDI for all these operations?
(I know there's DirectX, GDI+, but i don't know anything about their performance)

If you have any sample of codes, it would be appreciated.

(Our application should be able to run on older systems, not only Windows 7 & Vista)

Thanks for your help
Question by:cdebel
    LVL 11

    Accepted Solution

    If you want access to the direct windows desktop image, and you don't want to use anything like DirectX, then I think you're stuck with GDI.

    As a general concept, though, I don't think the GDI portions of what you're doing should be too much slower than any other technique.

    Make sure the amount of time you're actually using the GDI handle is minimized;
    get it, lock it, copy the bitmap, unlock, release the handle
    before you do anything with the bitmap.

    The time to get the handle and lock it varies greatly among the different video drivers and /or versions of windows.

    That was one of the reasons it was rewritten and redesigned for GDI+; it can be really, really slow.

    If you really need the backward compatibility, though, and you don't want to install software on the desktop computer, i think you're stuck with GDI.

    Make sure you're copying the data from the desktop window as efficiently as possible.  

    You might find this link useful, but from your description it didn't sound like directX or the media api was acceptable.

    Hope this helps,
    LVL 10

    Author Comment

    and you don't want to use anything like DirectX

    It's not that we don't want to use, it's that we don't have much experience with DirectX, and there must be someone on this planet who already tried to do Desktop Capture with DirectX.

    Apparently, DirectX is not the best thing to accomplish this task according to your article
    LVL 11

    Expert Comment

    No, it *can* be.

    It's just that if you need to support everything since Win95, then you're going to be in DLL hell with DirectX.

    I like DirectX just fine.   It's easy to use, and a nice, full featured API.

    But when you get down to it, it's not doing much more than you're doing with GDI in this instance.

    And, when I say the old ways are "slow", I'm still talking about sub-second times to complete.

    Are you capturing/transmitting the bitmaps in real-time?

    LVL 10

    Author Comment

    Yes we do capture & transmit parts of the bitmap in real-time.  (We check for part of it that changed.  We do not transmit the whole 1920x1200 bitmap).  And sometime, if the bandwidth is too low, we downscale the image to 8 bits image instead of 32 bits.
    LVL 11

    Expert Comment

    So you're transmitting the "dirty bits" in real-time?

    ie, 60 or 72 hz?

    Which versions of windows do you need to support?

    I didn't realize you had a real-time component to it, or that your resolutions were that large.

    I don't believe any of the older GDI systems I was thinking of (win95,win98) will support resolutions that large, but I haven't run those OSes in quite some time.

    I think the approach I would take...

    Check to see if directx is installed already.  if it's available, go ahead and use the DirectX methods (they're in Direct3d now-a-days; Direct2d is an obsolete spec, but might be still available).   WinXP was the first windows OS to ship with DirectX included.

    If DirectX is not available, gracefully downgrade the code to the GDI section.

    Again, the only part that would need to be done would be grabbing the latest bitmap...

    Hope this helps,
    LVL 10

    Author Comment

    Well, if "Real Time" mean 60-72 hz, we are bellow that.  We plan to send 3-4 images per second.  

    We want to support down to Windows XP SP3.

    At the moment with GDI, we are able to grab an image every 50 ms if my memory is correct.  This doesn't include image comparison and usage of regions.

    Let me do some test with DirectX, i'll advise you to see the result.  It might take sometime since we need to get used to DX to learn how every operations need to be done.

    Thanks for the link you provided
    LVL 22

    Assisted Solution

    I don't think capturing the screen would be the most performance critical part of what you are doing. If im not mistaken then the Microsoft remote desktop technology hooks up every window on the system and then minimizes the number of times it has to capture the screen by intelligently watching for events that change the presentation and capturing only what changes as it changes. If your RDC is really slow you can actually see some of that happening visually.

    That and using good/fast compression over the data sent may result in drastic performance improvements.
    LVL 10

    Author Closing Comment

    I don't think capturing screen will have a huge impact on the performance.   But what i wanted to know is if DirectX offer set of functions to compare images to determine what changes, and if it deal correctly with Regions because our application is a bit heavy on Regions because we build up a mask from the applications that we want and don't want to show on the screen.  When you consider an application juste like "One Window", it's simple, but it's not like this that Windows is built.  Even a tooltip have it's own window.

    I could use CBT to detect changes of size and stuff like that, but that's not really interresting.

    Compression work good at the moment.  We might tweek it to compress a little more, but in term of speed that's good.

    Thanks for the help & hints you have provided!  I really appreciate!

    Featured Post

    How your wiki can always stay up-to-date

    Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
    - Increase transparency
    - Onboard new hires faster
    - Access from mobile/offline

    Join & Write a Comment

    Suggested Solutions

    Title # Comments Views Activity
    zeroFront challenge 7 58
    EvenOdd challenge 10 69
    noX challenge 17 54
    VB 6.0 printer how to align 6 37
    A short article about a problem I had getting the GPS LocationListener working.
    This is an explanation of a simple data model to help parse a JSON feed
    The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.
    In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

    732 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    25 Experts available now in Live!

    Get 1:1 Help Now