Posted by: ben | April 26, 2010

GeeXboX at Embedded Linux Conference 2010

The CE Linux Forum organized the ELC (Embedded Linux Conference) 2010 session at San Francisco from 12th to 14th April. I had a 1h speaking timeslot where I presented GeeXboX, Enna, libplayer and libvalhalla. This was also followed by a 2 hours demo session where Davide and myself presented Enna on netbooks + Nokia N900 to various attendees and enterprises.

For interested people, my slides are available at:

And the video will be posted when available.

Those interested in all ELC conferences might take a look at:

So, what happened meanwhile this event ?

GeeXboX and Enna received a pretty good feedback from both the people attending the presentation than the demo. We also managed to draw contacts with many interesting people from various companies: Nokia, Texas Instruments, Samsung, Numonyx, AlwaysInnovating …

A lot of questions were raised, a few remarks too and in many cases, people had the same remarks or feelings (I do personally share many of them btw).

  • Most of the people were impressed by Enna on Nokia N900. Actually, most of people are interested by Enna on embedded devices (but that’s somehow normal due to expected audience), way more than on regular PC. Most people want it to run on ARM targets.
  • People were impressed by the very low footprint required. Numonyx folks consider it very useful with XIP approach.
  • Many people where very interested by libplayer actually. Its capability to allow user choose which backend to use seems to be very popular. Though everyone requested a GStreamer backend. I’m currently writing it but it’s definitely the way to go if we really intend to address embedded devices and enterprise-grade devices. It’s the only way to correctly handle DSPs atm.
  • Executives from Samsung were really interested by Enna itself. Actually, they knew about it before joining the stand. They wanted to know what was the difference with the enna from Enlightenment project (memo: Samsung hired the EFL main developer). They were happy to know that our Enna is the same as the one from E project. They also are very interested in it for their mobile phones (but not for the Bada project, or so they said) but were very disappointed by its very slow response time on N900. For the record N900 is running in software_x11_16 currently, the OpenGL|ES renderer being barely faster (if not slower) and produces garbage. I recalled them that they hire the man responsible of Evas and the renderers. Though it’s true and I confirm their feeling. I consider Enna as really really slow to draw anything (both on embedded devices and x86). No idea if its Evas issues or Enna bottleneck for we have slowdown issues. Though, from the expedite tests I did on N900, I’m disappointed by Evas performances.
  • People loved libvalhalla (or what it provides) and the capability to retrieve all metadata was really welcomed.
  • The biggest reproach done to Enna was the use of EFL instead of QT. Both individuals and enterprises (including Nokia obviously, but not Samsung, obviously too 🙂 would have recommended to use QT for its stabilized and documented API. The no-relases behavior, lack of documentation and unstable API of EFL was stated countless of times. Nokia shown us some small apps written using their new QML langage (EFL Edje equivalent) which is completely interpreted (but can be compiled) and I have to say the results were impressing. At first they have all necessary widgets (i.e. a completed Elementary) we need and the performances (on a regular PC at least) truely outcomes the ones of Evas-based applications (again while being interpreted). I asked us about OpenGL|ES performances and benchmarks (as it’s now my main point of interest) but they have no numbers to be provided (they however confirmed it to work fine). A lot of people also told us they would consider helping the project if it was QT written.


  1. This performance problem your are speaking about is really weird. Using EFL on many target, I can already tell you that it’s always running faster and consume less memory than other toolkit, and more improvements are coming.
    So perhaps you hit some bugs or slow path. Did you run enna through valgrind or did any benchmark ? Perhaps you are scaling image without the scale cache enable, or you just hit your GPU fillrate. If you want help on this issue, please don’t hesitate to post on the E dev ML with a scenario easy to reproduce to see why it’s slow.

    Regarding QT and QML, it’s not really fair to compare to Edje and the EFL, saying that they are not realeased, when QML is not yet part of a QT release, nor is it stable ! Don’t assume that QML == QT. It’s a young technology with limitation.

    By the way, I did some benchmark against Edje/Evas and QML/QT, and their is an order of magnitude speed difference.

    • I’d be really glad to see the benchmarks. Please post.

      Regarding Enna performances, I dunno yet if the real slowdown issue comes from Evas or Enna. I however proceeded with Expedite benchmarks on OMAP3 (Nokia N900 + BeagleBoard) and it’s pretty disappointing. I have to use software_x11_16 to have something usable. The software_x11 is slower (obviously) and opengl_x11 (with OpenGL|ES SGX enabled, after Raster’s optimizations) also is slower than software_x11 in most of the tests (so useless). I dunno if the problem comes from OpenGL|ES implementation or what.

      Also, Raster published some benchs a while ago regarding GL optimizations and his tests on N900 and I really have no idea how he supposedly managed to hit these performances. I measured 5x slower performances than he does (though he doesn’t say about the command-line he really used). This is achieved by using all possible GCC optimizations for ARM Cortex-A8 I can. Also using the EFL for ARM built from Raster, I obtain the same results than using my libs.

      Also btw, regarding Evas GL, I’d highly suggest to replace GL_NEAREST flags by GL_LINEAR. While this has no performance impact (on both GL and GL|ES), the display has a much much better look&feel (like anti-aliased).

  2. I am using the same GPU on another device, and I get the same performance as raster.

    Something just hit my mind, but the n900 comme with a composit manager turned on by default. If it’s badly writen (and my guess it is), it will really impact expedite performance in GL. Maybe, this is the source of the problem. And I don’t think that it’s related to the main CPU, as in OpenGL, it’s barely used.

  3. Thx for the bench.
    Do you have the associated command-line you used ? I’ll check for composite manager on N900 and the other device I have.

    Btw, have benchs regarding Evas/Edje to QT/QML in GL ?

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: