Thanks Joe. This makes great sense. I implemented it like you outlined,
using Phil's BufferedCanvas as a basis, since he so conveniently gives
access to the back buffer. His Update method just does a DrawPicture,
and I've got the Paint just calling the Update method.
I am now flicker free. Some of the built-in controls don't redraw until
I stop waving a window in front of my app, but the app doesn't flicker.
One thing I notice is that the app is consuming huge amounts of CPU
cycles when doing the DrawPicture. If I open Windows Task Manager, and
wave it in front of my canvas, I immediately go to 100% CPU utilization
on an AMD 64 3200. The same thing happens when I wave the Task Manager
window in front of the RB IDE. I'm coming off Delphi development, and in
contrast, waving the Task Manager window in front of my Delphi app
(whose main window is mostly a large canvas with hundreds of drawn
elements), I barely reach 10-20% CPU utilization -- and in Delphi, I did
not have to double-buffer the canvas -- nothing flickers, and no trails
of the waving window are apparent.
-Tom
Joe Huber wrote:
I think it's easiest to understand if you break the problem into two
scenarios, and you need to support both:
1. Paint event driven updates:
....
2. Application driven updates:
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
