Snappy, Apr 5: Snappy Goals for Q2

It is time to set goals for the next 3 months at Mozilla. A lot of them should be Snappy-related.

As I mentioned before, we have made a lot of snappy progress lately. We identified a lot of problematic areas, fixed some of them and the end is in sight for others. It is extremely important that we maintain the current Snappy momentum, such that we can wrap up Snappy this year and move on to scaling Firefox on multiple cores, etc.

The following platform goals have been proposed:

  • Graphics: More rendering off main thread (this work is split between graphics/layout), Fix GFX acceleration lag (not yet on wiki)
  • Layout: More rendering off main thread (this work is split between graphics/layout), Invalidation via DisplayList Analysis
  • Video: Off main thread rendering (not yet on wiki)
  • DOM: Prevent [to a reasonable extent] background tabs from starving the main thread, Reduce CC pauses significantly when there are cycles to collect
  • Perf Team: Async local storage via blocking pageload, Combine IndexedDB/LocalStorage quotas to allow indexeddb to remove prompt, provide js file api (in workers) for all supported platforms, Reorder xul.dll on windows to speed up startup, continue exit(0) progress
  • Networking: Resolve listed high priority cache locking/async issues
  • Firefox: Fix top three Snappy offenders – lightweight themes, add-on manager, main thread SQL (under discussion, not on wiki)

We do a lot of work outside of our goal process, so above goals represent only the big ticket items that we’d like to see accomplished in the near future. There will be other snappy work going on too.

This entry was posted on Thursday, April 5th, 2012 at 1:16 pm and is filed under snappy. You can follow any comments to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

2 comments

  1. Ed
    April 5, 2012 at 10:13 pm

    A lot of these are ongoing (supersnappy) work, does that mean we should expect all these to be land within next 3 months…. ?

  2. pd
    April 6, 2012 at 4:35 am

    Reading b/w the lines, Firefox has been exactly what it seemed to be for years: a single-threading, laggy UI -blocking, chrome-hanging bloated program driving dedicated users nuts! Combine poor threading with the memory issues that have taken MemShrink so much work to improve and really, it makes a mockery of all the UI changes Firefox makes. Oooh Chrome has curvy tabs, we need Australis!

    The core issue has been performance and that is the biggest reason – amongst many – that people have jumped ship to Chrome

    I really hope that the long timeframe you suggest – Q1 2013 at the earliest – to get all of the more dynamic threading and multi-core scaling isn’t too late but I highly suspect that it might be. Hope I’m wrong, or that you dump priority on B2G or somewhere else and give this Snappy/MemShrink work the priority it deserves – first!