Opera goes to BlinkOn 3
Recently, the Opera Web Technology team attended BlinkOn 3, the twice-yearly conference for Blink contributors. (Videos are available on YouTube.) As you may know, Opera is a prolific committer to Blink, and has the only non-Google API owner and Chromium Security Group members.
Here are a few notes and observations from our team.
A year ago, a “mobile first” policy was formed. Now that has been replaced by a policy about enabling web developers to do whatever they want. Part of that is to keep landing new APIs that give more and more access to hardware/OS features and to avoid having slow code that prevents web apps from being smooth.
A main Google Blink focus for the next year will be never slipping on 60fps and its per-frame timing budget.
60 frames per second
Slimming paint seems to move along nicely. Looks similar to our “Eliminate-paint-traversal” project in Presto.
From the animations talk: inspector support, new features from Web Animations which have been implemented and will be implemented. They stressed that there are still only two properties (opacity, transforms) being animated on the compositor thread so we need to continue improve performance in the style → render tree → layout → composite → paint pipeline for main thread animations. They specifically highlighted our optimization for skipping style matching during animations as an example of such an improvement.
Project Warden meeting: it’s an ongoing project to improve hackability of Blink and it spans various unrelated tasks. They’re looking for volunteers to take on a re-design of line layout, in particular for security (tends to crash), but also for performance.
We had interesting chats with Nat Duca about style performance, and we discussed the state of the style part.
The Blink scheduler has promising results. That was something we talked about in BlinkOn2 (based on ideas from Presto). The idea is to have some code that actively decides what to do next (i.e. handle input events) instead of doing everything in the order they were queued or in 100 parallel threads. The main problem will still be to get rid of long running tasks on the main thread or that hogs the active CPU core and we’ll never be able to handle input within the 100 ms we need to. But the Android team in London has added metrics and some code and already there are measurable improvements which indicate that this is the right idea.
“UI workers” is currently an interesting experiment on allowing some programmability/scripting to the compositor thread.
Oilpan (replacing a messy ref-counted DOM environment with a garbage collected one) is also proceeding, but it’s a big knife in the middle of the Chromium guts, so lots of nervousness and attempts to figure out hard requirements before it can be enabled for performance-sensitive code. Oilpan presented preliminary performance numbers and plans for shipping. It was given a fair hearing, but has been given fairly hard targets and a deadline (end of 2015Q1) to meet in order to ship.
We met with the Oilpan team to set out how to go about making that happen, and I think we now have a workable plan in place. Oilpan is something we want to see Blink move to and adopt fully. It is just a more solid foundation to build a quality engine on top of. The project is now run by developers from the Google Tokyo office, with help from Opera. Optimizing overall performance and bounding/controlling garbage collector pause times (i.e., you don’t want your UI and animations to stutter due to Oilpan) are the remaining work items. During BlinkOn3, it was decided that Oilpan will only be fully adopted by Blink (“shipped”) when there are zero regressions on performance metrics, which cover pause times and overall fps / runs per sec. This needs to happen by the end of 2015Q1.
Work/effort on V8 is picking up. One aspect is bringing up its language support to ES6, which has been talked about as a goal for a while but seems to be happening now. (ES6 will be published/finalized in June 2015.)
Crankshaft is being replaced by TurboFan. An initial goal for TurboFan is to address the “asm.js use case”, meaning it wants to derive just as good type information and generated code as an asm.js validator and backend would when given asm.js input. But not without recognizing the asm.js type rules specifically, just by being a better all-round backend for JS/ES6.
- The ServiceWorkers shipping efforts are going to plan.
- The merge of Chromium and Blink repos is moving forwards again (Having them divided costs a lot of time). It’s gated on even more bot capacity.
- Work on Skia proceeds: more high level optimizations and more work on DisplayLists.
- Reducing the number of code paths for shaping and rendering text. There are now ~2 left. Goal is to remove the Latin-only code path as soon as the generic code path is fast enough. Optimizations in this area have made for instance Russian text rendering twice as fast (apparently it was very slow for non-ASCII before).
- Yandex wants to improve search in text so that it can find words better, and so that alternative word forms are found (e.g. search for “glanced”, get a hit on “glancing”).
- Out of process
iframes proceeds. It’s a security feature but it complicates the code. They have been working for a long time but there seems to still be a lot more to do.