Snappy, Feb 23rd

SUMO Problem investigation

There was an increase in negative feedback regarding Firefox 11 beta relative to Firefox 10 beta on SUMO.  Cheng and me will be analyzing SUMO reports to see if we can find a concrete regression or two in Firefox 11.

(One of the reasons this update is late is because I was digging through our telemetry data looking for something to correlate with user reports)

Cycle Collector + GC

Olli and Jan cooked up (as part of MemShrink?) about:ccdump addon for assist with finding leaks (bug 726346, bug 728669). See Jan’s blog post for more details.

Andrew is working on:

  • reducing how often cycle collector runs in worst-case scenarios, bug 710496
  • A fix that might increase the time between cyclecollector runs 10x, bug 728460, 728547
  • Triggering GC from CC less often, bug 727965

Bill landed incremental GC this week, bug 719492. Most users will not benefit from incremental GC until Bill finishes up handling frequent “corner cases” that end up disabling incremental GC.

DOM

Kyle is adding infrastructure to allow webpages to wait on local storage without blocking user interactions, see 729769.

Profiling

Vlad’s non-destructive chromehang got mostly r+ed, bug 712109.

Frontend

Livemarks will soon be async, bug 613588. What are livemarks? An example of a livemark is the bbc livefeed/folder that we used ship on the bookmarks toolbar. Turned out when we rewrote the UI to hide the bookmarks toolbar, the livemark was still alive and well, hogging the UI while doing disk IO. We took out the default livemark a few releases back, now the code is being converted so users with preexisting bbc livemark (or their own livemarks) don’t suffer accompanying browser lag.

Scrolling

Avi ported his smoothscroll logic to C++, Jared pushed it to the UX branch, bug 206438. If you are interested in fluid scrolling, give it a try, play with acceleration prefs to help us find optimal values. Once this is done, bug 629507 is next and then we get to tell the rest of the browser to not interrupt scrolling/etc in bug 712478. If any readers are interested in helping desktop browsers catch up to mobile levels of responsiveness, this is area is a good place to contribute to.

6 comments

  1. Just used about:ccdump to file a bug for an npr.org zombie compartment that has hung around for the last 6-7 hours.. =)

  2. I use everyday livemarks to check the news headlines (including Firefox) and i notice that with the new livemarks it takes a while to load each one (on my work i don´t have a very good internet conection so they take longer). I usually scroll thru my 20+ livemarks and now i have to wait a few seconds in each one waiting for them to load.

    Is should be a option to load everyone when i try so see the firs one so when i scroll thru the others i don´t have to wait.

    On the other hand, on the old version i had browser.bookmarks.livemark_refresh_seconds set to 600. Where do i choose the refresh interval on this new version?

  3. Open question: is scrolling really that much of a ‘snappy’ issue on the desktop or is this yet another mobile-prioritised fix?

    Personally I find things like text input constantly crawling and lagging whenever a developer puts any listeners on a text field as more annoying than scrolling. Just last night I was trying to comment on YouTube and it took several seconds for no more than half a dozen characters at a time to appear. As a web developer I know that adding JS to a text field – for example to provide “X characters left” feedback almost always makes the UX quite laggy. For such an elementary aspect of the modern web – commenting and form entry in general – is this acceptable snappiness?

  4. I have a folder on my bookmark toolbar with 20+ livemarks and throughout the day the day I frequently scroll thru all of them to see the news headlines / firefox development…

    With this new livemarks the first time I scroll thru them I have to wait in each one a few seconds (sometimes it takes longer and sometimes it´s fast). Is there a chance that when i load the first, firefox loads all of them? As it is it feels slow. Sometimes I give up because it takes too long. I realy like this feature, but I guess it´s no longer practical.

    In this new version, how do I set the refresh time? The default seems to me that don´t update so often like the old one. In the old livemarks I had Browser.bookmarks.livemark_refresh_seconds set to 300

  5. @jcpereira: livemarks change is one of those cases where, even if you improve performances for real, users won’t notice, cause they are not used to associate livemarks with network. A user already filed bug 731274 about similar issues, and I’ll evaluate what we can do to limit the issue likely in that bug. So you can cc yourself there.

  6. (Crosspost from mZ [1])

    Just an observation:

    My GPU died and I’m now using my motherboard’s integrated IGP (VIA/S3 Unichrome Pro) that is blacklisted from layers acceleration. I was afraid I had to look around for a relatively decent AGP GPU, primarily to run accelerated layers in Nightly (I mostly browse the web and play the occasional roguelike). To my surprise, even without acceleration, I can see no real performance issues at scrolling even complex webpages like The Verge. I can even keep using smooth-scrolling (that is more prone to “jank” since the page doesn’t move in increments).

    By comparison, trying to scroll complex document in Chromium is sloooooooow and janky.

    It seems like the Snappy team is doing a good job. Thanks for all the hard work guys!

    [1]: http://forums.mozillazine.org/viewtopic.php?p=11781065#p11781065