[499] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: Two more Gtk questions (fast frame rates and thread safety)
daemon@ATHENA.MIT.EDU (Raph Levien)
Mon Jul 21 16:04:05 1997
Date: Mon, 21 Jul 1997 13:02:34 -0700 (PDT)
From: Raph Levien <raph@acm.org>
To: Rob Browning <rlb@cs.utexas.edu>
cc: gtk-list@redhat.com
In-Reply-To: <87sox82n95.fsf@nevermore.csres.utexas.edu>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
On 21 Jul 1997, Rob Browning wrote:
> OK, I'll poke around. I assume that a gtk_image is not a normal
> XImage (not that anything about an XImage is normal). Probably some
> kind of RGB image. I'll see if I can figure it out from the code. It
> may be overkill for our purposes since our data is already subsampled
> to 3/3/2 when it comes in. Using a full blown 24bit RGB is excessive,
> but if gdk uses XShm (which we don't now) it could conceivably be
> faster anyway.
gtk_image is basically a wrapper around XImage. In general, to use it you
have to supply images in the bit depth of the underlying visual. Gsumi
has a three-way switch statement supporting 8-bit, 16-bit, and 24-bit
(packed as 32-bit) images.
GTK does include a generic RGB image widget (gtk_preview) which handles
the dithering, but it seems clear that's not what you want.
gtk_image does use XShm by default. One gotcha with XShm images is
keeping the image data consistent until the pixels actually get drawn on
the screen. The gtk_preview widget handles this by doing a gdk_flush()
call (a wrapper around XSync) after the gdk_draw_image(). This could lead
to some performance degradation. I plan to do some measurements, but
until then I have no idea how much. If the performance problem is severe
(which I think is unlikely), then there are other solutions.
Raph
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
