nicalsilva

Firefox's user base is also full of old Intel integrated GPUs that don't support bindless. The day WebRender can start relying on it cannot come soon enough but it's a long way off.

(I'm the author of the blog post) Yes, WebRender could repack it's texture atlases. A lot of stuff of various sizes go in there so I would not want to rely on repacking large amounts of pixels frequently but it could, among other things, help with more quickly converging back to a single texture atlas after an allocation spike. To my knowledge WebRender cannot move data within a texture using the OpenGL version it's restricted to.

It's a matter of allocating time to implement the missing parts and get it to work properly. Right now the people who could do this are working on other things but it will get done eventually.

As pcwalton said, there is a whole lot of things on the web that are very cheap to render on a GPU if done right. For these things, a well tuned gpu renderer can easily outperform a naive compositor like what you can see in most browsers. All of the caching optimizations that one gets from a compositor can be incorporated in something like webrender (and some are, like glyphs and a bunch of other stuff). Right now webrender doesn't have all of the tweaks to avoid rendering the whole page when there is a small spinning throbber, but that will be implemented eventually (there is still a lot of work going into rendering the long tail of weird and specific things right).

Actually, Gecko's compositor knows the screen space invalid region and scissors out the rest when compositing. The invalid region is passed to the window manager. Chromium also does that although they settle for an invalid rect instead of region which is fair. There is an issue on file to do the same with webrender.

It depends. For a lot of web pages, the things webrender do are actually very simple and can be faster than Firefox's compositor even if there was no painting required. The expensive stuff like rasterizing glyphs are cached. The idea is that if we can render everything at a cost that is equivalent to that of the compositor, then the benefits of the compositing infrastructure aren't clear anymore. For sure there will be pages where the compositor would have been faster for frames where no painting was required, at the end of the day it's a new architecture with new tradeoffs, but the goal is to be overall (much) faster.

Let's clarify, WebRender doesn't do anything at all if nothing changed. If the content of the window is static then webrender won't wake your gpu up until it really needs to. There seem to be a confusion about video games needing to render at constant frame rate, but that is only the case in games where there is always something changing on screen. It isn't that uncommon for other types of games with more static graphics to not render if nothing has changed.

What? Whether or not a browser matters depends on the amount of people using it, not on whether you can install it on several operating systems.

I find that gtk3 themes are easy to tweak (and more so than gtk2 ones), have you tried to look at the (pseudo-)css and modify it to suit your taste?

Firefox uses GTK to draw native-looking widgets. Basically, Gecko passes an X11 pixmap to GTK2 the latter draws the buttons/scroll bars/etc. into it with xrender. This means that Firefox either has to do all of the rendering with xrender and pixmaps, or do an expensive read-back of the native widgets from the pixmap and draw other web content into whatever kind of surface it wants. The thing is, we really really want to move away from xrender. GTK3 has a slightly different API for this and can draw native widgets into any kind of surface that can be wrapped in a cairo context. So for Firefox, the most important part of moving to GTK3 is the removal of this dependency to X11 and xrender. Chrome (as far as I know) doesn't do native-looking widgets (and to be honest I would be happier if Firefox didn't either), so moving to GTK3 is not that big of a deal for Chrome because it doesn't use the GTK nearly as much as Fireox does.

Sure! This post is like an invitation to discuss the subject, right?

"over-engineering" was not the point anyway. The title is a lie. The point was: dont be afraid of making mistakes (Over-engineering and the likes) when you can afford to, so you can learn from them and aim at high quality discussions on HN.

I don't know about this particular series of comments, but I second him on the idea that often some comments on HN smell like "If I troll harder I'm gonna look cooler". It somewhat degrades the overall quality IMO.

For what it's worth, the rubber band thing having a patent on it, I am not sure shipping it in Firefox is only about implementing it. I do know sometimes patches wait in bugzilla for legal approval, and I do know implementing native-like features often involve much more work than most people think. It makes me a bit sad to see that people judge the entire browsing experience in term of how native it feels rather than how well standards are implemented and what actual features are provided (not the look of a scrollbar, which is a matter of taste and generates debates that don't interest me much). There is some work in progress for more UI smoothness in firefox. Using xul instead of native UI has its pros and cons, but reducing the dependencies between UI code and the OS-specific APIS enables Firefox to be available to many platforms which is valuable in my opinion. It looks to me like people in general prefer to complain on blogs and comments rather than doing the same on bug trackers were it is actually useful and where one can get feedback from the guys that actually know about the stuff.