Re: [PATCH] enable double buffering on GtkCanvasPeer

["Scott Gilbertson Onsite" <sgilbertson-onsite at cogeco dot ca>]

AWT programmers are used to double buffering in Component subclasses, rather
than having the peers do it, as shown in the test program attached to my
"xlib double-buffering support" patch:
http://gcc.gnu.org/ml/java-patches/2003-q2/msg00512.html
I don't think this patch has been comitted yet.  Swing programmers are of
course used to being able to simply turn on double buffering for a
JComponent, but I think under the hood swing does things roughly like my
example (i.e. does it in java, in the JComponent class, which ultimately
subclasses Component).  It's possible some programs rely on the peers not
double buffering everything.

For the gtk peers to take advantage of my patch, you'd just have to make
sure the gtk ComponentPeer's createImage (int width, int height) method
returns an image which implements getGraphics and can be painted onto a gtk
window.   I don't know my way around the gtk peers, but at a glance it looks
like much of what you'd need is already there.

If the gtk peer double buffers everything, as I assume it does with your
patch, and you compile a program which has double-buffering in java, you'll
get triple buffering.  I don't think that's a problem (so long as the user
doesn't mind wasting a little memory and running a little slower), but I
thought I'd point it out in case someone feels differently.

----- Original Message -----
From: "graydon hoare" <graydon@redhat.com>
To: <java-patches@gcc.gnu.org>
Sent: Friday, July 18, 2003 11:31 AM
Subject: [PATCH] enable double buffering on GtkCanvasPeer


> hi,
>
> this patch enables GDK's double buffering on the canvas peer, so that
> it behaves like a "normal" flicker-less GTK widget when you paint into
> it.
>
> ok?
>
> -graydon
>
>