FAQ Topic - How do I modify the content of the current page?(2010-04-14)
in [JavaScript]
|
Prev: test code with firefox 3.5.8 or better
Next: FAQ Topic - How can I see in javascript if a web browser accepts cookies? (2010-04-16)
From: Stefan Weiss on 9 May 2010 20:45 On 10/05/10 02:14, David Mark wrote: > Browsers re-flow on exiting execution contexts. The > second set allows for up to five re-flows. The first set allows for > none. Re-flows are often expensive (not to mention ugly), so should be > minimized. I've heard as much, but I haven't seen any official statements to that effect. How do you know that *all* browsers do this, or even the "current" ones (for user defined values of "current")? I know for a fact that the ones I've tested don't trigger a *redraw* when an execution context is exited, but it's impossible to test when a reflow is triggered. It's a bit like quantum mechanics - as soon as you measure it, you're changing the outcome :) -- stefan
From: David Mark on 9 May 2010 20:56 Stefan Weiss wrote: > On 10/05/10 02:14, David Mark wrote: >> Browsers re-flow on exiting execution contexts. The >> second set allows for up to five re-flows. The first set allows for >> none. Re-flows are often expensive (not to mention ugly), so should be >> minimized. > > I've heard as much, but I haven't seen any official statements to that > effect. Opera (for one) has a long writeup about it on their site. Sorry, but I don't have a link handy. Search the archive as we have discussed this before. > How do you know that *all* browsers do this, or even the > "current" ones (for user defined values of "current")? I don't know that all browsers do that. But I know from roughly a decade and a half of experience that it is a very common strategy. If you work with any sort of intensive animation code, you will find out about it quickly. > I know for a fact > that the ones I've tested don't trigger a *redraw* when an execution > context is exited, but it's impossible to test when a reflow is > triggered. You haven't tested enough browsers/platforms then (or your tests weren't reliable). They may well have repainted so fast that you didn't notice it (which doesn't mean that others with different setups won't). IE does this for sure, as do many versions of FF (perhaps even the latest). I just had to deal with this issue for a client who was having flickery issues in IE8. Changed it so all of the affected DOM updates were done in the same context and the flickers of their unfinished work vanished (as I knew they would). This and memory leaks are "pet" issues for me (i.e. they are found virtually everywhere and most developers don't know what to do about them). And it isn't a rule that they *always* reflow/repaint on exiting an execution context. It just gives them the chance to do so. Conversely, it is virtually *never* the case that browsers update the rendering in the middle of executing a function. ;)
From: Stefan Weiss on 9 May 2010 21:45 On 10/05/10 02:56, David Mark wrote: > Stefan Weiss wrote: >> On 10/05/10 02:14, David Mark wrote: >>> Browsers re-flow on exiting execution contexts. The >>> second set allows for up to five re-flows. The first set allows for >>> none. Re-flows are often expensive (not to mention ugly), so should be >>> minimized. >> >> I've heard as much, but I haven't seen any official statements to that >> effect. > > Opera (for one) has a long writeup about it on their site. Sorry, but I > don't have a link handy. Search the archive as we have discussed this > before. Will do. >> I know for a fact >> that the ones I've tested don't trigger a *redraw* when an execution >> context is exited, but it's impossible to test when a reflow is >> triggered. > > You haven't tested enough browsers/platforms then (or your tests weren't > reliable). They may well have repainted so fast that you didn't notice > it (which doesn't mean that others with different setups won't). IE > does this for sure, as do many versions of FF (perhaps even the latest). They may recalculate/reflow, they do not always redraw immediately. We had a case in here recently where Johannes Baagoe tried to force redraws in the middle of a long running calculation. The result - ugly hacks excluded - was that it can't be done. I did try wrapping the DOM changes in another function, just to see if "exiting the execution context" would help, but it didn't. Thread: <Hu-dnT-HxfkT_FTWnZ2dnUVZ8nti4p2d(a)giganews.com> > I just had to deal with this issue for a client who was having flickery > issues in IE8. Changed it so all of the affected DOM updates were done > in the same context and the flickers of their unfinished work vanished > (as I knew they would). This and memory leaks are "pet" issues for me > (i.e. they are found virtually everywhere and most developers don't know > what to do about them). > > And it isn't a rule that they *always* reflow/repaint on exiting an > execution context. It just gives them the chance to do so. Conversely, > it is virtually *never* the case that browsers update the rendering in > the middle of executing a function. ;) Ah, that's a better way to put it. Repaints _may_ happen when an execution context is exited, but they don't have to, and often don't. I suppose this can be a problem with animations in certain browsers, but I don't have much experience in this area. -- stefan
From: David Mark on 9 May 2010 21:43 Stefan Weiss wrote: > On 10/05/10 02:56, David Mark wrote: >> Stefan Weiss wrote: >>> On 10/05/10 02:14, David Mark wrote: >>>> Browsers re-flow on exiting execution contexts. The >>>> second set allows for up to five re-flows. The first set allows for >>>> none. Re-flows are often expensive (not to mention ugly), so should be >>>> minimized. >>> I've heard as much, but I haven't seen any official statements to that >>> effect. >> Opera (for one) has a long writeup about it on their site. Sorry, but I >> don't have a link handy. Search the archive as we have discussed this >> before. > > Will do. > >>> I know for a fact >>> that the ones I've tested don't trigger a *redraw* when an execution >>> context is exited, but it's impossible to test when a reflow is >>> triggered. >> You haven't tested enough browsers/platforms then (or your tests weren't >> reliable). They may well have repainted so fast that you didn't notice >> it (which doesn't mean that others with different setups won't). IE >> does this for sure, as do many versions of FF (perhaps even the latest). > > They may recalculate/reflow, they do not always redraw immediately. We > had a case in here recently where Johannes Baagoe tried to force redraws > in the middle of a long running calculation. The result - ugly hacks > excluded - was that it can't be done. I did try wrapping the DOM changes > in another function, just to see if "exiting the execution context" > would help, but it didn't. It's always about context. It's hard to say exactly when a reflow/repaint will occur, but it is easy to predict when they will _not_ occur. That's the key to avoiding flickers of unfinished DOM manipulations.
From: Garrett Smith on 10 May 2010 01:36
Stefan Weiss wrote: > On 10/05/10 02:14, David Mark wrote: >> Browsers re-flow on exiting execution contexts. The >> second set allows for up to five re-flows. The first set allows for >> none. Re-flows are often expensive (not to mention ugly), so should be >> minimized. > > I've heard as much, but I haven't seen any official statements to that > effect. How do you know that *all* browsers do this, or even the > "current" ones (for user defined values of "current")? I know for a fact > that the ones I've tested don't trigger a *redraw* when an execution > context is exited, but it's impossible to test when a reflow is > triggered. It's a bit like quantum mechanics - as soon as you measure > it, you're changing the outcome :) > > alert and resizeTo/resizeBy will trigger a repaint. Not sure about scrolTo/By, but probably. DUnno about the other stuff David Mark is talking about. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |