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 10 May 2010 22:11 On 11/05/10 03:07, David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Garrett Smith wrote: >>>> What do you mean by "lack of function calls between DOM manipulations"? >>>> What does it have to do with completing an execution context? >>> >>> I think that should be perfectly obvious. Re-read the thread. >> The question stands on its own. > > Are you playing dumb or what? And I noticed you've translated the > terminology (e.g. exiting => completing). So, I think you know that > when you call a function, you exit one context and enter another. > Right? That's when updates _can_ happen. If that's what you meant, then I misunderstood you, too. "Exiting an execution context" is ambiguous - I also thought you meant "returning from an execution context", either explicitly or when there are no more statements to process, instead of "entering a new execution context". (OTOH, there may be no practical difference, because both are connected) I've noticed unexpected redraws in Opera in the past, when they didn't happen in other browsers on the same PC. Maybe Opera really does handle things differently here, or maybe all browsers do this, as you say, but with a different heuristic/logic behind the decision. In any case, this effect is not easy to prove*, and there are still no official documents describing when a redraw is likely to happen (before the thread ends). You said you could easily produce a test case for your PC. It would be helpful if you could put this test online, so that more people with different configurations can try it and share their results. *) apart from reading the source, where that is possible. Given time, I can find my way around the Mozilla and Webkit sources, but these days it's mostly a maze of macros and arcane optimizations. I don't go there unless I absolutely have to. My last encounter with Mozilla code left me scarred and traumatized for life. > We just had this discussion a couple of months back. Did you search the > archive as I asked? I did, but came up empty. I really wish Google would stop treating Usenet search like an unwanted child. Their web search is great, almost psychic at times, but with their Usenet index, I sometimes can't even find a message when I know the group and the exact subject. That thing is seriously broken. "Searching the archive" is a good idea but not a guarantee for success. > It's served me well for many years (primarily by knowing > that if I need for updates to happen all at once, I need to avoid > exiting the execution context). I don't doubt it, but that's still anecdotal evidence from one person. We should be able to do better than that. -- stefan
From: Garrett Smith on 10 May 2010 22:37 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Garrett Smith wrote: >>>> David Mark wrote: >>>>> 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. >>>> [...] >>>> >>>>>> 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, >>>> Then it should not be that hard to produce an example demonstrating that >>>> phenomenon. >>> No, it shouldn't. I can produce one that is visible on _my_ PC with no >>> trouble. What's your problem? >>> >> Said the Jehova's witness. > > Where? > Did you see a problem that nobody else saw? Why not share it with the group and show us about it? It is certainly interesting and on-topic material for this NG and thread (in contrast to the ads for your support services) >> What is not obvious is to the reader is the phenomenon that you are >> describing. > > I think it is. And you are the only one asking about it at this point. > It is unsurprising that nobody is complaining about the nothing not being solved. Just because nobody is willing to tell you you are wrong does not mean that you have provided evidence to your claims. >>>> What do you mean by "lack of function calls between DOM manipulations"? >>>> What does it have to do with completing an execution context? >>> I think that should be perfectly obvious. Re-read the thread. >> The question stands on its own. > > Are you playing dumb or what? And I noticed you've translated the > terminology (e.g. exiting => completing). So, I think you know that > when you call a function, you exit one context and enter another. Would you rather use the term exiting? Exiting an execution context? OK. So I think you mean that given: div.style.color = "red"; // func(); div.style.position = "absolute"; - that if line two "func()" is uncommented, then the browser might repaint, but if it isn't then that won't happen. The cases where I know that is true is with alert, scrollTo/By, etc as mentioned. I also recall seeing flickering issues, though it was actually within one function call. It was something along the lines of: el.style.visibility = "visible"; el.style.top = t + "px"; el.style.left = l + "px"; - and in an old version of Mozilla, the menu would be shown momentarily out of place and snap into place. If you are able to try an old version of Mozilla, around 1.0, see: http://brainjar.com/dhtml/menubar/demo.html - and you may notice the described behavior. > Right? That's when updates _can_ happen. As Opera said, there are a > number of considerations it uses to determine when to do them. It does > _not_ necessarily wait until the end of the call stack. You can put > _that_ in the bank. And how could you not know this at this point? We > just had this discussion a couple of months back. Did you search the > archive as I asked? > I vaguely recall the notion of repainting was presented without much evidence and instead of picking it up, I did something else. > Put two PC's of varying performance side by side and one may have a > noticeable update while the other may not. It depends on far too many > variables to predict. So concentrate on the abstraction, rather than > observations. It's served me well for many years (primarily by knowing > that if I need for updates to happen all at once, I need to avoid > exiting the execution context). You are describing undocumented behavior with no example. You are applying the reaction of that behavior in a way that may adversely affect API design. It is as if you are prioritizing API design around undocumented peculiarities rather than logical organization of what needs to go where. A function that sets innerHTML is not as clear or efficient as setting innerHTML directly and it requires organizing that function so that it is a "static" method as a property of something. That is the reason for not creating such function. Not: The browser will repaint. The browser won't repaint then and if it does it is making a bad choice. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 11 May 2010 00:28 Stefan Weiss wrote: > On 11/05/10 03:07, David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> Garrett Smith wrote: >>>>> What do you mean by "lack of function calls between DOM manipulations"? >>>>> What does it have to do with completing an execution context? >>>> I think that should be perfectly obvious. Re-read the thread. >>> The question stands on its own. >> Are you playing dumb or what? And I noticed you've translated the >> terminology (e.g. exiting => completing). So, I think you know that >> when you call a function, you exit one context and enter another. >> Right? That's when updates _can_ happen. > > If that's what you meant, then I misunderstood you, too. "Exiting an > execution context" is ambiguous - I also thought you meant "returning > from an execution context", either explicitly or when there are no more > statements to process, instead of "entering a new execution context". > (OTOH, there may be no practical difference, because both are connected) To be precise, I mean leaving an execution context on either calling another function or on finishing execution of the last statement (at which point it returns to the caller's execution context, assuming the call stack is not exhausted at that point). > > I've noticed unexpected redraws in Opera in the past, when they didn't > happen in other browsers on the same PC. Maybe Opera really does handle > things differently here, or maybe all browsers do this, as you say, but > with a different heuristic/logic behind the decision. There's no telling exactly when any given browser will do it. But they won't do it at all unless you exit an execution context. That much I know. I can't speak for every browser, but I've tested more than my share over the years. > In any case, this > effect is not easy to prove*, and there are still no official documents > describing when a redraw is likely to happen (before the thread ends). Correct. You have to draw upon experience. I have also discussed this with other experienced developers (and some of those discussions are in the archive). > You said you could easily produce a test case for your PC. Sure. Set a previously hidden element's visibility style to "visible" (assuming it does not have a display style of "none" of course). Then call a function that clips it (or sizes it or whatever). Try it in various browsers (as mentioned slower or burdened PC's seem to be the best bet) and watch for a flicker of the full element before the clip (or size or whatever). Once reproduced, it is trivial to fix by setting the subsequent style without calling a function. I most recently ran into this when dealing with IE's filter style. Displaying the element just prior to calling a function that adjusted the filter style resulted in a momentary flash of the unfiltered element. This happened virtually every time (on at least one machine anyway). Setting the filter style in the same function that displayed the element (with no function calls in between) fixed it for good. Of course, this only happened when styling a particular DOM structure. The same code operating on a different structure (or even the same structure in a different document) did not. So trying to track such behavior will drive you nuts. It's best to look at the code, rather than the browser window (assuming you know what to look for). ;) > It would be > helpful if you could put this test online, so that more people with > different configurations can try it and share their results. As it happens, the one I describe above is online, but with a workaround in place. I used a workaround of setting the opacity to 0, then applying the other filter, calling the function that shows the element and then setting the opacity back on return from that function (unless the effect is fade of course, in which case I let it be). Eventually I will update the library code as I can see where the potential for a problem lies (and it had lay dormant for years until I started on the Alert example). As mentioned, this never happened on another page that shows/hides the same DOM structure with the same code (the Build Test page has no such workaround). Basically, a fade-in on the latter page was fine, but on the Examples page (in IE8 only), I got a flicker of the fully opaque element. But it is no mystery as the animation code clearly has one place where this can happen. Hit my Examples page with IE8 and see the note in the alert section. There's enough explanation there to try to reproduce the issue in a sandbox. But your sandbox may well have to mimic the Examples page (and your PC may well have to be similar to my test machine). FWIW, IE8 is a major dog on that particular machine and the Examples page is fairly long-winded with tons of form controls. http://www.cinsoft.net/mylib-examples.html#myalert Perhaps I will put up a test version without the workaround when I get a chance, but no promises. I am pretty swamped these days and I am not particularly curious as I know exactly where the potential for a problem lies. > > *) apart from reading the source, where that is possible. Given time, I > can find my way around the Mozilla and Webkit sources, but these days > it's mostly a maze of macros and arcane optimizations. I don't go there > unless I absolutely have to. My last encounter with Mozilla code left me > scarred and traumatized for life. Don't bother (not for this anyway). :) As an aside, I've had previous issues like this with various FF versions (again, usually on slow machines). The solution was always the same. > >> We just had this discussion a couple of months back. Did you search the >> archive as I asked? > > I did, but came up empty. I really wish Google would stop treating > Usenet search like an unwanted child. Yes, GG sucks. I got lucky and found one of the threads I was thinking of:- http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/5977cb39923b4b9d/b09cb6f082f1487e?#b09cb6f082f1487e > Their web search is great, almost > psychic at times, but with their Usenet index, I sometimes can't even > find a message when I know the group and the exact subject. Tell me about it. :( > That thing > is seriously broken. "Searching the archive" is a good idea but not a > guarantee for success. It's unfortunate. But you can use their Web search as well as these posts echo all over the place. > >> It's served me well for many years (primarily by knowing >> that if I need for updates to happen all at once, I need to avoid >> exiting the execution context). > > I don't doubt it, but that's still anecdotal evidence from one person. > We should be able to do better than that. > > Possibly. As mentioned, it's one of those issues that shows up sporadically. I only know the way to avoid it entirely, not the way to reproduce it reliably. BTW, for those wondering, this does not qualify as a "quick answer". My "insurance business" would go belly up if I had to give this much detail for quick questions. The quick answer had been previously given and is certainly enough to avoid the problem (though it does not represent a proof of anything). Proofs (when possible) and history lessons are extra. ;)
From: Garrett Smith on 11 May 2010 02:45 David Mark wrote: > Stefan Weiss wrote: >> On 11/05/10 03:07, David Mark wrote: >>> Garrett Smith wrote: >>>> David Mark wrote: >>>>> Garrett Smith wrote: [...] >> I've noticed unexpected redraws in Opera in the past, when they didn't >> happen in other browsers on the same PC. Maybe Opera really does handle >> things differently here, or maybe all browsers do this, as you say, but >> with a different heuristic/logic behind the decision. > > There's no telling exactly when any given browser will do it. No, they will repaint after alert, setTimeout, setInterval, etc. But they > won't do it at all unless you exit an execution context. Except when they do, such as with the example I provided a link to. I observed the behavior in a much older version of Mozilla on apple mac. Doesn't really make much sense from an efficiency standpoint for the browser to repaint twice when it can repaint once so the fix makes sense. The browser not doing that anymore seems like a fix. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 11 May 2010 02:54
Garrett Smith wrote: > David Mark wrote: >> Stefan Weiss wrote: >>> On 11/05/10 03:07, David Mark wrote: >>>> Garrett Smith wrote: >>>>> David Mark wrote: >>>>>> Garrett Smith wrote: > [...] > >>> I've noticed unexpected redraws in Opera in the past, when they didn't >>> happen in other browsers on the same PC. Maybe Opera really does handle >>> things differently here, or maybe all browsers do this, as you say, but >>> with a different heuristic/logic behind the decision. >> >> There's no telling exactly when any given browser will do it. > > No, they will repaint after alert, setTimeout, setInterval, etc. That only covers a small subset of possibilities. > > But they >> won't do it at all unless you exit an execution context. > > Except when they do, such as with the example I provided a link to. I > observed the behavior in a much older version of Mozilla on apple mac. Anything is possible. I didn't say that *every* browser ever made behaved like this (just the hundreds I've dealt with over the years). > > Doesn't really make much sense from an efficiency standpoint for the > browser to repaint twice when it can repaint once so the fix makes > sense. The browser not doing that anymore seems like a fix. Yes. It makes sense to queue changes until an execution context is exited. Near as I can tell, that is what they do. |