Ariya Hidayat (@ariyahidayat) works at Sencha and created PhantomJS and Esprima. He talked about front end web performance.
These are my notes from his presentation at W3Conf in San Francisco as part of this live blog series.
Oversimplified advice: “Use translate3d for hardware acceleration.”
Browsers are complicated: User Interface – Browser Engine – Render Engine – Graphics Stack – JavaScript Engine – Networking Engine.
Getting content to pixels is complicated too. Painting to the screen is only the last step in a long chain. We’re mostly familiar with the DOM Tree, but there is also a Render Tree.
Style recalculations are easy (e.g. changing background color). Layout changes are more difficult and thus slower / “more expensive” (e.g. changing positioning of an element). There are lots of properties that change layout.
There are varying expenses to different brushes/fills. No fill is easy, gradients are harder, textures hardest. This concept applies to all kinds of properties. For instance CSS transforms: scaling is easier than dealing with perspective.
GPU’s are optimized for games. Less-so for simple things like lines (Call of Duty doesn’t need straight horizontal lines). The web doesn’t have predictable content (like games do). The web is mostly text. Games are mostly images.
GPUs = Low memory; Lots of processing power; Data transfer is the bottleneck; Requires a good amount of power.
So how do we take a GPU that is optimized for games and use it on the web?
Fluid animation is a huge goal on the web. So: push as much of it to the GPU as you can. Less efficient = loop over and move a box. More efficient, put box in buffer and move buffer. Good example of this is Falling Leaves demo by WebKit. Makes it the job of the compositor to figure out where leaves are.
#w3conf @ariyahidayat: Animation mechanics → initialization caches images, then you only manipulate the bitmaps’ position etc.
— Faruk Ateş (@KuraFire) February 22, 2013
translateZ(0) isn’t needed if you’re already using animation.
- Doesn’t require re-upload to GPU = opacity, position, size, filter
- Does require re-upload to GPU = everything else (avoid!)
Cool things:
- Photon: CSS3 lighting Engine
- 3D CSS First Person Shooter
“It’s not just the speed of the car, it’s the traffic conditions.”
Avoid overcapacity.
If you change color, that’s one of the things that requires re-upload and thus isn’t great for performance. But there is a trick! It uses twice as much memory, but you can make it smooth.
More info on all of this: Jank Busters.
“Graphics programming is full of tricks. It always will be.”
He also demoed a useful feature of Safari: Enabling the Debug menu and turning Show Composition Borders on. Which showed the number of times a texture is sent to the GPU.
The Popcorn demo from the Montage team is a great demo of how smooth you can render a UI.
I was stoked to see that in his talk! :)
Chris, is there a video to this article? In viewing the slides I find it very interesting!
This is exactly why Opera switched to Webkit. Developers just can’t be bothered to add prefixes for other browsers even if it’s easily fixed with mix-ins..