Re: [PATCH] enable double buffering on GtkCanvasPeer

[graydon hoare <graydon at redhat dot com>]

Tom Tromey <tromey@redhat.com> writes:

> >>>>> "graydon" == graydon hoare <graydon@redhat.com> writes:

> This is ok, but I have one comment.
> 
> graydon> +  assert (w);
> 
> Shouldn't we use the glib assert macros here?  That is the more common
> style for gtk code.  Actually, some of these asserts are probably just
> redundant -- the gtk type-cast macros will complain if we do something
> wrong.
> 
> What do you think about that?
> 
> It would be cool if you and Tom Fitzsimmons worked out some standards
> for how the gtk peers should look.  This wouldn't have to be too
> formal, just a micro-decisions on stuff like this.  I'm ok with
> whatever approach you two agree on.

sure, I don't mind. I tend to write assert-heavy code so it's just
reflex, not a serious preference.

one way I notice my current implementation of Graphics2D diverges from
the classpath coding style is that I make a lot of *small* JNI calls;
my gnu_java_awt_peer_gtk_GdkGraphics2D.c file is mostly just
passthroughs, and I do most of the logic up in java land. similar to
the way SWT is built, I just made one JNI call for each call in the Xr
library.

if JNI is really super-expensive, I suppose I can turn this around and
move more logic into C, say by computing arrays of doubles and magic
integer code numbers up in java, and passing them down into the C. I
prefer not to, for aesthetics, and I don't get a clear number from the
oprofile measurements I've run so far. mostly it seems dominated by
libX11, but there's a peak in libpthreads too. maybe I'll add a
benchmark test and compare raw polygon throughput with 2 different
implementations.

-graydon