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 07:06 On Apr 18, 4:46 am, Johannes Baagoe <baa...(a)baagoe.com> wrote: > (...) > But I still do not see what difference it makes to the browser being or > not capable of checking periodically whether there is some modification > of `document.documentElement` that requires that it re-renders the > window, or some part of it. > > That being said, if most implementers have decided in their wisdom > that the average DOM programmer cannot be expected to learn how to > use DocumentFragments and that one has to protect them against their > own stupidity, there is nothing I can do about it. 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". 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. So, the question, rather, might be -given that it's not a good idea in any case- whether we do really need .renderNow(). ¿? Because there's no way that I can think of to solve/workaround the blocked UI/event dispatch issue you'd run into in long running pieces of code. For this reason we have recently been given the Workers. They're not perfect, they can share no data, you can't pass nothing but strings to/ from them, but they provide any number of separate JS threads/ processes, fwiw, in a fool-proof way: a while (1) {} in a worker can't/ won't block anything but the worker's own thread/process, and even in that event, the parent can still kill it. -- Jorge.
From: VK on 18 Apr 2010 08:30 On Apr 18, 3:06 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > 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". Correction: it would be a Super Good Thing :-) A regular natural and well explainable "laziness" of software developers: nothing properly working should be changed for time and money and by introducing a new bugs risk - unless it is needed for surviving on the market. window.repaint method will appear eventually but now the push is not high enough. Opera is just the first try of the kind. window.repaint obviously will have to be a synchronized method. It may be called at the same system tick several time, it may be called from several places over setTimeout, so it has to be a queue, buffer, blah- blah-blah. After all such script can work for hours then (Javascript 3D graphics, movies, visualizations etc. which are around the corner already). Then it can be interaction blocking or interaction allowing script - in the latter case IRQ request listeners from keyboard, mouse or touchscreen. So it is a hell of work to be done and eventually it will be done by the winners (and the next wave of losers will go away). But sofar it is still possible and it is way much simpler to have the prehistoric "maximum script execution time limit" and "let them solve their problems with setTimeout".
From: VK on 18 Apr 2010 08:51 While the situation is as it is: one crucial point to remember about onload handlers - *a lot* of sites keep being affected by it. window.onload / body onload= / addEventListener('load',.. do not mean "display the page and start the script execution" 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. For a lengthly initial page scripting the user might look at a blank script too long wondering if the page exists at all. So unless it is needed to be so, always exit from the execution context first, then start to do your stuff. In the sample below run it first as it is. Then comment window.onload = releaseContextAndInit; and uncomment window.onload = init; Watch when "Startup page content" first appear in either case. Make the conclusion and forward to all your programming involved friends. Keep in secret from your programming involved enemies :-) :-| <!DOCTYPE html> <html> <head> <title>Untitled Document</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <script type="text/javascript"> function init() { var out = document.getElementById('out'); for (var i=0; i<5000; i++) { (out.appendChild(document.createElement('P'))).innerHTML = i; } } function releaseContextAndInit() { window.setTimeout('init()', 500); } //window.onload = init; window.onload = releaseContextAndInit; </script> </head> <body> <h1>Startup page content</h1> <div id="out"></div> </body> </html>
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 09:19 VK wrote: > While the situation is as it is: one crucial point to remember about > onload handlers - *a lot* of sites keep being affected by it. > > window.onload / body onload= / addEventListener('load',.. > do not mean "display the page and start the script execution" > > 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. Nonsense. 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 09:31
On Apr 18, 5:19 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > VK wrote: > > While the situation is as it is: one crucial point to remember about > > onload handlers - *a lot* of sites keep being affected by it. > > > window.onload / body onload= / addEventListener('load',.. > > do not mean "display the page and start the script execution" > > > 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. > > Nonsense. The test case is posted. I hope I can skip at least on step-by-step instructions how to copy it, paste it into an editor, save as a (X)HTML page and open in a browser. So much you should now. |