Wanted: Tips on Flicker-Free Draw Scrolling
in [Visual Basic]
|
Prev: Snapshot of screen
Next: HTTPS File Uploads
From: Dee Earley on 24 Nov 2009 08:02 On 23/11/2009 19:36, Webbiz wrote: > rolling with the mouse, I'd like it to actually show the bars > scrolling, also smoothly and as quick as the mouse is being moved, > while the mouse is being moved. Right now, I don't do any of the > redraw with the mouse until it has stopped at the new location, > because of the flickering issue. There is just all these redraws. > > Because I have purchased programs that seem to do this without any > problem, I believe it should be possible to do the same with my > project. Yet, I'm wondering if this is a VB6 problem, and that I'd Firstly, use double buffering so you don't draw bits at a time. You draw the data to an off screen buffer, then draw when needed. 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 -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems
From: Mike Williams on 24 Nov 2009 08:44 "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message news:%23w5aJMQbKHA.2188(a)TK2MSFTNGP04.phx.gbl... .. . . the other thing I wanted to mention as far as the drawing side of your code is concerned (except that it went out of my mind as I began to get more and more angry thinking about how GDI hardware acceleration has been destroyed on almost all Vista machines!) is the GDI PolyLine function, which even in Vista can be faster than the equivalent bunch of Line (or LineTo) methods. PolyLine draws a set of continuously connected lines, but if that does not suit your purposes then you can instead use the PolyPolyLine function, which can draw any number of separate groups of lines at different places. The only problem with that, judging by the video you posted, is you are using a number of different line colours, and PolyLine (or PolyPolyLine) draws all lines the same specified colour. You could get around that though by using one call to PolyPolyLine to first draw all black lines, then another call to PolyPolyLine to draw all red lines, etc, etc. This might add a bit of complexity to your drawing logic (setting up the different POINTAPI arrays) but it might still be worth it. You'd need to try it in practice on your own specific drawings though, to see whether it ends up with a speed increase worth bothering about. Also, you still need to look at the offscreen buffer that has been suggested by a number of people, but even when you have done that it is still best to get the most speed you can out of whatever drawing operations you perform, regardless of when you actually perform them. Mike
From: Webbiz on 24 Nov 2009 22:00 On Tue, 24 Nov 2009 13:44:22 -0000, "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote: >"Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message >news:%23w5aJMQbKHA.2188(a)TK2MSFTNGP04.phx.gbl... > >. . . the other thing I wanted to mention as far as the drawing side of your >code is concerned (except that it went out of my mind as I began to get more >and more angry thinking about how GDI hardware acceleration has been >destroyed on almost all Vista machines!) is the GDI PolyLine function, which >even in Vista can be faster than the equivalent bunch of Line (or LineTo) >methods. PolyLine draws a set of continuously connected lines, but if that >does not suit your purposes then you can instead use the PolyPolyLine >function, which can draw any number of separate groups of lines at different >places. The only problem with that, judging by the video you posted, is you >are using a number of different line colours, and PolyLine (or PolyPolyLine) >draws all lines the same specified colour. You could get around that though >by using one call to PolyPolyLine to first draw all black lines, then >another call to PolyPolyLine to draw all red lines, etc, etc. This might add >a bit of complexity to your drawing logic (setting up the different POINTAPI >arrays) but it might still be worth it. You'd need to try it in practice on >your own specific drawings though, to see whether it ends up with a speed >increase worth bothering about. Also, you still need to look at the >offscreen buffer that has been suggested by a number of people, but even >when you have done that it is still best to get the most speed you can out >of whatever drawing operations you perform, regardless of when you actually >perform them. > >Mike > > Now I remember the headache I had trying to assimilate all that high tech talk in my head. Ooh. I'm going to try the two pic box idea first, just to see what happens. So if I undertand correctly, I should replace the picturebox being referenced by my current drawing code to one that is not visible and has Autoredraw = true, correct? And then, when the drawing is completed, have it sent to the picture box I'm currently using. Is that right? Webbiz
From: Webbiz on 24 Nov 2009 23:27 On Tue, 24 Nov 2009 09:42:33 -0000, "Dave O." <nobody(a)nowhere.com> wrote: > >"Webbiz" <nospam(a)forme.thanks.com> wrote in message >news:lfolg51dqo43v288g7k8v7ahd7fv5f2gce(a)4ax.com... >> Hello. >> >> An old project of mine draws stock charts on a picturebox called >> pctChart. >> >> On this pctChart, a routine called DrawChart is used to draw OHLC or >> Candlestick price bars. >> >> After the bars are drawn, the chart tools are drawn over them, such as >> lines, boxes, etc. This is done in RedrawTools. >> >> Currently, I can scroll this chart by either double-clicking the >> chart, holding down the mouse button on the second click, and dragging >> the mouse to a new location. After the mouse is let up, then the draw >> is redrawn in the new location. >> >> Or, I can press and hold the Left or Right arrow keys and it will >> scroll the chart (slowly) to the right or left. >> >> Problem: >> >> With the arrow keys, in order to show the chart actually scrolling, it >> runs the DrawChart and RedrawTools over and over, one day (bar) at a >> time. This looks really rickety, and moves so slow. Watching it redraw >> each time is a flickering hodge-podge. It would be nice if the chart >> would scroll smoothly and quickly. >> >> As for scrolling with the mouse, I'd like it to actually show the bars >> scrolling, also smoothly and as quick as the mouse is being moved, >> while the mouse is being moved. Right now, I don't do any of the >> redraw with the mouse until it has stopped at the new location, >> because of the flickering issue. There is just all these redraws. >> >> Because I have purchased programs that seem to do this without any >> problem, I believe it should be possible to do the same with my >> project. Yet, I'm wondering if this is a VB6 problem, and that I'd >> have to program with C to achieve the above. >> >> And yes, I have a decently quick computer and graphics card, so that's >> not the problem. >> >> Any suggestions, tips and otherwise? >> >> Thanks. >> >> Webbiz > >If all you want to do is move the image about when scrolled another option >is to put a very big picture box inside a much smaller picture box, plot >your stuff on the large one then with scroll bars you can move the whole box >but only the part visible through the smaller box would be seen. > >Dave O. > Unfortunately, that would be one very large picturebox. The chart may show only 120 price bars, but if all the price bars are drawn ahead of time on that larger picturebox, you'd be talking a minimum of 3000 bars. Thanks. Webbiz
From: Webbiz on 24 Nov 2009 23:30
On Tue, 24 Nov 2009 13:02:22 +0000, Dee Earley <dee.earley(a)icode.co.uk> wrote: >On 23/11/2009 19:36, Webbiz wrote: >> rolling with the mouse, I'd like it to actually show the bars >> scrolling, also smoothly and as quick as the mouse is being moved, >> while the mouse is being moved. Right now, I don't do any of the >> redraw with the mouse until it has stopped at the new location, >> because of the flickering issue. There is just all these redraws. >> >> Because I have purchased programs that seem to do this without any >> problem, I believe it should be possible to do the same with my >> project. Yet, I'm wondering if this is a VB6 problem, and that I'd > >Firstly, use double buffering so you don't draw bits at a time. >You draw the data to an off screen buffer, then draw when needed. > >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? Thx. Webbiz |