

About Repaint and Reflow in JavaScript - vladocar
http://www.vcarrer.com/2011/02/about-repaint-and-reflow-in-javascript.html

======
nsfmc
Was i the only person that was a little disappointed by this 'awareness'
piece?

I've recently noticed some unintuitive (initially) painting issues: box-
shadows with large blur radii _freak_ out webkit/mobile safari. I had thought
my site was dying because of some wacky js pokery i was doing and spent a
considerable amount of time tuning my js to no effect. it turned out that this
was a problem with how shadows are drawn in css when atop (i.e. looks like
they're composited live, so umm... watch out).

Who knew? This was a sort of performance issue i remember coming across in ios
core animation lectures and never considered (stupidly) that might be an issue
when you get dynamically generated shadows from css. But the moral here really
is, while repaint and reflow are killer, also watch that you're not doing some
insane _paint,_ because, you know, that's also a performance hit.

Aside: I was really hoping for something like a webkit or chrome plugin that
lets you watch paint/repaint/reflow for your own js-heavy sites like a slow-mo
Timeline feature in webkit's inspector.

~~~
vladocar
Did you try <http://code.google.com/intl/it/webtoolkit/speedtracer/> ?

~~~
nsfmc
awesome! <tips hat>

------
dspillett
While this is a perfectly valid point, particularly if you want your site to
be usable on mobile devices (where the lower power of the devices mean you
need to be more aware of potential performance bottlenecks) of have to support
IE6 (which is slower than everything else by some magnitude for this sort of
content update), in the example given it may be that only a few items are
expected in each response in which case there will be little difference
overall but the code is slightly more complex.

Also, the example given is an example designed to illustrate an unrelated
matter: a callback method within a given API. In such examples it is generally
best to include the minimum extra code needed to make a working example -
adding extra code unrelated to what the example is demonstrating in order to
optimise around browser bottlenecks could muddy the issue.

------
rix0r
I remember hearing in a presentation by Douglas Crockford that the browser
will reflow only after the event that triggered the JS has been handled.

So if you do 1 insert or 1000 in response to an event, it should only cause 1
reflow.

Animation on the other hand...

~~~
dspillett
Correct with most (all?) browsers. Though the code presented would still be
faster ignoring the reflow issue because is is calling
document.getElementById("content") in every iteration of the loop where the
optimised version calls this only once. Of course yuo could cache the
reference to the element to avoid the repeated getElementById calls but
affecting the DOM via the innerHTML property on each loop is still going to be
at least marginally quicker than affecting a local string variable.

This is all beside the point though: that example is for a specific part of
their API. Keeping the example short by not adding more lines in order to
optimise an unrelated area makes it a better example in the intended context
even if not a complete show of general coding "best practise".

The original link's "better" option is bad for its own reason: it misses the
glaring opportunity for reference caching. If you are going to call one
example bad because of a missed optimisation make sure your counter example
does miss an even more obvious one!

~~~
dspillett
Please ignore the above post - I seem to have completely misread a chunk of
the linked article so my point about reference caching is completely and
utterly wrong (the document object's search method is only called once in the
counter example).

Remember kids: think before you post.

