[maemo-developers] Can GTK+ make use of XSHM extension from MIT

[From: Bin Chen]

On Jan 11, 2008 11:46 PM, Eero Tamminen <eero.tamminen at nokia.com> wrote:
> Hi,
>
> ext Bin Chen wrote:
> >> 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?
>
> That detail depends on which theme engine you use.
>
> With maemo Sapwood engine all the currently required client widget
> bitmaps are at the X server side (at display bitdepth i.e. as 16-bit)
> and shared between all the applications.
>
> With pixbuf engine all widget images are in the application process
> as normal gdk_pixbufs (i.e. 32-bit) and converted to display format
> on each blit.
>
> Most other older theme engines draw things instead using bitmaps.
> Newer themes use SVG sources, but could cache them as bitmaps.
>
>
> > 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?
>
> Gdk does all image operations in 32-bits, N800/N810 display is 16-bit.
> Whether you use SHM or not can be of less concern than this from the
> performance point of view.

OK, so your point is because the convert process must be done on every
operation, so the performance will be bad? But I think if the XSHM is
used, at least the transfer overhead will be cut, right?