5

For example, if I do something like

requestAnimationFrame(function() {
    el.appendChild(otherEl)
    el.appendChild(anotherEl)
    anotherEl.removeChild(someOtherEl)
    anotherEl.appendChild(yetAnotherEl)
})

Does that cause a (synchronous?) repaint/reflow to happen during the time when we're trying to avoid causing repaint/reflow, thus voiding the purpose of requestAnimationFrame?

Or, will the browser be smart and wait until after that frame is complete (after all those DOM manipulations are complete) in order to finally paint the resulting DOM structure?

What are all the things that can cause repaints/reflows, and that we would want to avoid doing while inside a requestAnimationFrame?

The list of styles in this html5rocks article mention only style that (I think) cause repaint/reflow when they are modified. I'm also curious to know which JavaScript properties (and on which object they are on) cause reflow when being accessed (i.e. reflow happens in order to be able to get the value of a certain property).

trusktr
  • 44,284
  • 53
  • 191
  • 263
  • are you doing that on a per-frame basis i.e. appending children on a regular basis? – Tahir Ahmed Apr 07 '16 at 06:21
  • @TahirAhmed Not necessarily. It could be every few seconds, or possibly even less than a second. Though, I wouldn't want to impose a limit on it. The use case could be anything (f.e. adding removing elements every frame to make some sort of quickly blinking effect). – trusktr Apr 07 '16 at 21:26
  • _adding removing elements every frame_ would I think be far too quick for you to notice anything visually because browsers tend to render *60* frames per second. – Tahir Ahmed Apr 08 '16 at 02:21
  • but, I get that this is an example scenario and rAF doesn't have a purpose here. You only want to understand that on a single frame, how the above appending and removing child operations would perform. – Tahir Ahmed Apr 08 '16 at 02:22
  • 1
    another question, are you using the word _repaints_ in general here because a frame consists of a number of operations, one of them is *Paint*. Take a look at this **[video](https://www.youtube.com/watch?v=CHwwSgKfXDE)** and **[this](https://aerotwist.com/blog/the-anatomy-of-a-frame/)** article by *Paul Lewis*. – Tahir Ahmed Apr 08 '16 at 02:44
  • @TahirAhmed Thanks for the links, which were interesting, but don't quite cover what exactly doesn't cause a synchronous repaint. Ah, maybe I should add the word "synchronous" in the question. – trusktr Apr 10 '16 at 05:27

1 Answers1

2

Does that cause a (synchronous?) repaint to happen during the time when we're trying to avoid causing paints, thus voiding the purpose of requestAnimationFrame?

I don't quite understand you're first question but I'll try to answer it anyway.

Adding or removing elements from the DOM triggers a reflow, whilst requestAnimationFrame is a formal version of the translateZ(0) or translate3d(0,0,0) trick to force a layer creation. In that sense, triggering a reflow is irrelevant to using rAF. You mentioned a "repaint to happen during the time when we're trying to avoid causing paints" which I assume you're referring to throttling which you should be implementing anyway. Let me know if I didn't answer it properly.

Or, will the browser be smart and wait until after that frame is complete (after all those DOM manipulations are complete) in order to finally paint the resulting DOM structure?

Given that all your appends and removes are in the same rAF call, the browser (to my understanding) should paint them all together in a single frame.

What are all the things that can cause repaints/reflows, and that we would want to avoid doing while inside a requestAnimationFrame?

Repaints are triggered by anything which causes a change in the visibility but does not affect the layout. Opacity doesn't trigger a repaint so it's much cheaper to animate.

Reflow affects the layout of the whole or a portion of the page causing the size and positions of the affected elements to be recalculated and should therefore be avoided in animations. Translate, rotate and scale however don't trigger reflow.

You can read more about this here and get a list of the css properties which trigger layout and repaint.

Lastly just to clear up that last question, repaints and layouts occur whether or not they're inside or outside of a rAF. Just keep that in mind.

Flying Emu
  • 430
  • 6
  • 14
  • I believe I meant "repaint and/or reflow", not just repaints I'm interested in. A reflow causes a repaint right, since things have been re-laid-out they need to be re-painted I would think. So, I guess I'm actually curious to know what causes reflows (lay outs). – trusktr Apr 21 '16 at 04:20
  • That's a nice list of things that trigger reflow (layout). But, the article doesn't mention which things not to read where reading the property causes reflow in order to determine the value of the property being read. – trusktr Apr 21 '16 at 04:22
  • 1
    @trusktr I'm not aware of any properties which trigger reflow on being read, especially given that reading properties do not affect their style in the DOM. As far as I'm concerned, all the properties are stored in the object's prototype and are retrieved from there. Perhaps you're referring to thrashing where we request a style value, change the value, request the value, change the value, etc. to cause a forced synchronous layout? And yes layout causes a repaint so it's particularly taxing on animation performance. Basically keep to rotate, translate, scale and opacity to be on the safe side. – Flying Emu Apr 21 '16 at 12:26
  • You can definitely trigger reflow from a read, see: https://gist.github.com/paulirish/5d52fb081b3570c81e3a – Marty Aug 21 '16 at 23:24
  • @trusktr The way I understand it, reflow/ layout happens on anything that changes dimension, that reflow triggers a paint. – frontsideup Oct 23 '16 at 23:33