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



On Jan 11, 2008 11:46 PM, Eero Tamminen <eero tamminen 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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]