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 12:52 Garrett Smith wrote: > David Mark 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: >>>> [...] >>>> >>>>>> 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 >>>>> >>>> Does it say something there about repaint when exiting an execution >>>> context? I didn't see any such claims there. >>> They called it something else IIRC (a "thread" of some sort). > > IIRC? If you recall? It's an article *you* posted. Hardly. It's an article I cited. I originally read it _years_ ago. > > I get that you don't like reading documentation. I get that you don't get anything. > > The article, however, hardly qualifies as documentation. If you'd read > any, ever, you'd know that, but you've made it clear that don't read > documentation. And again, calling it "fruitless". > >>> >> >> Re-reading what they said, it seems they aren't very clear about this >> specific issue. By "thread", they are not referring to an execution >> context. But they qualify that with assertions about when they might >> repaint _before_ the "thread" has ended. From experience (with Opera as >> well as many other browsers), I can tell you that on exiting execution >> contexts, they make a decision to repaint at that time or wait for the >> next such occurrence. >> > Claiming that a browser makes a decision to repaint when exiting an > execution context is certainly different from claiming that the browser > repaints when exiting an execution context. > > Execution stack, is probably what was meant by "thread" in that article. I'm sure. > > I see no evidence that shows that browsers will repaint when exiting an > execution context normally. Execution stack, yes, but execution context? > No. Then you haven't experimented enough. It comes with experience. > >> Better for you to do some experimentation on your own (with more than >> just Opera of course). Slower PC's/devices are usually better >> candidates for such demonstrations. YMMV. >> >> Or you could just listen to me for once. My experience invariably ends >> up trumping fruitless documentation searches in such matters (as you >> have found out numerous times over the years). For example, we didn't >> have any documentation about the relationship between ActiveX and >> "unknown" types until very recently, did we? And that documentation >> confirmed exactly what I had been saying for years (and that you >> attempted to contradict just a month or two ago). The browser >> developers don't publish everything (and what they do is often years too >> late to be helpful). > > > There was a long standing correlation with ActiveX throwing errors for > "unknown" types. MS-ES3 documentation explained that it was not only > correlation, but causation. Yes, and who first pointed it out (years before it was documented?) The documentation just proved my theory. The point is that the documentation doesn't always exist, but you can still theorize (and be right). > > The article you linked didn't back up the claims that the browser will > repaint when exiting an execution context. So far there isn't any > evidence to back up the claim. Yes there is, you just can't see it. As usual, you'd be much better off taking my word for it (or testing yourself) than searching for documentation that likely doesn't exist.
From: Garrett Smith on 10 May 2010 19:55 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. What do you mean by "lack of function calls between DOM manipulations"? What does it have to do with completing an execution context? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 10 May 2010 20:00 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? > > 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.
From: Garrett Smith on 10 May 2010 20:46 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. What is not obvious is to the reader is the phenomenon that you are describing. >> 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 10 May 2010 21:07
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? > > 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. > >>> 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. 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? 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). |