You can use the widget flag WA_PaintOnScreen to bypass the backing store on X11. However, I doubt that the backing store is the bottleneck (in the case of Maemo). See also my short post: http://ariya.blogspot.com/2008/08/qt-44-and-maemo.html. We just need to tweak Qt a bit so that it flies on 16-bit X.

Yes, that’s right, however, let me further explain which was the reason of this test.

From earlier tests we realized that we were losing a lot of performance due to the fact Qt paints to an off-screen QPixmap and then to the screen (to avoid flicker). Trying to find a faster way to do that, we found out that, as of Qt 4.4.1, it’s not using shared pixmaps at all, rather that that, all pixmap copies are relying on local sockets (XPutImage, as you said).

Before going into details on the reason why Qt is not using shared memory, we were wondering the potential XShmPutImage had on the device, given that, X11perf seemed like a good starting point.

Best regards,
Fleury

This benchmark is a bit pointless if you consider how technology works.

XPutImage will copy image from client to server using a unix socket (local connection), while XShmPutImage will not. Of course, after this copy is done, X Server still needs to copy it to framebuffer, but is the same for both.

The only case that would give XShmPutImage a bad impact is if you’re using small images with short lives. Again, this can be understood from technology: Shared memory always go through kernel (one cannot use malloc and its user-space allocator), which for security reasons need to zero the whole memory in order to prevent information leak.

Thus XShmPutImage implies one memset() and possible one more syscall per creation. But after you did that, you can benefit from full speed.

So you should try to use XShm from beginning. That is not the problem. The real problem is how to make Qt keep XShm images around for more time.

Evas does exactly that, and I introduced this with x11-16 engine, then the optimization was backported to x11. Evas does the same as Qt with its alien windows, just one X Window and thus just one XShm Image for the whole updated area, this area is kept around after some time, because during animations we do not want destroy it. After a given timeout, we idle_flush(), which will drop that image. Yes, we really drop the scene contents, that’s why we use less memory.