Announcement

Collapse
No announcement yet.

There's Interest Again In Embeddable Gecko To Better Compete With Chromium CEF

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Daktyl198 View Post
    azari Great post. There's just one thing I'd like to point out: XUL is FAST. Much faster than any HTML5 Firefox (or Chrome for that matter) can render, which is why browser.html as a concept has never been brought up seriously before. However, with Servo's architecture, HTML5 is getting very close to XUL speeds. With WebRender finally pushed to master, it's probably a little faster at this point. Much more reliable, at the very least... and much less buggy.
    That's interesting. Why has the UI always felt so sluggish compared to the UIs of websites then? I don't think it's only lack of e10s because even on developer edition the UI still doesn't feel like it's as fast as what's going on inside the content area of the browser (although it's way more responsive in e10s for sure).

    I remember when they were porting Firefox to Android and they decided to get rid of XUL and make a native UI because of performance issues, and that's what gave me the impression that XUL was slow; given that a "native UI" on Android is still basically done in a high level language (Java), it gave me a bad impression of XUL. Could it be that XUL just doesn't thread as well or something, and thus feels less responsive even if the rendering speed is faster?

    I'd love to read more about the subject of XUL and browser.html, and the motivations/wins that come from the changes, if you have some blog posts on it or something.

    Comment


    • #22
      Originally posted by azari View Post

      That's because Firefox has not yet implemented multiprocess (e10s), they are working on it but it has been really difficult to do this without causing too much damage to the addons ecosystem; at the moment they're supposed to ship e10s with version 46, but even then there will still just be one content process and one UI process, it will take a bit longer for them to implement the resource management necessary to automatically spawn new processes and load balance them the way Chrome does. This is basically one of those "legacy codebase" problems that ended up requiring an insane amount of rework, but after years of work, it's finally close to fruition. (More details below in my response to SystemCrasher.)
      Again, I like Firefox and I like what the Mozilla team is trying to do, and I trust them with my privacy much more than I trust a company that makes its entire income through targeted advertising.

      But I've been running Firefox Nightly, which is Firefox 46, with e10s enabled and it's still not able to tackle Chrome for speed and performance - at least not on Linux. Maybe the situation is better on Windows. And to be fair to the Mozilla folks, Windows is the bigger market. But if Firefox 46 on Windows is like Firefox 46 on Linux, the battle is still lost and switching more resources to Servo seems like the right move.

      Comment


      • #23
        Originally posted by Michael_S View Post
        [...] I've been running Firefox Nightly, which is Firefox 46, with e10s enabled and it's still not able to tackle Chrome for speed and performance - at least not on Linux. [...]
        They are still only using one content process, so right now the only difference is the UI and content run in separate processes. As I stated previously, they don't have any resource management or load balancing yet to spawn new processes as-needed the way Chrome does. This will get solved eventually, but the problem is that getting legacy XUL/XPCOM addons working with e10s is complete and utter hell; a huge part of the WebExtensions project is about creating an extensions API that fits in better with e10s.

        In short, this isn't going to happen overnight, there are several milestones here; first of all, we need to see e10s ship in a release version, so that Mozilla can gather more testing/data in the real world; then they have to eventually get multiple content processes with some load balancing and resource management; and finally once they start deprecating XUL/XPCOM extensions and switching to WebExtensions, they will become free to refactor and cleanup internals that they have never been able to touch before.

        Servo doesn't magically solve any of this because the extensions migration has to be done for Servo as well, since there is no way in hell that Servo will be compatible with XUL/XPCOM, and yet that issue is what has kept Firefox back all these years; once you make it possible to alter the internals without breaking extensions, we should see a lot of progress there.

        Comment

        Working...
        X