locked
doublebuffering causes blank screen RRS feed

  • Question

  • I use GDI+ for a high volume, yet standard drawline. It works great but a little slow. I tried speeding up using DoubleBuffering, however; I get an unexpected blank square in the middle of the screen when executing the following code that calls another from the main form.

    Dim

    myFormFile As New frmForrier

    myFormFile.ShowDialog()

    Label13.Text =

    ""

    Label13.Visible =

    False

    ScreenX = WholeX

    ScreenY = WholeY

    Xcursor = WholeX

    Ycursor = WholeY

    PrevXcursor = WholeX

    PrevYcursor = WholeY

    Zoomval = WholeZoom

    myFormFile.Close()

    'myFormFile.Dispose()

    MouseReEntryF = 1

    DrawCursorOnlyF = 0

    'RedrawScreen()

    'SetCursorPos()

    Me.Update()

    'Me.Show()

    Monday, November 5, 2012 4:59 PM

Answers

  • I wanted to use doublebuffer to speed massive drawing point-to-point. (Upwards of 15,000 line segments.) 

    Double buffering does not speed up drawing per se.  What it does its to remove the flickering when you are repeatedly copying an image to the display, eg with DrawImage.  If you are drawing those 15,000 points in the Paint method then you should move that drawing out of the Paint event and do it in a method that executes only when the drawing changes.  Draw the points into a bitmp, and in the Paint event draw the bitmap to the graphics object.

    • Proposed as answer by Renee Culver Wednesday, November 7, 2012 3:09 PM
    • Marked as answer by Mark Liu-lxf Thursday, November 15, 2012 6:08 AM
    Monday, November 5, 2012 10:15 PM

All replies

  • Which form have you enabled double buffering for and which form displays the blank square?  If its the main form, does the blank square appear while the dialog is showing or only after the dialog closes?

    If the blank square occurs after the dialog is closed and if it corresponds to the area in which the dialog was displayed then you need to look at what is happening in the Update method.

    Monday, November 5, 2012 8:17 PM
  • Thank you for your response.

    The blank square does not correspond to any form size that was opened with show dialog, nor any control. The blank square shows after the "called form" gets closed & disposed, and the "calling form" (application's main form) gets a me.update() command. Me.Update forces a redraw. I was wondering if I need to look for a flag or thread before calling it?

    It would seem to the casual observer that if there would be something wrong in the Paint Events or Paint method, it would show whether or not doublebuffer is set to true. I traced through PAINT and did not see anything unusual. I only see this when doublebuffer is set to true, and this seems odd in the sense that no forms are rectangular. Otherwise, the methods "seem" fine when doublebuffer is set to false. I wanted to use doublebuffer to speed massive drawing point-to-point. (Upwards of 15,000 line segments.) 

    Monday, November 5, 2012 10:02 PM
  • I wanted to use doublebuffer to speed massive drawing point-to-point. (Upwards of 15,000 line segments.) 

    Double buffering does not speed up drawing per se.  What it does its to remove the flickering when you are repeatedly copying an image to the display, eg with DrawImage.  If you are drawing those 15,000 points in the Paint method then you should move that drawing out of the Paint event and do it in a method that executes only when the drawing changes.  Draw the points into a bitmp, and in the Paint event draw the bitmap to the graphics object.

    • Proposed as answer by Renee Culver Wednesday, November 7, 2012 3:09 PM
    • Marked as answer by Mark Liu-lxf Thursday, November 15, 2012 6:08 AM
    Monday, November 5, 2012 10:15 PM
  • I wanted to use doublebuffer to speed massive drawing point-to-point. (Upwards of 15,000 line segments.)

    Double buffering does not speed up drawing per se.  What it does its to remove the flickering when you are repeatedly copying an image to the display, eg with DrawImage.  If you are drawing those 15,000 points in the Paint method then you should move that drawing out of the Paint event and do it in a method that executes only when the drawing changes.  Draw the points into a bitmp, and in the Paint event draw the bitmap to the graphics object.

    Monday, November 5, 2012 10:16 PM
  • Thank you once again for your response. ("Sandy", an east coast storm caused a delay.) I regret that it now causes more questions that I must ask. It took me a bit to move the drawing commands out of form_paint, but I left it in GDI+ format. At this point I discovered that for some reason, when doublebuffer is active, the operating system rasises another event that fires form_paint for a second time before that routine that redraws the screen finished. I suspected a mouse event, however; placing a Beep confirms no mouse_move event. I have yet to find other events that may be the culprit. I do suspect the operating system simply because operating systems used to have "interrupts" that look for servicing every 25 miliseconds or so, and I supose that is still true.

    1. What intially sold me on GDI+ was hardware independance.  I realize the ongoing battle Microsoft has had with OpenGL, and the need for speed!. What I don't understand is why Microsoft is unable to pass those commands to the graphics chip or graphics processor. There are only so many manufacturers out there, and Microsoft regularly attends the conferences on hardware standards. If the operating system communicates with those devices, then why not VB.NET and NET 4.5? [I used to BitBlt previous versions of this program in VB6 which was lightning fast, but evolutions in VB.NET abondoned some of the features. Why did Microsoft abandon those features in its VB code format for a while? If you could point me to some .NET BitMap examples,I would greatly appreciate that. I would like to stay hardware independent if possible, and although my confidence is shaken somewhat in Microsofts "recommendations" over the years. I worry that BitMap may place me in a situation that it would not work with all hardware installations.

    2. Should all forms be doublebuffered, or only the form with focus? Since the form is set to always be on top, could "doublebuffer" see a printer pop-up window or something else that is minimized and operating in the background on timers possibly using the same doublebuffer feature that is processed by an I7 (core)? That question may not make sense at first! Under modern operating systems, calls to a dll or service creates a "seperate instance" that gets disposed so that "trash collection" of the calling context takes place. Is this also true for a dll or service that operates a single device called by multiple contexts where graphics code could be piped to different processors of multiple "core" processor?

    3. You mentioned looking in the update method. Is there a way to defeat "background" forms from affecting the focused form in this method?

    Thank you once again for your guidance.

    Wednesday, November 7, 2012 2:34 PM
  • P.S. Tried Bit Blitting, but seemed to have hit a 32,000 line limit. Just a guess. Kept getting stack over-flow error if I understand try catch error message.
    Thursday, November 8, 2012 7:59 PM
  •  At this point I discovered that for some reason, when doublebuffer is active, the operating system rasises another event that fires form_paint for a second time before that routine that redraws the screen finished. I suspected a mouse event, however; placing a Beep confirms no mouse_move event. I have yet to find other events that may be the culprit. I do suspect the operating system simply because operating systems used to have "interrupts" that look for servicing every 25 miliseconds or so, and I supose that is still true.

    The operating system won't create a Paint event just becasue an interrupt has occurred.   What is the problem that you are seeing?

    1. What intially sold me on GDI+ was hardware independance.  I realize the ongoing battle Microsoft has had with OpenGL, and the need for speed!.

    If you want hardware independence, use GDI+.  If hardware independence is not important use OpenGL and live with the restrictions, limitations and warnings that you find with any high speed graphics game.

    If the operating system communicates with those devices, then why not VB.NET and NET 4.5? [I used to BitBlt previous versions of this program in VB6 which was lightning fast, but evolutions in VB.NET abondoned some of the features. Why did Microsoft abandon those features in its VB code format for a while?

    VB .Net communicates with the hardware using the facilties provided by the OS.  That means it uses the device drivers, either generic or as supplied by the manufacturers, depending on the hardware.  MS has not abandonded any of that functionality in VB, but in any case you can still use API calls to do anything that the OS can do. 

    I worry that BitMap may place me in a situation that it would not work with all hardware installations.

    I don't understand that comment/  What do you mean by 'bitmap' here?

    2. Should all forms be doublebuffered, or only the form with focus? Since the form is set to always be on top, could "doublebuffer" see a printer pop-up window or something else that is minimized and operating in the background on timers possibly using the same doublebuffer feature that is processed by an I7 (core)? That question may not make sense at first! Under modern operating systems, calls to a dll or service creates a "seperate instance" that gets disposed so that "trash collection" of the calling context takes place. Is this also true for a dll or service that operates a single device called by multiple contexts where graphics code could be piped to different processors of multiple "core" processor?

    Only the form that needs the flickering minimised needs to be double buffered.  I think the process you are referring to above is the bitblitting part of the double buffering process which is probably implemented as a DMA memory copy.  Exactly how that operates depends on the implementation of the device driver but in general a DMA operation will not be interrupted by a context switch.  However, as this is still a 'slow' operation in CPU terms it is quite possible that the processor continues executing in other cores.  This would not be visible to the OS or to the user.

    You are still talking about double buffering in terms of speed. Note that double buffering is concered with flickering during drawing - it has nothing to do with speed other than the user's perception of an animation.

    3. You mentioned looking in the update method. Is there a way to defeat "background" forms from affecting the focused form in this method?

    You would need to identify what these 'background' forms are doing to affect the focused form.   If they are forms that are part of your application then you need to make sure that they do not do things to reduce your drawing speed, such a hogging the CPU. But apart from stealing CPU cycles I can't think what they might do to interfere.   If they are not part of your application then there's nothing you can do - Windows is multi-tasking, and that has implications for graphics performance.  Think about games that only run in full screen mode and pause completely when the user switches applications.

    Thursday, November 8, 2012 8:28 PM