Re: [PATCH] enable double buffering on GtkCanvasPeer

[graydon hoare <graydon at redhat dot com>]

"Scott Gilbertson Onsite" <sgilbertson-onsite@cogeco.ca> writes:

> 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.

hm. yes, it appears you're right. I thought it was just an omission in
the normal AWT component model (notably corrected with
JComponent.setDoubleBuffered()), but it appears the GtkComponent
actually has a specialized GtkOffScreenImage dummy subclass of Image,
for just this purpose.

the main problem with having GtkComponent.createImage() and
GtkOffscreenImage.flush() control double buffering is that, for most
peers, double buffering is *already enabled*. so turning it on again
in those cases would be very ugly; it would make the foreground image
of the widget disappear. maybe that's "doing the right thing" though?

the canvas is imho a special case, because it is not peered with a
normal (double buffered) GTK widget, but a GDK drawing area. I guess I
can override createImage, and make the image returned by
GtkCanvas.createImage() be the special double-buffer-managing one, if
it's seriously the case that most AWT programmers will write this:

class myComponent extends Canvas
{
        void paint (Graphics g)
        {
        Rectangle clip = g.getBounds ();
        Image im = this.createImage (clip.getWidth (),
                                    clip.getHeight ());
        Graphics buf = im.getGraphics ();
        buf.draw( ... );
        im.flush ();
        }
}

when they want double buffering. it seems completely loopy to me, but
maybe that's how it's done. or is the final transfer from the
offscreen Image usually done with a separate paintImage() call on the
main graphic? in that case I could recognize the incoming "special"
GtkOffscreenImage using instanceof, and just pop the Gdk drawable
stack.

my main interest is in keeping RENDER drawing on the server, moving
between server-side pixmaps, not doing a pixel-copy back and forth
with the client.

-graydon