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: Thomas 'PointedEars' Lahn on 18 Apr 2010 13:22 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. > 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? 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)? 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: VK on 18 Apr 2010 13:29 On Apr 18, 9:22 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > 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)? Thomas, just relax - there will be your day - but another day. I do practical programming, so I am making mistakes left and right, so it will be an opportunity to criticize, believe you me. :-)
From: Johannes Baagoe on 18 Apr 2010 13:32 Jorge : > Johannes Baagoe : >> I shall therefore continue to misuse setTimeouts. I hoped there >> would be a better way, but apparently, there is not. > You're right: there's no better way. Currently only Opera renders DOM > changes to the screen in parallel with JS execution (in a separate > thread, or process, or whatever). I agree with you that something > along the lines of a ~ window.renderNow() would be a Good Thing™, > and it wouldn't "break the web". If the rule is that by default, modifications of a visible DOM object are accumulated without action by the layout engine until the return of the event handler or listener that caused them, that rule should be stated explicitly, and there should be a standard and convenient way to override the default. Like window.renderNow(), or similar. (I can see at least one, very pragmatic reason for such a rule. If it is not enforced and some fool's code therefore makes the page get madly re-flowed during the execution of a script, visitors tend to blame the browser, not the script kiddy.) > Note however that in any case it's not a good idea to have your single > thread of JS code running without interruptions for long periods of > time, as event dispatching cycles would not have any chance to run > in the meanwhile, and as a consequence the page's UI would turn out > to be badly blocked too. Quite, and that is another issue that needs addressing: the lamentable fact that user scripts may block the general operation of the browser. (By "user scripts", I mean those that are provided by what script language implementers call an "user", i.e., a programmer who uses that language in their implementation. Let us call it the "unresponsiveness issue", and the other one the "delayed rendering issue". Both may be solved by the same hack given the way most current browsers work, but they are quite unrelated from a logical point of view. A browser might implement time-sharing between user scripts and its other jobs (thus solving the unresponsiveness issue) and *still* not render before the user script's current event-handling procedure returns. And it just conceivably might render "on the fly" without taking the opportunity to react to other events. The second case seems very silly, but the first could be advocated by those who think it is all right to make many successive changes that affect the layout, and that it is the browser's job, not theirs, to accumulate such changes before the layout engine takes them into account. 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. 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". 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. -- Johannes
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 13:37 VK wrote: > Thomas 'PointedEars' Lahn wrote: >> 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)? > > Thomas, just relax - there will be your day - but another day. Shut up. > I do practical programming, I hope I'll never have to use a piece of software written by you. > so I am making mistakes left and right, Tell me something I don't know yet. > so it will be an opportunity to criticize, believe you me. You haven't answered the question. Figures. BTW, you can shovel your smileys where the sun doesn't shine. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Johannes Baagoe on 18 Apr 2010 13:59
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, 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". > 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. What is needed to convince me is a realistic example of repeated changes that affect the layout, and could only at great expense be performed outside of already laid out element. Perhaps a large table with lots of event listeners whose cell contents get updated to something longer or shorter, but even then, I need to understand why the function that set up the event listeners on the first instance cannot be reapplied to the new copy, or why it would be expensive. -- Johannes |