0

I've read on SO and elsewhere that re-paints and re-flows are expensive for the browser to perform.

I'm curious about CSS/JS alternatives to re-paint/display:none and re-flow/visibility:hidden that aren't as computationally demanding for the browser.

Just to be clear, and please correct me if I'm wrong, a common re-flow scenario is when you set display:none on element that you want to toggle the display of, e.g., a dropdown menu. The re-flow means that the browser first "flows", i.e., displays, the element and everything beneath as visible content but then has to re-flow all of it because the dropdown menu needs to be hidden.

Commentary on whether the performance hit of re-flow and re-paint is actually something that people need to care about is welcome too.

Community
  • 1
  • 1
tim peterson
  • 23,653
  • 59
  • 177
  • 299
  • 1
    If you want to change what is displayed, you need to reflow and repaint at least once. The best you can do is to minimize the number of reflows by not alternating DOM changes with computed property reads – John Dvorak Mar 04 '13 at 16:04
  • On a typical webpage (e.g., this one here-Stackoverflow), what's a typical upper limit number of `display:none` that one would want to use before it starts to look jerky? – tim peterson Mar 04 '13 at 16:06
  • DOM elements that are permanently hidden don't cause a reflow. What hurts is "remove this element. How big is the container? Remove this one. How big it's now? OK, remove this one as well. What now?" – John Dvorak Mar 04 '13 at 16:08
  • The point is that if you remove multiple elements at once, you may end up with just one reflow if the browser can avoid all but the last reflow. – John Dvorak Mar 04 '13 at 16:10
  • Thanks @Jan, so have I misunderstood what a re-flow is? If an element has a CSS attribute of `display:none` then that doesn't need to be flowed and then re-flowed when the page is being rendered? Can you provide an answer which provides a typical example of what a re-flow is? – tim peterson Mar 04 '13 at 16:12
  • reflow = the browser computes where each element is; repaint = the browser places some pixels on the screen – John Dvorak Mar 04 '13 at 16:13
  • 1
    I'm pretty sure this shouldn't be an issue. Look how fast the browser can create 1000 divs, make them invisible, then make them visible again: http://jsfiddle.net/howderek/aDzgc/ – howderek Mar 04 '13 at 16:31
  • @howderek nice example! – tim peterson Mar 04 '13 at 16:35
  • @timpeterson it still runs fast even with opactiy: http://jsfiddle.net/howderek/aDzgc/embedded/result/ – howderek Mar 04 '13 at 16:59

2 Answers2

2

I think you misinterpret that statement.

If you're dynamically generating elements, consider these two scenerios:

  1. Generate an element, add it to the DOM. Repeat.
  2. Create a DOMDocumentFragment first. Add the elements to the fragment. Repeat. Add the fragment to the DOM.

Method 1 will do a re-paint for each element you add. Method 2 will only do one repaint at the end. If you have a low number of elements to add method 1 is probably fine. If you're adding many nodes method 2 will be considerably faster.

This is what is meant by re-paints are expensive.

Maybe this is a good way of looking at it:

A re-paint has a base cost of say 100. Creating a DOM element and appending it costs 1. If you're doing method 1 for 7 elements your cost will be (1 + 100) * 7 = 707. If you're doing method 2 your cost will be: 1 * 7 + 100 = 107. Which is considerably lower. The numbers are just for illustration. There is probably a lot more to it than this, but I think this is a good and simple way of looking at re-paint performance.

Halcyon
  • 57,230
  • 10
  • 89
  • 128
  • so adding then removing a loader gif from the DOM is a good example of re-flow? That can't be expensive. I guess if there are big chunks of HTML being added/removed/hidden/shown repeatedly by JS then perhaps the "expense" becomes relevant. – tim peterson Mar 04 '13 at 16:16
  • 1
    @timpeterson adding a gif really doesn't hurt performance (unless it displaces 10000 more elements) – John Dvorak Mar 04 '13 at 16:17
  • @FritsvanCampen thanks, so is looking for alternatives to re-paint/re-flow even a reasonable goal? – tim peterson Mar 04 '13 at 16:32
  • 1
    I don't think there exists such a thing. If you're having problems with performance consider reducing the amount of elements you have on the screen. – Halcyon Mar 04 '13 at 16:34
1

There is no simple formula. To begin with, every browser has its own way to deal with reflows and repaints. Usually, browsers will try to postpone reflows as much as possible, since they can be very expensive, as you know.

In general, keep in mind that the following operations always trigger a reflow:

  • Changing the DOM tree by appending, removing or moving nodes.
  • Changing CSS calculated properties such as offsetWidth
  • Reading computed CSS values with getComputedStyle (or currentStyle on old IE)

(See When does reflow happen in a DOM environment?.)

Setting styles will usually cause a reflow, but browsers will try to avoid it if the change can't affect other elements' positions or dimensions[citation needed].

For some fun with reflows, see Will it reflow?

Community
  • 1
  • 1
bfavaretto
  • 71,580
  • 16
  • 111
  • 150