none
BitBlt takes quite a long time RRS feed

  • Question

  • Hi there,

    I'm currently trying to speed up the redraw mechanism of my device. I therefore set up a small application that blits a simple bmp onto the screen. On application side I put some performance counters for measuring. In my particular case the call to BitBlt takes about 10 milliseconds to complete.

    I also did some modifications in my display driver for getting information on where the time is being spent. I did some research within BltPrepare for finding out what blt function is being called. Right here I also put some performance counters for measuring. And - what's quite suprising to me - the blt function (driver side) solely takes ~ 1 ms to complete. BltPrepare and BltComplete seem not to take the rest of the time. So, did I miss something? What else is being called within a bitblt?

    Any help would be apreciated.

    Thanks in advance,
    Peter

    Friday, June 3, 2011 8:58 AM

Answers

  • On 6/6/2011 10:15 AM, pkjt wrote:
    > Hi Valter,
    > first of all thanks a lot for your hints.
    >
    > My sample bitmap is 190 x 230 px of size (8 bit) and I'm workin on a
    > MIPSIV based platform (600 MHz). I did some further research and found
    > out that that all the preliminary work in this particular case is being
    > done by GPE::EmulatedBlt_Internal. I also did some modifications in my
    > application. Now all the bitmaps are being converted to 16 bit before
    > they're getting blitted. With this one single blit is a little faster.
    >
    > I also thought about using DirectDraw. But - till now - I doubt whether
    > this could lead into heavy conflicts with the rest of our present
    > application approach. Let me give you some background information. Our
    > application is a visualisation runtime. Aside of bitmaps it must be
    > capable to draw simple graphic types (lines, rectangles, ellipses, ...)
    > as well as compound types (meters, xy-graphs, ...). Right now most of
    > them are being drawn by the help of MFC. Actually I do not have
    > detailled experience with DirectDraw and I cannot estimate how much
    > effort it would take to switch the drawing interface to DirectDraw.
    > Would I have to switch all the drawing routines to DirectDraw? Or is
    > there a possibility of doing a mixture? If there was a possibility to
    > mix, would there be a possibility of influencing z-order (i.e. for
    > getting things like: draw a line on background, a DD bitmap (with
    > lateral off-set) in the middle, and xy-graph on top)?
     
    Mixing DD and GDI is complex and your display driver may not support DD
    window mode, allowing only full-screen access to the display.
    To have the best blt performances on GDI you should use bitmaps that are
    in the same format of video memory, blitting images that use a different
    format will require a conversion.
     
     

    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    • Marked as answer by pkuebler Tuesday, May 19, 2015 8:22 AM
    Monday, June 6, 2011 9:55 AM

All replies

  • On 6/3/2011 10:58 AM, pkjt wrote:
    > Hi there,
    >
    > I'm currently trying to speed up the redraw mechanism of my device. I
    > therefore set up a small application that blits a simple bmp onto the
    > screen. On application side I put some performance counters for
    > measuring. In my particular case the call to BitBlt takes about 10
    > milliseconds to complete.
    >
    > I also did some modifications in my display driver for getting
    > information on where the time is being spent. I did some research within
    > BltPrepare for finding out what blt function is being called. Right here
    > I also put some performance counters for measuring. And - what's quite
    > suprising to me - the blt function (driver side) solely takes ~ 1 ms to
    > complete. BltPrepare and BltComplete seem not to take the rest of the
    > time. So, did I miss something? What else is being called within a bitblt?
    >
    > Any help would be apreciated.
    >
    > Thanks in advance,
    > Peter
    >
     
    On wich kind of platform are you working? Wich is the size of the bmp
    you are blitting?
    This could give us some metrics about the performances you are experiencing.
    If your driver is based on GPE part of the implementation is inside the
    GPE base classes.
    If you use GDI BitBlt this will take into account also clipping and
    overlapping windows. If you need the fasted blt time you should use
    DirectDraw.
     

    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    Friday, June 3, 2011 3:23 PM
  • Hi Valter,
    first of all thanks a lot for your hints.

    My sample bitmap is 190 x 230 px of size (8 bit) and I'm workin on a MIPSIV based platform (600 MHz). I did some further research and found out that that all the preliminary work in this particular case is being done by GPE::EmulatedBlt_Internal. I also did some modifications in my application. Now all the bitmaps are being converted to 16 bit before they're getting blitted. With this one single blit is a little faster.

    I also thought about using DirectDraw. But - till now - I doubt whether this could lead into heavy conflicts with the rest of our present application approach. Let me give you some background information. Our application is a visualisation runtime. Aside of bitmaps it must be capable to draw simple graphic types (lines, rectangles, ellipses, ...) as well as compound types (meters, xy-graphs, ...). Right now most of them are being drawn by the help of MFC. Actually I do not have detailled experience with DirectDraw and I cannot estimate how much effort it would take to switch the drawing interface to DirectDraw. Would I have to switch all the drawing routines to DirectDraw? Or is there a possibility of doing a mixture? If there was a possibility to mix, would there be a possibility of influencing z-order (i.e. for getting things like: draw a line on background, a DD bitmap (with lateral off-set) in the middle, and xy-graph on top)?

    Best regards,
    Peter

    Monday, June 6, 2011 8:15 AM
  • On 6/6/2011 10:15 AM, pkjt wrote:
    > Hi Valter,
    > first of all thanks a lot for your hints.
    >
    > My sample bitmap is 190 x 230 px of size (8 bit) and I'm workin on a
    > MIPSIV based platform (600 MHz). I did some further research and found
    > out that that all the preliminary work in this particular case is being
    > done by GPE::EmulatedBlt_Internal. I also did some modifications in my
    > application. Now all the bitmaps are being converted to 16 bit before
    > they're getting blitted. With this one single blit is a little faster.
    >
    > I also thought about using DirectDraw. But - till now - I doubt whether
    > this could lead into heavy conflicts with the rest of our present
    > application approach. Let me give you some background information. Our
    > application is a visualisation runtime. Aside of bitmaps it must be
    > capable to draw simple graphic types (lines, rectangles, ellipses, ...)
    > as well as compound types (meters, xy-graphs, ...). Right now most of
    > them are being drawn by the help of MFC. Actually I do not have
    > detailled experience with DirectDraw and I cannot estimate how much
    > effort it would take to switch the drawing interface to DirectDraw.
    > Would I have to switch all the drawing routines to DirectDraw? Or is
    > there a possibility of doing a mixture? If there was a possibility to
    > mix, would there be a possibility of influencing z-order (i.e. for
    > getting things like: draw a line on background, a DD bitmap (with
    > lateral off-set) in the middle, and xy-graph on top)?
     
    Mixing DD and GDI is complex and your display driver may not support DD
    window mode, allowing only full-screen access to the display.
    To have the best blt performances on GDI you should use bitmaps that are
    in the same format of video memory, blitting images that use a different
    format will require a conversion.
     
     

    Valter Minute
    Windows Embedded MVP
    http://geekswithblogs.net/WindowsEmbeddedCookbook
    • Marked as answer by pkuebler Tuesday, May 19, 2015 8:22 AM
    Monday, June 6, 2011 9:55 AM