How can I make the browser display changes at once?
in [JavaScript]
|
Prev: FAQ Topic - How can I disable the back button in a web browser? (2010-04-17)
Next: FAQ Topic - How do I access a frame's content? (2010-04-18)
From: Jorge on 18 Apr 2010 16:33 On Apr 18, 9:39 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Jorge wrote: > > Thomas 'PointedEars' Lahn wrote: > >> Jorge wrote: > >> > Thomas 'PointedEars' Lahn wrote: > >> >> <http://pointedears.de/scripts/test/dom/events/window-onload.mpeg> > > >> >> Will you *please* shut up now? > > >> > Why ? > >> > He's right. > >> > The page in your video is not drawn until after window.onload returns: > > >> That is > > >> 1. not what he stated: > > >> | They mean KEEP THE SCREEN BLANK until the script executed, apply DOM > >> | changes if any, and only then display the page for the first time. > > >> and 2. not what happens. The heading is there, and "the page displayed > >> for the first time" long before. No "blank screen" whatsoever. > > > Well, I get the blank screen for 20s in Safari, Chrome, FF 2..3.6, > > NSNavigator, Flock and iCab, but not in Operas nor in IE5.2.3, on Mac > > OSX. > > Apparently you don't know what "blank" and "first time" mean. FYI: a blank screen means that the heading is not there, that nothing is there but a blank, empty page, for 20 seconds. > >> > replace your window.onload with this one in order to see: > > >> > window.onload= function (now) { > >> > now= +new Date()+ 20e3; > >> > while(+new Date() < now) {} > >> > init(); > >> > }; > > >> That does not prove his knee-jerk generalization either. It only proves > >> that time-consuming tasks like those slow down loading of the document.. > >> What else is new? > > > The document is fully loaded when onload fires, remember, that's the > > whole point of the onload event. > > There is no "onload event", and you miss the point. "Loaded" does not need > to mean "rendered", and in fact it is well-known that the `load' event may > occur well before all content has been fully rendered (images, for example). And well before *any* content is rendered, it seems. > >> But assuming the generalization would be true, how do you explain > >> <http://PointedEars.de/es-matrix/index-alert>, where the console message > >> and the alert message box is displayed *after* the table of contents is > >> displayed (at least in Iceweasel 3.6.3)? > > > That page is too complicated for me to dig in it. Could you please > > post a shorter example to prove your point ? > > No. The very point of this is that it is a considerably large document (a > slightly adapted copy of the original Matrix) which makes it a much better > test case for any possible timing issues with the `load' event than the > short one which was posted by VK here (not to mention that the > window.setTimeout() call only complicates the issue in a *single-threaded* > environment). > > You only need to recognize that and look for the window.alert() call in the > `onload' attribute of the `body' element's start tag. And observe the > document content being displayed well before the alert message. Maybe. But you should not call alert() as it adds an additional variable to the equation. It might very well be -and it would really make a lot of sense- that all browsers redraw the screen before an alert, but that would have nothing to do with what VK was saying. > We know with considerable certainty that window.alert() holds script > execution until after the alert message was confirmed. True. But your attempt at cheating now by introducing an alert() is quite lame, really. > If VK's knee-jerk > generalization would be true we should be seeing no document content > whatsoever until after the alert message was confirmed. No. Not really. As there was no alert() in his code. > But obviously that > is _not_ the case. Logic dictates that if the set union of assumption and > facts is inconsistent (i.e. contradictory), the assumption must be false. > q.e.d. QED or whatever, his code yields a blank page in 6 out of 8 browsers. -- Jorge.
From: Johannes Baagoe on 18 Apr 2010 16:42 Thomas 'PointedEars' Lahn : > Why should I replace an element with its clone when I could simply > modify its properties? It seems the natural thing to do if one does not want the successive modifications to cause the layout to be recalculated and the window redrawn at each modification. Now, if there is some authoritative standard, say, in the W3C DOM specifications, which says that this is *not* what should happen, I stand corrected - one may safely assume that on conforming browsers, the changes will only cause recalculation when the functions that makes them returns, or at some other moment the standard specifies. Is there? > That does not make a lot of sense, and it is considerably less > efficient both with regard to runtime and memory. Just how considerable would that be? It seems to me that anything less than 50 ms and a few megabytes won't really matter. -- Johannes
From: Jorge on 18 Apr 2010 17:51 On Apr 18, 7:32 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > (...) > Failing that, the very minimum would be a standard and convenient > function like `window.yield()`, meaning "Do whatever requires your > attention, and come back when you have finished". > (...) A second thought: The purpose of .yield() would be to service pending events while preserving (that is, avoiding the need to exit/destroy) the current execution context, right ? For example, this code: (function contextContainer () { var contextData; do { workOn(contextData); yield(); } while (!done()); })(); But, as JS functions carry their contexts with them (a closure), somehow it's not such a big deal, it requires not much effort -at least in JS- to exit a context and happily resume later, because the context is automatically saved for you: (function contextContainer () { var contextData; (function iCarryTheContext () { workOn(contextData); !done() && setTimeout(iCarryTheContext, 0); })(); })(); And both are just 4 lines long... :-) -- Jorge.
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 18:10 Johannes Baagoe wrote: > Thomas 'PointedEars' Lahn : >> Why should I replace an element with its clone when I could simply >> modify its properties? > > It seems the natural thing to do if one does not want the successive > modifications to cause the layout to be recalculated and the window > redrawn at each modification. No. Current DOM implementations have a long history, and there has not always been a cloneNode() method. > Now, if there is some authoritative standard, say, in the W3C DOM > specifications, which says that this is *not* what should happen, I > stand corrected - one may safely assume that on conforming browsers, > the changes will only cause recalculation when the functions that > makes them returns, or at some other moment the standard specifies. > > Is there? JFTR, I don't know one, and IMNSHO it is not the purpose of W3C interface specifications to define implementation behavior in that great detail. But you know what, you are really funny. When a specified reference is being presented to you that recommends not to do something, you demand empirical evidence before you would reconsider your design decision. And when there is empirical evidence that something works as described you demand a specification reference before you would reconsider your design decision. Make up your mind! >> That does not make a lot of sense, and it is considerably less >> efficient both with regard to runtime and memory. > > Just how considerable would that be? Considerable enough with, say, 100 sets of property changes within 5 seconds (that is, a delay/frame length of 50 milliseconds, a DOM animation average). That would be 100 objects in memory instead of one, and 200 method calls instead of none. > It seems to me that anything less than 50 ms and a few megabytes won't > really matter. AISB, you don't know what you are talking about. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Dr J R Stockton on 18 Apr 2010 13:52
In comp.lang.javascript message <Hu-dnT-HxfkT_FTWnZ2dnUVZ8nti4p2d(a)gigane ws.com>, Sat, 17 Apr 2010 02:21:50, Johannes Baagoe <baagoe(a)baagoe.com> posted: >When making my test page to measure speeds of PRNGs, I met an >unexpected problem: neither Firefox nor Chrome displayed the changes >to the document before the end of the tests. (Firefox also became >*very* unresponsive.) Opera, on the other hand, behaved as expected - >the changes I made to the document were immediately visible. > >I have solved the problem by daisy-chaining the tests with setTimeout >calls: That, or using Opera, appears to be the standard (and perhaps only) recommendation; you might use, say, 10 ms or more instead of 0 ms to give the rest of the system more time (that might be desirable if another busy process is also running). In some browsers, and perhaps dependent on settings, window.status is always updated without delay. If all that is needed is an indication of progress, that can suffice, though some will not like it. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links; Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc. No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News. |