Archive for December, 2011

Obituary watch

Thursday, December 8th, 2011

Marco writes an obituary for Firefox:

I’m a bit sad for Firefox. It used to be the fast, powerful, progressive browser that finally broke IE’s era of stagnant dominance and saved web developers’ sanity. Now, it’s a bloated, slow, unstable monster that’s often a pain in this web developer’s ass.

Siegler nods in assent. It’s funny to me because in my sphere Firefox is alive, full of new life due to efforts like memshrink and Jaegermonkey. The stability cry also rings hollow; this is a non-issue for me.

Then again, I have a few tricks up my sleeve that you may not. For web developers out there who love Firefox and its mission but worry about the bloat, I have a few suggestions:

  • Try the Aurora or Beta channel to reap some performance benefits.
  • Be stingy about your extensions. Mozilla is only beginning to address the tip of the iceberg that is extension performance, but for you, know that performance can be dramatically affected by them. If you’re using Chrome now, you’ve probably paired down anyway; try being zen about Firefox and you might be surprised. The same goes for plugins.
  • Speaking of extensions, Firebug is one of the worst offenders for bloat. There were several memory leaks fixed recently that you may not know about, and I recommend using the latest and greatest here as well. Or: try some of the built-in developer tools that the Aurora channel now has.
  • If you crash, be sure to look at about:crashes. If you report it, an issue will be created and you can check out any progress on it. In my experience, it’s usually Flash. If you are worried about bloat, keep an eye on about:memory.
  • File bugs! Firefox is a community effort, and web developers have a responsibility for the future of the web. If you don’t want the big three (Google, Apple, and Microsoft) in a room deciding where the web goes next, Mozilla is truly the one voice that continues to make a difference in these discussions.

Tags: , , ,

Prevent text flashing on Safari

Tuesday, December 6th, 2011

Two months ago, I left my job at Mozilla to tackle an emerging challenge on the web today: getting peer-to-peer video chat right. I have transitioned from C++ browser platform work back to web technologies. It’s thrilling to reap the benefits of all the progress we’ve made in the browser over the past few years. It may not be perceptible to web developers who have been in their element for the last three years, but it’s striking to me how much the needle has moved. One thing that has not changed: all the crazy-ass browser workarounds!

Our designer pointed out today that Safari was re-rendering text when CSS animations were active. The affected text was not related at all to the animation. Putting a background color on the text block fixed the issue:

div.name {
  background-color: #e1e2e3;
}

I don’t know why this worked, but I have a theory. CSS transitions and animations are hardware accelerated in every browser today in some form or another. Every browser now has to balance complex rendering algorithms with performance, and sometimes they don’t get them right. For Firefox, we broke apart web pages into pieces called layers. The content of the layers were rendered in software, and at a later point all the layers are composited using hardware acceleration to give us what we see on our screens.

Does Firefox create a new layer for every single block element? No. There is a cost to creating a layer, so Firefox keeps layer creation cheap and makes them on the fly, for instance, when CSS animations are running. When it creates this new layer, the software renderer has to repaint some elements on the web page. The final bitmap dimensions change because the larger paint has been broken up into two paints that will be composited together. Good text rendering is heavily dependent on subpixel positioning, so if you aren’t careful the aliasing calculations will subtly change when rendering text.

Safari does something similar through the Core Animation framework, so my guess is that setting the background color changed the regions that the software renderer painted and stopped tickling the bug. Background color permits Safari to paint that div to an opaque ‘layer’ instead of a transparent one, or so it goes in my head.

Tags: , , ,