Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In terms of render perf, is paint area worth worrying about in DOM animations? #7

Open
alexzaworski opened this issue Jan 20, 2017 · 0 comments

Comments

@alexzaworski
Copy link

alexzaworski commented Jan 20, 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 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):

resize

That uses a couple tricks to keep things speedy:

  1. 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)
  2. 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:

resize1

(the giant ugly checkbox toggles box sizing).

SO my actual question is a two-parter:

  1. 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
  2. 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.
  3. Bonus: why the hell does 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

@alexzaworski 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant