Off Main Thread Compositing (OMTC) and why it matters

Like most desktop applications, Firefox is driven by an event loop. Currently this event loop is servicing a lot of events including page layout, drawing, image decoding and don’t forget JS. We do our best to handle events quickly (in a few milliseconds) and break up the ones that we know will take longer (such as image decoding). Any event, such as poorly written JS, that takes too long to process will cause the application to feel sluggish and will cause updates, animations and videos to pause.

Every web page is broken into a set of layers (backgrounds, canvas, video, web contents, position fixed element, elements that are being animated) by our layers system. When these layers are updated they must be flattened to the screen to show a final frame. This process is called ‘composition’. Currently this composition is driven by the main event loop. While compositing does add more load to the event loop from my experience the load it adds is often negligible. After all with hardware accelerated layers backends the work is mostly just queuing a few simple graphics command to the GPU.

Simplified painting pipeline (Desktop Current)

So why move compositing to a second thread if it’s relatively cheap? Because we need the event loop to be responsive to service composite events and any slow events (>15ms), such as a long JS script, will cause us to drop frames. By compositing on a separate thread we can still service layers update and keep the browser partially responsive even if the event loop is momentarily blocked by a long running script.

Simplified OMTC painting pipeline (Fennec Beta)

There is one catch however. If the main event loop is being hogged by an event then that will block certain updates, like page reflows, from reaching the compositor. However other types of updates can still be made while the main event loop is bogged down such as video which we decode in yet another thread, css/gif animations and plugins to name a few. Another use case is to support smooth panning and zooming on mobile. The goal we’re aiming for is to make Firefox more responsive.

The feature just shipped into the latest Fennec beta and provides a smoother experience while consuming less resources.

Simplified OMTC painting pipeline (Desktop/Fennec Future)

In the future we plan on landing more changes that will leverage this new architecture. We are considering many proposal shown above. Some are uncertain at this point such as having canvas workers. Right now our current focus is passing decoded video frames directly to the compositor and handling simple CSS animation asynchronously. These features will allow video and animations to perform smoothly over short periods of blocking similar to async scrolling on Fennec. We’re hoping to have some of these features landed in Q2 for mobile and desktop where OMTC will likely still be behind a preference until later this year. Stay tuned to these bugs to try out these features when they land.

About these ads

25 thoughts on “Off Main Thread Compositing (OMTC) and why it matters

  1. Pingback: Native Firefox for Android Beta | lucasr.org

  2. Pingback: GFX Changes in Firefox 13 « Benoit Girard's Blog

  3. Pingback: Splitting up the work for the UI thread | FunctionSource Development

  4. Pingback: Mobile Firefox: Measuring How a Browser Feels | William Lachance's Log

  5. Pingback: Video Synced Profiling « Benoit Girard's Blog

  6. Pingback: Multiprocess Firefox | Bill McCloskey's Blog

  7. Pingback: Firefox for Android in 2013 | Lucas Rocha

  8. Pingback: Firefox 33 Find out what is new - gHacks Tech News

  9. Pingback: Lucatarik | Firefox 33 Find out what is new

  10. Pingback: Firefox 33 on julkaistu – täältä saat sen heti ladattua - mustapekka.fi

  11. Pingback: Firefox 33 on julkaistu – täältä saat sen heti ladattua | Iltapuuro

  12. Pingback: Firefox 33 arrives with OpenH264 support, sending video to Chromecast and Roku from Android | 381test

  13. Pingback: Firefox 33 ya disponible con WebRTC y streaming en Android

  14. Pingback: Релиз Firefox 33 | AllUNIX.ru — Всероссийский портал о UNIX-системах

  15. Pingback: Mozilla Firefox 33.0 正式发布 爱玩软件 | 爱玩软件

  16. Pingback: Firefox 33 Find out what is new | vpsdash

  17. Pingback: Navegadores Firefox 33

  18. Pingback: Firefox 33 arrives with OpenH264 support, sending video to Chromecast and … – VentureBeat | Best electronic online

  19. Pingback: Firefox 33 steht zum Download bereit | Software news

  20. Pingback: Firefox 33 Find out what’s new | Windows8to9

  21. Pingback: SeaMonkey 2.30 est sorti » MozillaZine-fr

  22. Sounds good tho complicated. I tinkered with a related tho far simpler coding problem on a Commodore years ago to get a homemade text editor to achieve snappier performance without glitches, running the main program thread and the interrupt thread handling the keyboard. Two other sources of slowness not mentioned in this article are network delays and either thrashing or cache cleaning. While the program is waiting on a network response, and waiting, and waiting, it could be doing something useful instead of constantly checking for the network response in a tight loop. By the way, the stop-key testing should be in those tight loops so it will actually stop an attempted action. If the cache exceeds the max, the program stops and cleans the cache, when it would make a lot more sense to wait until program exit to downsize the cache or at least until a time of low total system activity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s