Framebuffer vs. X11

Putting some new fuel to the neverending fire — whether the (undebatable) performance drawback of using a full-blown window system like X11 outweighs the benefits in flexibility; Just recently I built the Expedite benchmark utility (from the Enlightenment project) for my Neo1973 (266MHz armv4, VGA display, unaccellerated framebuffer).

Thanks to the Evas canvas abstraction, Expedite has tons of rendering backends, including ones for the framebuffer and X11. And here are the results of the jury:

Expedite Benchmark Results

I this is is quite shocking (I expected the framebuffer to win, but not by that far). With an average frame-per-seconds of 17 for the framebuffer backend and 11 for the X11 backend, this looks like X11 introduces an overhead of about 50% on my platform.I wonder how the directfb and SDL backends would score — I’m going to do these eventually. I’m also curious in the results of Gtk+/X11 vs. Gtk+/fb as well as Qt/X11 vs. Qt/Embedded. I’ll do that once I have nice benchmark utilities for the respective toolkits.

Surely this result only applies to unaccellerated framebuffers, hardware-accellerated xrender may win by far, but this is what we don’t have right now. The question is, did we bet on the wrong horse here? Do we really need all the goodies X11 give us? Do we really need a windowing system abstraction on a phone? Do we really need to run multiple toolkits in parallel? What do you think?


  1. Ivo Anjo
    8. Dezember 2007 - Antworten

    Nice benchmarks =)

    Although the added performance seems very cool, I think that compatibility with standard X apps is great too, allowing you to use that must-have app that no-one ported for the platform, and to use other toolkits inside the ui (qt4 [standard, not embedded] comes to mind).

    Also, you just have to add xrender to the xserver and the whole platform is „ported“ instantly; choosing the framebuffer probably would make it harder to switch back to X11+xrender or +opengl.

  2. daniel
    8. Dezember 2007 - Antworten

    > Do we really need all the goodies X11 give us?
    > Do we really need a windowing system abstraction on a phone?

    One a phone? No.
    One a mobile communications device? I believe so.

  3. Stefan Schmidt
    8. Dezember 2007 - Antworten

    An idea that comes to mind is if it possible to have two different openmoko images. Our normal one and one that uses directfb-gtk.

    Of course a lot of work just for some testing, but it still would be nice.

  4. Lorn Potter
    8. Dezember 2007 - Antworten

    IMHO, the performance benefits of using the framebuffer outweight the benefits of „allowing“ multiple toolkits.

    Using „standard“ apps on a small screen is a myth. They are not designed for small screen and phone form factor. Usability changes on them. and to make best use of the small screen, they usually have to be redesigned.

    As well, you generally are not going to have more than one ‚toolkit‘ on a phone. With larger flash (and ram) sizes also comes increased energy requirements.

  5. Dan Aloni
    8. Dezember 2007 - Antworten

    I think X11 is a must have. We just need get that xrender support going.

  6. Stan
    8. Dezember 2007 - Antworten

    How are the different bars weighted together to give the final measure? It looks like performance discrepancy in „Image Blend Solid“ dominates the final answer, with most of the other operations having must smaller performance discrepancies. A 50% speed hit for X11 does seem excessive, but if the operations used by „Image Blend Solid“ can be optimized, then things could be much better. A 10% speed hit for X11 could be a worthwhile trade to give developers access to a familiar GUI environment.

  7. Alexander Larsson
    9. Dezember 2007 - Antworten

    The idea of using unaccelerated framebuffer output on any modern device is ludicrous. Basically all hardware has some level of acceleration, and using that for e.g. fills/clears and scrolling *far* outweigh any minor details wrt what protocol is used to trigger the drawing commands.

  8. Dominik Blystak
    9. Dezember 2007 - Antworten

    I think the x11 is a must. It allows you to port a lot of existing apps with ease. Although most complex guis have to be redesigned.

    What is with multiple desktops? On a workstation with a big screen you do not need this feature that much but on a small phone screen it may boost usability.

    Another great feature is the possibility of remote „desktop“ sessions. You can have your moko screen on your workstation and vice versa out of the box.

    I think leaving the path of the mainstream in this case would be a substantial mistake.

  9. mallum
    9. Dezember 2007 - Antworten

    Tests I’ve done in the past indicate raw fb blits being on average approx 30% faster than blit via X (over SHM – this doesn’t indicate if shared memory was used, which could well make up the 20% difference you are seeing)

    Its kind of like comparing a rally car to a road car, of course the rally car goes faster but which would you rather drive to work every day ?

    Dont under estimate whats needed in window system, blitting is the easy bit – events, multile clients, inter client communications, policy etc are the the hard things and the fb gives you none of them.

    My old tests are here;
    (also include gtk, gdk etc like tests also)

  10. Wertigon
    9. Dezember 2007 - Antworten

    „The idea of using unaccelerated framebuffer output on any modern device is ludicrous. Basically all hardware has some level of acceleration, and using that for e.g. fills/clears and scrolling *far* outweigh any minor details wrt what protocol is used to trigger the drawing commands.“

    But, you can have accellerated FB if the drivers to the GFX cards support it. See for more info.

  11. 9. Dezember 2007 - Antworten

    It depends so much on what you want. If you want a cool UI, with animations, the 10-30% performance increase of the framebuffer device will make it worth it dropping some ease of development. If you want a thoroughly unsexy, but feature filled, UI, like S60, you’d go with X and get lots of generic apps for free. Not that any non-hacker would be interested in having 10 different irc clients, but as I said, it depends on what you want.

  12. Bill King
    10. Dezember 2007 - Antworten

    I’ll take fb + a decent toolkit thanks. What most desktop developers (and it seems almost everyone commenting here) fails to remember is that more instructions = more power used. That 30-50%, that’s an extra 1/3 to 1/2 of my battery life thanks very much. A decent toolkit will help with the porting effort as Lorn is utterly right, desktop apps do not directly port to phone, they need redesigning. X does not „give you“ anything that a decent toolkit (or a necessary redesign) should already give.

  13. Ben
    10. Dezember 2007 - Antworten

    I’m leaning towards X:
    the kind of phone I would like to buy in the near future wouldn’t be one I can admire for its graphics, but one that can fit w/ the functionality/compatability of the computers I already have. My fav idea behind X is the rdesktop access. … just my opinion.

  14. 10. Dezember 2007 - Antworten

    Thanks for your contributions. Some first answers:

    I agree that adding accelleration to Xrender contributes much more to the free software world than adding it to, say directfb or SDL.

    @Alexander: Unaccelerated framebuffers — as ludicrous as it seems to you — are _very_ common in embedded devices.

    @Mallum: Nice analogy, however let me again question the need of a full windowing system on a phone or a set-top-box [A PDA or an internet tablet may be a different thing]. Why do we need multiple clients at all? How about one framework application and the rest is all shared libraries? Makes inter-client-communication fast and easy.

  15. Lucas
    11. Dezember 2007 - Antworten

    A good compromise I found for a touchscreen based POS system (using one of those VIA mini-ATX boards) was libggi. It allows to develop and test on X and have the same binary run under fb.

  16. starox
    11. Dezember 2007 - Antworten

    @Mickey :
    > [A PDA or an internet tablet may be a different thing].

    I think openmoko or iphone or nokia n95 *are* PDAs.
    The need is good interface, good software, and at first sight, it seems more easy to try, make or port several ui/soft with X based software.

  17. 11. Dezember 2007 - Antworten

    X11 allows you to use most of the existing toolkits and their language bindings. Think of Python, Java, Ruby, TCL,…

    Using X11 OpenMoko is open for every developer
    and allows for fast pragmatic development (and UI-porting of existing apps – which is needed, as Lorn points out).

    I only see power consumption as a drawback – though we should measure it first.

  18. Michael Krog
    11. Dezember 2007 - Antworten

    I really dont see how a window server, that already doesnt perform *incredibly* on a 3 Ghz PC with 2 Gigs of ram and a decent screen card, should ever be made to perform good on a small unaccelerated phone.

    When openmoko was first announced I was delighted. Finally a free phone OS. But – comparing its current performance to any other phone OS just doesnt cut it.

    In my (humble) opinion the eyecandy of this phone wont happen soon with an X server.

    Furthermore – Trash GTK as long as its performance and API stinks.

  19. Nikolaus Schaller
    12. Dezember 2007 - Antworten

    I do not see how you come to 50% overhead.

    Let’s take the highest peak: 30 vs. 23 fps. This means:

    fb 33ms
    X11 43ms = 33+10 i.e. 30% overhead

    So, the overhead is less than 30%. A 50% faster CPU will outweight this. And in one year we can have 100% faster CPUs.

    And, approx. 80% of the benchmarks have the same speed. So, why care about it?

  20. mickey
    12. Dezember 2007 - Antworten

    I left two tests out of the graph which had very high scores which would have ruined the scale. I’ll update the blog post on how to reproduce these tests tomorrow, so you can play with it.

    @Nikolaus: Even on faster CPUs, X11 will still be slower by about the same amount. And it’s not just about slowness, it’s also about power consumption, of course. And i’m sure you will agree with me that one can never have enough usage and standby time…

  21. Lame_Dude
    13. Dezember 2007 - Antworten

    Can we do not use X-windows?Yeah.But this will be sort of dumb lame dialer only.At very most, it will run couple of native graphic programs aware of framebuffer + maybe have.Hardly can be called a smart phone or communicator.Just dialer.Yeah, controlled by Linux.But still pretty useless brick not so far from these 150$ proprietary „dumb dialers“.Because you can’t for example expect to see featured apps (like Pidgin for example).So only dumb things are fast.On PC text-mode console is even faster when it comes to text output.So what?It’s also so boring…

  22. Wertigon
    14. Dezember 2007 - Antworten

    Lame_Dude: I’d hate to see, say, Pidgin as it is right now on the Neo1973. Why? Because the interface would *suck*. Not only would it take up like, the entire screen and then some, it’d also probably consume tonnes of resources. An application based on libpurple might be better suited, but then libpurple doesn’t have any dependencies on X (AFAIK).

    So, you’re left with either really good apps crippled and shoehorned into a format that obviously doesn’t fit too well, or fix the interface for those apps so they work well with the OpenMoko platform. If you do the later, might as well write a new interface while you’re at it.

    So I don’t buy that particular argument; I do however buy the argument that GTK, QT etc all exist for X with bindings in multiple languages. That in and of itself is worth quite some consideration…

  23. Paul Sokolovsky
    16. Dezember 2007 - Antworten

    Only by 50%?! Tests must be wrong! I’d expect 2-3 times real-world slowdown with all the byte-banging X does…

  24. Mr Nice
    17. Dezember 2007 - Antworten

    I like the idea of something like xynth [1] for smartphones.


  25. mokobits
    7. Januar 2008 - Antworten


    Lame_Dude: well, but there a port of GTK to directfb instead of X. Even Gimp runs without X! Also, Qtopia does not need any X related stuff (AFAIK). Maybe directfb increases the speed of GTK. Apart from QT and GTK, there are IMO not a lot GUI libraries which would need support anyway.

    The current OpenMoko interface on GTA01 feels veeheheery sluggish and I think performance needs to be improved alot (a 200MHz CPU should be able to do usual smartphone apps quickly, even my old m105 palm was able to do that!). Of course, optimization is the last thing to consider, … but here it would change alot in terms of usability.

    I have my neo-GTA01 in dualboot with QTopia on the SD-Card and (apart from the still not finished GTK Openmoko Desktop, but that’s ok), QT feels like a usable phone in terms of speed, whereas you can see the different drawing operations of GTK and you will become impatient very soon.

    To summarize, I really like to have an image of all the openmoko apps built on top of GTK/directFB, to test this combination (and I think it would be good for openmoko to have this feedback to know what to finally put on the market).

    Also, isn’t it possible to have a combination of GTK+directfb and an X server which would be optionally started ‚on another console‘ for those who really need their special X apps? If such a combination will be chosen, I do not see the reason for an additional X layer below the core OpenMoko apps at all.

    Maybe – ok, this is baad blasphemy I know – the Openmoko project would have a lot less headaches if they simply switch to QTopia.

  26. 13. Juli 2009 - Antworten

    30% here, 30% there. We think that is not a problem in terms of energy consumption, the same do the managers, politicians etc. It means 30% more waste. Multiplied with number of years and so on… It is a huge number… So better redesign now than later. We need to redesign several things on earth… And Xwindows is one of them 🙂

  27. 13. Juli 2009 - Antworten

    news… you may read the final tests on my blog… but openmoko is not slow due to X windows… I am convinced that 90% of slowness is due to other libraries… so first speed up those and then X windows…

Drop a comment

Your email address will not be published. Required fields are marked *