Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-12

TAChart: double-buffering (issue 0012377) questions

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alexander Klenin

In issue http://bugs.freepascal.org/view.php?id=12377, reporter said:

Painting to an Bitmap and paint this on the Canvas would be much faster

This assertion is, of course, incorrect. I assume that the reporter's problem is actually that the TChart flickers when repainted.

The flickering is caused by two sources:
1) The TChart is TGraphicControl, so Parent control erases chart's background before every repaint.
2) TChart itself draws directly to screen, first clearing the canvas.

First source obviously needs fixing, and I attached to the issue a patch which fixes it.
The only caveat is that TChart is now TWinControl -- can it lead to some undesirable consequences I am not aware of?

The second source can also easily be fixed by double-buffering, but before I do that,
I have two questions:
1) TWinControl.WMPaint already contains double-buffering code, but it is protected
by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there some ongoing work to implement double-buffering globally?
2) If double-buffering will be implemented in TAChart itself, it will have some negative
performance impact. So, should I make it optional via DoubleBuffer property?

Alexander S. Klenin Insight Experts Ltd.

Reply by email

Mattias Gaertner
to Alexander Klenin
Show quoted text 17 lines
In issue http://bugs.freepascal.org/view.php?id=12377, reporter said: > Painting to an Bitmap and paint this on the Canvas would be much > faster This assertion is, of course, incorrect. I assume that the reporter's problem is actually that the TChart flickers when repainted. The flickering is caused by two sources: 1) The TChart is TGraphicControl, so Parent control erases chart's background before every repaint. 2) TChart itself draws directly to screen, first clearing the canvas. First source obviously needs fixing, and I attached to the issue a patch which fixes it. The only caveat is that TChart is now TWinControl -- can it lead to some undesirable consequences I am not aware of?

All direct TWinControl descendants must be implemented in all widgetsets.
You can use TCustomControl.

Show quoted text 7 lines
The second source can also easily be fixed by double-buffering, but before I do that, I have two questions: 1) TWinControl.WMPaint already contains double-buffering code, but it is protected by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there some ongoing work to implement double-buffering globally?

It was an idea to implement double buffering, but it does not work on all platforms. Gladfully most widgetsets have double buffering themselves.

2) If double-buffering will be implemented in TAChart itself, it will have some negative performance impact. So, should I make it optional via DoubleBuffer property?

Please try first TCustomControl.

Mattias

Reply by email

Alexander Klenin
to Mattias Gaertner
Mattias Gaertner wrote 7 lines
On Fri, 12 Dec 2008 19:38:55 +1000 "Alexander Klenin" wrote: > The only caveat is that TChart is now TWinControl -- can it lead to > some undesirable consequences I am not aware of? All direct TWinControl descendants must be implemented in all widgetsets. You can use TCustomControl.

Sorry, I mixed up the mail (but not the patch). I already used TCustomControl.

Show quoted text 7 lines
> 1) TWinControl.WMPaint already contains double-buffering code, but it > is protected > by {$ifdef BUFFERED_WMPAINT}. What is the reason of this? Is there > some ongoing work to implement double-buffering globally? It was an idea to implement double buffering, but it does not work on all platforms. Gladfully most widgetsets have double buffering themselves.

But, apparently, not Win32, at least on WindowsXP.

> 2) If double-buffering will be implemented in TAChart itself, it will > have some negative > performance impact. So, should I make it optional via DoubleBuffer > property?
So this question remains. Or should I protect double-buffering with
{$IFDEF WIN32}?
Alexander S. Klenin Insight Experts Ltd.

Reply by email

Florian Klaempfl
to Alexander Klenin
Show quoted text 8 lines
On Sat, Dec 13, 2008 at 11:46, Alexander Klenin wrote: > So this question remains. Or should I protect double-buffering with > {$IFDEF WIN32}? Since noone is commenting, I assume my patch is ok ;-) (http://bugs.freepascal.org/view.php?id=12377) Can someone review/apply it? It is again holding further TAChart work.

Just as a side note: http://florianklaempfl.de:8000/lazarustrunk/ is a mercurial mirror of lazarus. It might help you to maintain your patches. Mercurial works fine on windows as well and isn't a posix/unix centric hack as git is.

Reply by email