You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This may be a bit too browser-internals-ish of a question but it's something I've been wondering about for a while so I figured I'd see if you folks had an answer.
My grasp of render performance is... iffy so if I say something that sounds weird/wrong it's prob weird/wrong — bear with me :) My understanding is that the most performant CSS animations are those that leverage properties that trigger compositing but nothing else, followed by those that trigger paint, followed by those that trigger layout (which, as I understand it, is reaaaally bad perf wise).
In blink-based browsers that can be accomplished by limiting your animations to transform and/or by using things like translate3D to place elements on their own layer to avoid some paints. As an exercise I wanted to build a resizable text pane thing that caused as little painting as possible, here's how that turned out (with paint flashing turned on in Chrome):
That uses a couple tricks to keep things speedy:
overflow is set to hidden on the text box while resizing so the text isn't constantly painted (you can see the big ol' paint at the start/end when the scroll bar toggles)
The handle is elevated to its own layer via translateZ(0) to avoid having to paint the whole dang thing (just the top edge is painted, pretty neat)
Now where things get weird to me is when you set the box-sizing on the text wrapper to border-box instead of content-box. Suddenly the entire chunk of text is getting painted on every frame:
(the giant ugly checkbox toggles box sizing).
SO my actual question is a two-parter:
Do you worry about paint area when building CSS animations? Obviously it doesn't matter much here since it's so simple but I can imagine situations in which it has an impact
Is box-sizing: border-box a performance anti-pattern? I use it pretty much all the time and I've never heard it discussed in the context of render perf. That's weird to me because really smart browser peeps (eg Paul Lewis) have repeatedly mentioned that reducing paint is important.
Bonus: why the hell does border-box increase the paint area? It took me a solid hour to track the problem down :(
The text was updated successfully, but these errors were encountered:
alexzaworski
changed the title
In terms of render perf, is paint area worth worrying about in CSS animations?
In terms of render perf, is paint area worth worrying about in DOM animations?
Jan 21, 2017
This may be a bit too browser-internals-ish of a question but it's something I've been wondering about for a while so I figured I'd see if you folks had an answer.
My grasp of render performance is... iffy so if I say something that sounds weird/wrong it's prob weird/wrong — bear with me :) My understanding is that the most performant CSS animations are those that leverage properties that trigger compositing but nothing else, followed by those that trigger paint, followed by those that trigger layout (which, as I understand it, is reaaaally bad perf wise).
In blink-based browsers that can be accomplished by limiting your animations to
transform
and/or by using things liketranslate3D
to place elements on their own layer to avoid some paints. As an exercise I wanted to build a resizable text pane thing that caused as little painting as possible, here's how that turned out (with paint flashing turned on in Chrome):That uses a couple tricks to keep things speedy:
overflow
is set tohidden
on the text box while resizing so the text isn't constantly painted (you can see the big ol' paint at the start/end when the scroll bar toggles)translateZ(0)
to avoid having to paint the whole dang thing (just the top edge is painted, pretty neat)Now where things get weird to me is when you set the
box-sizing
on the text wrapper toborder-box
instead ofcontent-box
. Suddenly the entire chunk of text is getting painted on every frame:(the giant ugly checkbox toggles box sizing).
SO my actual question is a two-parter:
box-sizing: border-box
a performance anti-pattern? I use it pretty much all the time and I've never heard it discussed in the context of render perf. That's weird to me because really smart browser peeps (eg Paul Lewis) have repeatedly mentioned that reducing paint is important.border-box
increase the paint area? It took me a solid hour to track the problem down :(Here's a link to the Pen I used to demo stuff: http://codepen.io/alexzaworski/pen/f2ac1d6f8bff5d6e1f5c779375de43af
The text was updated successfully, but these errors were encountered: