As part of the Content-Performance program, we recently completed an extensive test of scroll and navigation performance comparison using 20 top sites between 3 browsers on Android (5.0.1, Galaxy S4): Fennec 43 Aurora, Chrome and “Internet” (the default browser on the S4).

• In general, Fennec scrolls worse than Chrome, especially on non trivial pages. But there are other issues too. We filed the following bugs:
  • Bug 1217415 - Fennec page navigation is slower than Chrome on some sites (e.g. Wikipedia, ebay)
  • Bug 1217372 - Fennec has text input lag in autocomplete boxes (google, bing) which Chrome doesn’t.
  • Bug 1217370 - On fast scroll swipes, sometimes the momentum is less than expected (and less than Chrome).
  • Bug 1217364 - Inconsistent scroll progression (momentum) without user inputs.
  • Bug 1217366 - Visible low resolution rendering, especially for fast swipes.

Hopefully, at least some of the scroll issues would be resolved or at the very least improved once Fennec gets async-pan-and-zoom (APZ). APZ is expected to land soon on Fennec nightly 44 before it becomes Aurora (on Firefox-desktop - APZ is already enabled by default on nightly builds).

Content-perf observations

Also on the subject of content-perf, we’ve recently filed quite a few bugs for desktop Firefox which were observed throughout our experiments. Vladan also blogged about it here and more recently here.

However, the bugs which we filed usually relate to specific cases or issues, but don’t expose non-issues, i.e. cases where Firefox is similar or better than other browsers, and they also don’t expose the scope of the experiments and the big picture in order to better assess the weight of the existing issues, nor do they expose general observations which were made.

To address this, we created a content-performance observations page. This page summarizes all the experiments which we performed, including their scope, procedures and observations, for both Desktop Firefox and fennec.

Let us know if you have any feedback on existing experiments and results, or suggestions for more experiments on either Desktop or Android, especially if there are no existing bugs where such discussion could take place.

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.

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.

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.

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

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.

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.

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

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.

Vsync

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.

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 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.