Re: [gtk-list] Re: Two more Gtk questions (fast frame rates and thread safety)

[Raph Levien <raph acm org>]

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