Running x11perf on Maemo (N800)

Hi all, this post is about some benchmarks we did on Nokia’s N800 device to measure the performance of XShmPutImage on this hardware.

I’ve been working on the QEdje project and, while studying possible optimizations, our team was interested in measuring whether we could benefit from using MIT’s X11 shared memory extensions. Among other tests, I managed to run x11perf on the N800.

A simple patch was needed before cross-compiling it. This because this app has a hard-coded window size of 600×600 pixels, more than what’s available in our 800×480 screen, thus leading to a X error message, complaining about get screen parameters.

I also reduced the square side size from 500 to 400 pixels in the XShmPutImage and XPutImage tests (shmput500 and putimage500).

The results were absolutely favorable to the use of the shared memory extension as you can see below:

./x11perf –shmput500 -sync

800 reps @ 8.6566 msec ( 116.0/sec)

./x11perf -putimage500 -sync

360 reps @ 14.8336 msec ( 67.4/sec)

For those willing to reproduce the tests, the patch is available below and should apply cleanly to x11perf 1.5.

Download x11perf 1.5 patch



5 thoughts on “Running x11perf on Maemo (N800)

  1. 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.

  2. Hi Barbieri,

    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,

  3. Pingback: Recent Links Tagged With "maemo" - JabberTags

  4. Pingback: qpixmap -

Leave a Reply