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: David Mark on 10 May 2010 01:36 Garrett Smith 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. 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. Really? Well, I'll direct you to search either this archive or the Opera site (or talk to anyone who has ever had to deal with animations in browsers).
From: Garrett Smith on 10 May 2010 01:44 Dr J R Stockton wrote: > In comp.lang.javascript message <hrvu7q$7cr$1(a)news.eternal- > september.org>, Thu, 6 May 2010 22:29:11, David Mark > <dmark.cinsoft(a)gmail.com> posted: > > >>> The above code should not be used >>> multiple times, but should be made a function : >>> >>> function Wryt(ID, S) { document.getElementById(ID).innerHTML = S } >>> >> I fail to see how that should be a rule. In fact, it is often a bad >> idea to exit an execution context amid multiple DOM updates as it >> triggers costly (and sometimes ugly) re-flows. > > Kindle explain how replacing something like > Either you have a bunch of little functions that each call getElementById or you have a bunch of little functions that expect an element reference, or you have a decorator that does a bunch of things and takes either an element reference or an id. Most times you want to do so much more than set innerHTML. // Untested. function makeTasty(div) { div.style.color = "red"; div.innerHTML = "catsup"; } var eisenhower = document.getElementById("kitty"); makeTasty(eisenhower); -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 10 May 2010 02:30 David Mark wrote: > Garrett Smith 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. 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. > > Really? Well, I'll direct you to search either this archive or the > Opera site (or talk to anyone who has ever had to deal with animations > in browsers). Oh yeah, and setTimeout and setInterval calls. Function calls won't normally trigger a repaint, though. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 10 May 2010 02:34 Garrett Smith wrote: > David Mark wrote: >> Garrett Smith 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. 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. >> >> Really? Well, I'll direct you to search either this archive or the >> Opera site (or talk to anyone who has ever had to deal with animations >> in browsers). > > Oh yeah, and setTimeout and setInterval calls. > > Function calls won't normally trigger a repaint, though. You have completely missed the point. The lack of function calls between DOM manipulations ensures that they will _not_ be triggered. And often they are triggered on exiting execution contexts, just as helpfully documented by the good folks at Opera (and yes, the other browsers generally work the same way). We just had this discussion a few months ago.
From: David Mark on 10 May 2010 02:43
Garrett Smith wrote: > David Mark wrote: >> Garrett Smith 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. 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. >> >> Really? Well, I'll direct you to search either this archive or the >> Opera site (or talk to anyone who has ever had to deal with animations >> in browsers). > > Oh yeah, and setTimeout and setInterval calls. > > Function calls won't normally trigger a repaint, though. Googled: "opera reflow repaint" First hit: http://dev.opera.com/articles/view/efficient-javascript/?page=3 I remember figuring this out (boosted by some anecdotal evidence I'm sure) in IE and FF around the turn of the century. But this is the only formal treatment of the subject that I know of. It's definitely not just about timeouts and intervals. Exiting the execution context is what _can_ trigger an (often unwanted/unneeded) repaint. You should sign up for my support service (meaning everyone). :) |