Hi,
Ok, I found what is wrong.
I thought that setting doubleBuffered on a Container is enough. But
unfortunately the patch applies only to the Component.paint
and Container overrides it with a method explicitly calling paint on all
the children, regardless it is doubleBuffered or not.
So the patch works currently only for child-level components. But
double buffering would be most useful on complex components containing
lot of subcomponents, e.g. whole frames (we save not only on painting,
but also on the whole painting logic like bounds calculation, etc.).
Best regards,
Piotr
W dniu 20.01.2012 15:35, Noel Grandin pisze:
note that you have to enable double-buffering explicitly on a
per-component basis.
On 2012-01-20 16:13, Piotr Kołaczkowski wrote:
Hmm,
Can't see a difference. But I have to profile it to see what is
causing the slowdown.
Thanks for the patch.
-- Piotr
W dniu 20.01.2012 13:53, Noel Grandin pisze:
Hmm, interesting idea.
This is a prototype patch. Try it out and let me know how it goes.
-- Noel Grandin
On 2012-01-20 11:09, Piotr Kołaczkowski wrote:
Hi,
Is there support for explicit double-buffering of components
(especially windows) like it is in Swing?
Currently I faced another performance problem - imagine a top level
Window with a one single Frame open in it.
The Window contains an animation, that needs to be repainted at >30
FPS. When I issue the repaint, not only the window gets repainted,
but also the parts of the frame that happened to be inside the
repaint region (if the user shadows a part of the animation with
the frame, the frame gets the repaints).
For complex Frames with lots of components inside them, it may be
slow. And it is not needed, because I actually haven't changed
anything inside the frame, so it is perfect case for double
buffering and drawing the whole frame with a single drawImage
statement.
So, is there a workaround now for this? Is this planned?
Regards,
Piotr
--
Piotr Kołaczkowski
senior consultant
Sages Sp. z o.o.
www.sages.com.pl
