Operation: Smooth

Mozilla performance notes - a personal view

Firefox E10s Performance on Talos

| Comments

TL;DR Talos runs performance tests on Firefox e10s on mozilla-central, not yet on try-server. OS X still doesn’t work. e10s reaults are similar, with notable scroll performance improvement on Windows and Linux, and notable WebGL regression on Windows.

Electrolysis, or e10s, is a Firefox project whose goal is to spread the work of browsing the web over multiple processes. The main initial goal is to separate the UI from web content and reduce negative effects one could have over the other.

e10s is already enabled by default on Firefox Nightly builds, and tabs which run on a different process than the UI are marked with an underline at the tab’s title.

While currently the e10s team’s main focus is correctness more than performance (one bug list and another), we can start collecting performance data and understand roughly where we stand.

The Simple Story of activeTicks Telemetry

| Comments

Our story begins with a fair request: let’s copy the activeTicks value which we have for Firefox-Health-Report - also to Telemetry, and so bug 1106122 was born.

Now, activeTicks is quite simple - it counts the duration a user has been interacting with Firefox. It’s part of the Firefox-Health-Report (FHR), but since it would be super useful to correlate this value with other telemetry values (such as number of hangs, etc), and since Telemetry and FHR live on different Clouds, we wanted to have a copy of this number also at telemetry. Fair enough.

I found the activeTicks code and played with it a bit to understand how it works. It turns out to simply count the number of “time units” (5s) at which the user moves the mouse over Firefox or otherwise interacted with it. There’s only one place at the code which counts this value, and it’s at services/datareporting/sessions.jsm. Great - this appears to be a simple task then.

Tabstrip #5 - TART, Talos Stress, Smooth Scrolling

| Comments

Talos stress

Talos tsvg and tscroll are about to be replaced with tsvgx and tscrollx, respectively (bug 897054). The main difference is that the “x” tests stress Firefox by iterating animations as fast as possible, AKA “ASAP mode”.

The old tests were performing some animation and then report overall (or average per frame) duration. However, they were using intervals which were not stressing Firefox at all, making the results almost meaningless WRT svg/scroll performance, and rather mostly sensitive to timing changes.

Stressing Firefox exposed some issues such as paint starvation (bug 880036).

Hopefully the new tests will have better correlation to our performance. Joel Maher did (and still does) a lot of work on the Talos side of things with these new tests (a l-o-t!)

There’s a more technical explanation on this dev.platform post.

TART - Tab Animation Regression Test

After previous work which went into improving tab animations in Firefox, It’s time to put it into Talos. TART is implemented as an addon which works either stand alone or from within Talos. It measures frames intervals during different animation cases, and it works equally well on mozilla-central and on the UX branch.

Tabstrip #4 - Vsync, Newtab, Talos, Paint Starvation

| Comments

I’ve been slightly behind with my blog updates and there has been some great progress recently, so this post covers a bit more than usual.


Vsync has finally landed on Windows Nightlies not long ago. This means that Firefox will now synchronize its paints with the actual refresh rate of the monitor (if available), which is essential for properly smooth animations. This will work (and is enabled by default) on Windows Vista and later with DWM enabled (“Aero” themes). This also works with WebGL content such as Epic Citadel (demo).

Without vsync, Firefox uses 60hz refresh rate by default, which works relatively decently with 60hz displays, but fails badly at displaying properly smooth animations on monitors with other refresh rates (50hz on quite a few laptop displays, 100hz monitors, etc).

However, the current implementation synchronizes with the main display only, so if using a multi-monitor setup, Firefox windows on secondary monitors might not gain from this.

Private Firefox Sync Server in 5 Minutes

| Comments

Well, theoretically in 5 minutes.

The official python server is there. The instructions on this page are for setting up a small 3rd party weave (Firefox sync) PHP server which is compatible with current Firefox 21 and nightlies as far as I can tell, and which I started using on my own systems as a replacement for the Mozilla sync server.

I’m not associated with this server in any way, and I’m not a security expert. Use at your own risk.

The short version - with sqlite:

  1. Have a web server with HTTPS and php5+sqlite (if self-signed cert, make sure to permanently accept it before Firefox sync setup).
  2. Create a directory for weave (e.g. /var/www/weave), and put the files from this repository. Make sure the web server has write access to it (e.g. sudo chown www-data /var/www/weave).
  3. Browse to https://your.domain.com/weave/index.php (sqlite selected by default), click OK.
  4. The server is now ready and operational. Sync URL is https://your.domain.com/weave/index.php/ (note the trailing ‘/’).
  5. Once an account was created after setting up sync from Firefox, you can disable further new accounts registrations at settings.php (new pairings with existing accounts will still work).
  6. If using sqlite, make sure that weave_db is not accessible from outside (e.g. using .htaccess).
  7. If required, to reset the server and delete the accounts: delete weave_db and settings.php at the weave directory (and go to step 3).
  8. Migration to a new server: Unlink all devices (Tools>Options>Sync>Unlink), setup sync on one device with the new server, pair the other devices normally. If you don’t wish to share all items (Addons/Passwords/etc), make sure to click “Sync Options” at the setup/pair dialogs since it resets to default more than expected.

Tabstrip Animation Progress #3

| Comments

Quick update on recent progress.

Vsync from a thread

Following the first experimental vsync implementation on Windows (using GetVBlankInfo which is non-blocking and synchronous), I’ve been experimenting with another implementation which vlad suggested: Run a thread which uses WaitForVBlank (blocking until next vblank) and post the timing event to the main thread.

Tabstrip Animation Progress #2: Vsync, Newtab Page Rendering, Lightweight Theme

| Comments

Tabstrip animation - Progress #2

The previous post introduced the Tabstrip animation project, and some work which has been done so far. This post reviews some more recent related progress.


During the Paris snappy work week, Bas and I discussed animation smoothness, and specifically the default 60hz refresh rate which Firefox currently uses. We’ve conducted a very unscientific poll among some attendees at the meeting, and found out that 4 out of 9 laptops had 50Hz monitor refresh rate. The rest had 60. For those with 60Hz, the current refresh system is acceptable, even if not perfect (actually … Often, developers choose 60 Hz as the refresh rate, not knowing that the enumerated refresh rate from the monitor is approximately 60,000 / 1,001 Hz …), but those with 50Hz monitors will always get a very noticeable jitter during any animation.

Tabstrip Animation Project #1 - Introduction

| Comments

I’ve had few slow weeks during which I attended some personal matters. Hopefully I’m back in full steam ahead again.

Here’s a summary of recent events.

Tabstrip animation project

As part of the recent Performance team changes (1, 2), I’m now the tech lead for the tabstrip animation project. It’ll require some additional coordinations and regular blog posts, but otherwise, work continues as usual.

The goal of the tabstrip animation project:

Make tabstrip animations as smooth and as snappy as possible, both visually and perceptually, by identifying and removing bottlenecks, deficiencies, and perception issues. The ultimate goal here is 60 FPS on a recent Atom CPU on all platforms, with minimal delays.

So far, this work touched several different subjects:

Talos - Test in a Browser, Noise Detection

| Comments

Talos is a performance tests framework used by Mozilla. It’s invoked on every checkin to the main code repository for early detection of performance regressions. You can find many interesting talos notes on Joel Maher’s blog.

Talos tests are pretty simple - they perform some task within a browser, then report a completion duration (or a comma-separated list of those) via the tpRecordTime javascript talos call. Talos then logs and processes those values, tries to ignore the noisy bits, and comes up with an average and StdDev values (it also deploys a similar process over several runs of the same test) - which can then be compared to other runs of the same test on different versions/platforms of Firefox.

Run and develop talos tests - without talos

While updating tscroll talos test, I found that running the test in a browser outside of the talos framework could be useful. The page could be reloaded to re-run the test, allowing quicker iterations of the code. While this isn’t as sterile as the talos run environment, it’s still useful during development. This required substituting tpRecordTime with my own, and also displaying various statistics on the collected data.

I’m not the not the only one who deployed such tactics, and one can find commented out alerts and statistics calculation (which are not reported to talos) on various talos tests.

Help Wanted - Slow Touchpad Scroll in Firefox?

| Comments

Bug 829952 says that scrolling using the touchpad feels slow on some laptops.

Turns out that it’s quite hard to provide a consistent scroll experience on the various platforms which Firefox supports, due to many laptop and touchpad manufacturers, different drivers, OS configurations etc. We could have provided some (or a lot of) configuration UI, but the best solution would be to get it as good as possible out of the box.

And to do that, we need data - and you might be able to help.