About Repaint and Reflow in JavaScript | Hacker News Reader

About Repaint and Reflow in JavaScript

vcarrer.com

24 pointsvladocar9 comments

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.

Did you try http://code.google.com/intl/it/webtoolkit/speedtracer/ ?

awesome! <tips hat>

Same thing happened to me while coding with Sencha touch, and I thought it should be something with the library performance (ExtJS).

After measuring everything correctly, and watching at the demo applications (which run fine on the phone) I saw that besides javascript work the difference where the box-shadows... Man that was a huge performance hit, removing them made the application actually usable, not like before.

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.

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...

No other hand required for Animation. It works the same.

Any changes you make to the DOM/CSS are rolled up and happen together. Even changes to position, CSS transforms, etc.

That's why your effects code ends up having all those setTimeout(function(){keepGoing()}, 0); blocks in it. You need to chill from time to time and let the browser render what you've done already.

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!

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.

Reply on news.ycombinator.com