Oversimplified advice: “Use translate3d for hardware acceleration.”
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.
— 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!)
“It’s not just the speed of the car, it’s the traffic conditions.”
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.”