Wanted: Tips on Flicker-Free Draw Scrolling
in [Visual Basic]
|
Prev: Snapshot of screen
Next: HTTPS File Uploads
From: Webbiz on 26 Nov 2009 13:49 On Wed, 25 Nov 2009 10:44:35 +0000, Dee Earley <dee.earley(a)icode.co.uk> wrote: >On 25/11/2009 04:30, Webbiz wrote: >> On Tue, 24 Nov 2009 13:02:22 +0000, Dee Earley >> <dee.earley(a)icode.co.uk> wrote: >>> Even with this, I was getting some flickering as VB insisted on >>> redrawing some parts of the screen in WM_PAINT before firing the Paint >>> event, despite me eating the WM_ERASEBACKGROUND message. >>> >>> I ended up handling WM_PAINT myself then passing direct to the paint event: >>> Case WM_PAINT >>> 'We handle WM_PAINT ourselves as VB6 seems to explicitly draw the >>> background in its handler >>> hDC = BeginPaint(hWnd, PaintInfo) >>> GraphFrame_Paint >>> EndPaint hWnd, PaintInfo >>> 'We've handled it so VB doesn't do anything further >>> SubClassed_WindowProc = 0 >>> Handled = True >> >> >> Forgive my inexperience, but exactly where did you place this >> Select...Case code? > >It's in a subclass handler for the picturebox. >Exactly where/how you use it depends on the sub class handler you're using. I'm sorry, but that went over my head. You should see the look on my face...dumbfounded. Kind of a 'huh?' look, if you know what I mean. Subclass handler? Guess I'll have to add that to my list of homework for later. Thanks. :-)
From: Webbiz on 26 Nov 2009 13:55 On Wed, 25 Nov 2009 22:27:31 -0000, "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote: >"Webbiz" <nospam(a)forme.thanks.com> wrote in message >news:vkcpg5h1pp45tc0daljhgtsuqfuec7ti36(a)4ax.com... >>> On Tue, 24 Nov 2009 13:02:22 +0000, Dee Earley >>> <dee.earley(a)icode.co.uk> wrote: >>> Even with this, I was getting some flickering as VB insisted on >>> redrawing some parts of the screen in WM_PAINT before >>> firing the Paint event . . . I ended up handling WM_PAINT >>> myself then passing direct to the paint event: >>> Case WM_PAINT >>> hDC = BeginPaint(hWnd, PaintInfo) >>> . . . etc >> >> Forgive my inexperience, but exactly where did you >> place this Select...Case code? > >Don't worry too much about that, Webbiz. I think Dee was deliberately being >a little bit obtuse when she told you to just place it in your subclass >handler . . . but then that's what you can expect of Londoners ;-) (Sorry, >Dee, just a little Scouse joke!). > >I think Dee was referring to problems she needed to solve in certain >circumstances concerning drawings in the PictureBox (or Form) Paint event, >which fires /after/ VB has itself dealt with the system WM_PAINT event, and >/after/ VB has effectively cleared out the "dirty rectangle" information, >which can then not effectively be read in the VB Paint event, even if you >use the GetUpdateRect API. This can result in any VB Paint event drawing >causing some flicker if for some reason you perform a Cls or clear an area >as part of a transparent blit or whatever during your drawing, because your >drawing is not clipped to the "dirty rectangle" and fills parts of the >PictureBox (or Form) other than the parts that actually required painting >(the usually very small "dirty rectangle" for example as a user drags a Form >off the edges of the display and back again). Subclassing the WM_PAINT >(which effectively means "getting at it" at a fairly low level and before >the VB Paint event fires, and whilst the "dirty rectangle" information is >still available and valid, enables you to do things that you could not >otherwise do. > >This should not be a problem in your own code though, and should not be >required, because I assume you will be using an Autoredraw PictureBox, and >VB Paint events do not actually fire in a PictureBox whilst Autoredraw is >True (although the lower level WM_PAINT events still fires of course, and is >handled by VB itself). In an Autoredraw PictureBox VB very effectively >handles the redrawing of the "dirty rectangle" for you in the WM_PAINT event >as the user moves the Form (PictureBox) on and off the edges of the display, >and in other circumstances. VB is quite good at this, painting /only/ the >required dirty rectangle from the contents of the hidden Autoredraw memory >bitmap (the Autoredraw bitmap that I mentioned in my previous response), so >as far as maintaining the contents of the PictureBox as the user drags the >Form on and off the edges of the display (and other things) you can >effectively forget all about it when using an Autoredraw PictureBox and >simply let the VB Autoredraw mechanism get on with the job for you. > >The only thing you need to concern yourself with is the initial drawing of >the new PictureBox contents each time the user uses the scroll bar (or arrow >keys or whatever) to require a different part of your stock and share data >to be drawn, which is something I covered in my previous response,. > >Mike > > Up to this point, let me see if I get what has been suggested. 1. Since I am using an AutoRedraw picturebox (frmChart.pctChart), there is no need for me to do the 'double-buffer' technique because the picturebox will already be doing this when AutoRedraw = True. 2. For matters of performance, replace my .Line code (VB) in favor of the FillRect code (API). Just so I'm clear on this. Thank you Mike. Webbiz
From: Mike Williams on 26 Nov 2009 16:49 "Dee Earley" <dee.earley(a)icode.co.uk> wrote in message news:OFAfRpnbKHA.4780(a)TK2MSFTNGP04.phx.gbl... > As for using AutoRedraw, I'd forgotton about it as I stopped > using it long ago as a lot of the data we rendered was "live" or > at least frequently updating and wanted to improve performance. Perhaps you might like to look at that again. In Vista, at least on the systems I've tested it on, drawing into an Autoredraw PictureBox is on average between 50 and 75 per cent faster than drawing into a non Autoredraw PictureBox, which can often more than compensate for the time taken to Refresh it to the display, and which of course is "extra speed for nothing" if you need to perform double buffering anyway. Mike
From: Mike Williams on 26 Nov 2009 17:22 "Webbiz" <nospam(a)forme.thanks.com> wrote in message news:rjjtg5ps8bd3mqo743np3pt5gb54f7c7fi(a)4ax.com... > Up to this point, let me see if I get what has been suggested. > > 1. Since I am using an AutoRedraw picturebox (frmChart.pctChart) > there is no need for me to do the 'double-buffer' technique because > the picturebox will already be doing this when AutoRedraw = True. Yep. That's about it. > 2. For matters of performance, replace my .Line code (VB) in > favor of the FillRect code (API). Yes, if you're drawing vertical or horizontal lines more than one pixel wide (which you appear to be) and if you want your code to run as quickly as possible in Vista. I haven't tested the comparative speed of Line and FillRect on XP machines when drawing vertical and horizontal lines of more than one pixel thickness (and I don't currently have an XP machine to perform any tests on) but I seem to vaguely recall lines of more than one pixel thickness not being hardware accelerated even on XP machines, so I imagine using FillRect instead (which may or may not be accelerated on XP, depending on the hardware) will be okay on those machines as well. If you have an XP machine then perhaps you might like to perform some speed tests yourself. Mike
From: Larry Serflaten on 26 Nov 2009 18:55
"Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote > > 1. Since I am using an AutoRedraw picturebox (frmChart.pctChart) > > there is no need for me to do the 'double-buffer' technique because > > the picturebox will already be doing this when AutoRedraw = True. > > Yep. That's about it. I would raise an objection there. The difference between drawing the chart once (to an off screen buffer) and painting in place compared to drawing the chart in every Resize event is going to increase as the drawing work load increases. For simple (say less than 50 lines) images, the difference may be neglegible, but for several hundred lines, the difference will be signifcantly more noticable. If you're only talking about drawing the visible portion of the chart on each Resize (or Scroll) event, then I would agree, there is no gain in using a second buffer if VB already does it for you. But I would suggest that drawing the chart once and painting to the form as needed will be more responsive to user input.... LFS |