Re: [PATCH] enable double buffering on GtkCanvasPeer

[graydon hoare <graydon at redhat dot com>]

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

> The normal approach is a little less loopy:
>  1. createImage and getGraphics are only called if the window size changes
> (or once at startup)
>  2. the in-memory image is only manipulated if something visible has changed
>  3. the in-memory image is copied to the on-screen graphics (using
> drawImage) every paint
> (as done in
> http://gcc.gnu.org/ml/java-patches/2003-q2/msg00512/DoubleBuffer.java)

ok. I've switched my Graphics2D to work this way using the
GtkOffscreenImage, adopting your patch to Component.java. strangely
this method runs *faster* than the native gdk_window_begin_paint_rect
call I was using in that Canvas patch. I wonder what gdk was doing
that I'm not. maybe a bit more thread locking on the window's
offscreen drawable stack? hmm.

anyways I'm faced with one small problem in this implementation: which
background color should I set the offscreen image to have? currently
it defaults to black, but it might be more in line with expectations
to assume the background color of the Component from whence the Image
was created (as the Component's internal Graphics2D initializes
itself). any preference? what's the normal behavior?

-graydon