| RTL referenceGlossary|Tips/Tricks|FREE App/VCL|Best'O'Net|Books|Link To |
| GDI Graphics In Delphi | |||||||||||||||||||||
| Page 7: Four Ways To Kill Flicker | |||||||||||||||||||||
Four Ways To Kill Flicker 1) Use the DoubleBuffered property for TWinControl descendants Now for a really interesting fact: Delphi 4 and above introduce a property in TWinControl called DoubleBuffered, which is a boolean value. This allows you to do double buffering with one simple boolean assignment :-). The only drawback to double buffering is that it uses more memory. However, this is usually not a major issue unless you plan to go insane with your interface.
This ONE line alone in your form will reduce the flicker if you plan to use the form's canvas for drawing.
The next technique involves using the ControlStyle set for any TControl. You can bung this into the constructor of any object you write (e.g. any descending from TGraphicControl, in particular), or you can use it to set stuff at run-time for other controls. Anyway, it looks like this:
This means the program realises the control should not have its background erased, as it will be opaque and doing so would cause flicker. A nice, easy technique. However, you should only use this for non-transparent controls (which is usually most of 'em).
Next up, there is a way to massively decrease flicker: handle the WM_ERASEBKGND message. This message gets sent by Windows whenever a window needs to have its background erased. However, if you plan to draw the entire background then this just causes LOTS of unnecessary flicker. To stop that, bung in this message handler prototype:
Add that somewhere in your form or classes prototype (the bit at the top of your unit, within "{ Private Declarations }"). Next, add in this code in the implementation section:
I shouldn't need to say this, but replace the T< The help for WM_ERASEBKGND says that if you handle it, you should set the result to a non-zero value. That's all the above code does. Make sure with this technique to draw the background fully. If you don't, Windows gets all huffy and sometimes explodes. This, by the way, is not an exaggeration - I have actually managed to reduce Windows to a crawl (more so) and/or actually hang the system by not drawing anything in my OnPaint. Not good.
Off-Screen Bitmaps Why is double-buffering good?
Double-buffering is very straightforward. If you, for example, drew some lines onto a form's canvas, like this:
...then to do double-buffering, you would create a bitmap and draw onto its canvas instead, then copy the results to screen - much like this:
That's as easy as it gets. Instead of using the form's canvas, you use the one on the bitmap instead. Then, once you've finished, you use the form's Canvas.Draw method to copy the bitmap to screen. Nice and easy. Note, if you're interested in demos, that some tutorials refer to this as using a 'virtual screen'.
A comment to be made here is that you should consider creating the bitmap at start-up and freeing it when the program closes (in FormCreate and FormDestroy). This would be quicker than creating a bitmap for every Paint procedure, of course.
Question, Suggestions... Next page > GDI, The Hard (Win API) Way > Page 1, 2, 3, 4, 5, 6, 7, 8, 9
|
|||||||||||||||||||||
All graphics (if any) in this feature created by Zarko Gajic.
| More Delphi |
|
· Learn another routine every day - RTL Quick Reference. · Download free source code applications and components. · Talk about Delphi Programming, real time. · Link to the Delphi Programming site from your Web pages. · Tutorials, articles, tech. tips by date: 2001|2000|1999|1998 or by TOPIC. |
|
· NEXT ARTICLE:
Articles. More Delphi articles |
| Stay informed with all new and interesting things about Delphi (for free). |
|
|
| Got some code to share? Got a question? Need some help? |

