mozilla on directfb

Over the last few months some of our contributors have been hacking away on trying to get Mozilla running on directfb systems on top of gtk. You can see Niranjan’s latest post on the topic here as well as the DirectFB Porting Page in our wiki. Sounds like they have things mostly up and running at this point.

There are some patches required to some of the GNOME stack to get things up and running. The patches are up on the page.

Good work, guys!

This entry was posted in Embedding, Firefox, GNOME, Linux, Mobile, Mozilla. Bookmark the permalink.

6 Responses to mozilla on directfb

  1. daniels says:

    On that note, if there’s anything X can do to be a better embedded citizen, please let us know. I’m not overly concerned (obviously there’s a fair bit of work to be done, but only assuming one person doing it part-time) about its state at the moment, and neither is my employer or anyone I’ve talked to about it.

    Is there anything specific we could do better, if we take ‘enormous reduction in size’ as not only a fait accompli, but a continuous process?

  2. blizzard says:

    Daniel -

    In general we still recommend that people doing GTK also use X – it’s much more mature than the DirectFB stuff and works pretty well.

    In general I don’t think that size is the issue as much as it is performance. The closer we can get to the hardware the better and cairo + render is still pretty painful. We do a lot better on a lot of benchmarks (but not all) using direct framebuffer access vs. going through X.

  3. ajax says:

    Seriously? cairo’s using the same rasterization code as the X server for Render, and directfb is completely unaccelerated so you have to be hitting the software path. I suspect you’re seeing the cost of image transport more than anything else.

    I’d be fascinated to see a detailed benchmark here.

  4. blizzard says:

    I was mixing comparisons, sorry. Some things are faster on directfb (image access, others) vs. X and cairo and pixman are slow no matter where you go. :)

  5. daniels says:

    Hmm. Even so, we use SHM for image transport, so it shouldn’t be _that_ slow. I would’ve thought that any difference would almost be line noise, due to GTK doing its internal double-buffering anyway (unless it only does that on X, and not DirectFB).

    If there’s any profiles or even benchmarks you can share that point to hotspots we need to fix, again, please do let us know. :) It’s not all intrinsic in the design: some things we can fix in X, others we can fix in GTK.

  6. michael says:

    I notice some interesting Cairo stuff on the Wiki page you’re going to do. Would this eventually be part of all builds, i.e. this will affect the Linux desktop build? It sounds like it’s going to improve performance quite a bit (removal of cairo-xlib-utils makes baby jesus smile)

Leave a Reply

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

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">