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 14:06 On Apr 18, 7:22 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> 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. > > 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. > 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 ? -- Jorge.
From: Jorge on 18 Apr 2010 15:00 On Apr 18, 7:32 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > (...) > With regard to the unresponsiveness issue, I believe that the only > good solution is true multitasking between user jobs and the other > jobs a browser has to perform. That is, the browser periodically > interrupts user processes to do whatever other priorities it has, > and returns control to them when it is done. But as everything (except the initial program load) is event driven, you'd end up having events interrupting events interrupting events... and if timers are considered as events too, timers interrupting timers interrupting events too, etc. A mess, I think. I hope there is a good reason why they've decided that only a few events are to be handled synchronously (behaving ~ as interrupts), and the rest -most of them- are to be queued to be dispatched later. > 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". GetNextEvent(), WaitNextEvent() and SystemTask()... :-) > At least, it would > not disrupt the structure of the user program and its execution flow > the way daisy-chaining calls to setTimeOut does, not to mention the > effort to set them up. One would simply have to spice one's code with > `window.yield()`s at appropriate places, but from the point of view > of the script programmer, they would essentially be NOPs. > > Both solutions would also solve the delayed rendering issue if one > adopts what I believe is what a normal person would naturally expect: > that changes to a visible DOM object are immediately visible, and > that if lots of such changes mean that the window gets madly animated, > it is up to the programmer to accumulate the changes outside visible > DOM objects until they are ready to be rendered. > > However, if the consensus is that such an accumulation is better > enforced by the browser than left to the competence of the programmer, > we need `window.renderNow()` or similar in addition to multitasking. I believe I have heard people much smarter than me say that this is not a good idea. -- Jorge.
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 15:39 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. >> > 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). >> 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. We know with considerable certainty that window.alert() holds script execution until after the alert message was confirmed. If VK's knee-jerk generalization would be true we should be seeing no document content whatsoever until after the alert message was confirmed. 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. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 16:14 Johannes Baagoe wrote: > Thomas 'PointedEars' Lahn : >> So you would want a DOM implementation to trigger a reflow every time >> you change a DOM property? > >> /* x refers to an object representing an element in the document */ >> x.style.position = "absolute"; >> x.style.left = "10px"; >> x.style.top = "20px"; >> x.style.width = "100px"; >> x.style.height = "200px"; >> x.style.color = "blue"; >> >> No, if you think about it a bit harder, > > Please do not presume how "hard" others think. Or, if you cannot help > making such presumptions, don't air them publicly. I do not need to make a lot of assumptions here. Reading your arguments, you are obviously too much concentrated on your use case to consider the needs of different ones. >> you will find that you really don't want that. > > I take it that you mean "Imagine what would happen if you apply many > successive changes to an element, causing many recalculations of the > page layout". (Like if `x.style.position = "absolute";` were the *last* > instruction in your example rather than the first, and anybody would > be crazy enough to actually do things like that.) > > My point is that one should never write it that way. Rather (assuming > HTML or XHTML with default namespace): > > var new_x = x.cloneNode(true); > > new_x.style.position = "absolute"; > new_x.style.left = "10px"; > new_x.style.top = "20px"; > new_x.style.width = "100px"; > new_x.style.height = "200px"; > new_x.style.color = "blue"; > > x.parentNode.replaceChild(new_x, x); Why should I replace an element with its clone when I could simply modify its properties? That does not make a lot of sense, and it is considerably less efficient both with regard to runtime and memory. You must have never written any *serious* DOM scripts, like animations, or you are just pretending. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 16:17
Johannes Baagoe wrote: > Sean Kinsey : >> Johannes Baagoe : >>> var new_x = x.cloneNode(true); >>> >>> new_x.style.position = "absolute"; >>> new_x.style.left = "10px"; >>> new_x.style.top = "20px"; >>> new_x.style.width = "100px"; >>> new_x.style.height = "200px"; >>> new_x.style.color = "blue"; >>> >>> x.parentNode.replaceChild(new_x, x); > >> Unfortunately, this wouldn't work well with attached event listeners >> now would it? > > You are right, it wouldn't. But then, the example is hardly realistic, Rest assured the lines between cloneNode() and replaceChild() are very realistic. > and it would be even less so if x had lots of attached event listeners > in addition to the folly of changing its position to "absolute". Just because you do not understand the use-case it is not a folly. >> Take for instance gmail, when you tick the 'check all' checkbox, >> would you have gmail clone and remove the entire parent container? For >> just setting a couple of setAttribute("checked","checked") calls? > > No, that would not be necessary, since checking boxes do not affect > the layout. Utter nonsense. 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 |