Re: Can GTK+ make use of XSHM extension from MIT

[Bin Chen <binary chen gmail com>]

å 2008-01-10åç 17:40 +0200ïEero Tamminenåéï
> Hi,
>
> ext Bin Chen wrote:
> > I am not doing very detailed profiling against this, but by comparing
> > the frame rate in my player against using pure framebuffer
> > implementation. The performance difference is large. If not using
> > shared memory to transfer the decoded image data, obviously the
> > performance can't be good in slow machine.
> >
> > The GTK+ can draw pixbuf and image to the drawable, is there any
> > existing method for me to choose to force the low level gdk to use SHM
> > extension?
>
> If you have a local connection to X server it uses that
> (where it helps, setting up XSHM has its own overhead).
>
> Gdk handles images internally as 32-bits, the display is 16-bits.
> Conversion is done automatically when needed by Gdk.  Need I say
> more?
>
> It sounds like your use-case would be more appropriate to be done
> with libSDL (which also does automatic conversions, but can handle
> surfaces in display bit-depth if you've just asked it to do that).

Ok, let me make the things clear, the content in a gdk window includes
many widgets, such as label, entry, button. But from the perspective of
X server, this widgets are just bitmaps with the states updated by GTK+,
right?

Xshm will accelerate the client to server transfer for type of Image and
Pixmap, but the GTK+ use XCopyArea to update the bitmap, can XCopyArea
can benefit from the Xshm?

In more detail, I am using gdk_draw_image to draw an image to a gdk
drawable, will this benefit the Xshm?

Of course, my GTK+ built with Xshm enabled and from Xdpyinfo the Xshm is
enabled in X side.