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 19 Apr 2010 18:25 Jeremy J Starcher wrote: > Thomas 'PointedEars' Lahn wrote: >> Jeremy J Starcher wrote: >>> The browser window is single threaded. >> Where did you get that piece of "wisdom" from? > > The same place we get the wisdom about other things that are not exactly > specified in the specifications, or the same way we get the wisdom that > things that /are/ in the specs yet implemented poorly. > > By observation and a bit of logic. You are a poor observer and reasoner then, because there are *a lot* of examples to easily disprove your statement. You could, for example, try Firebug's Net tab and see resources being loaded in parallel in Firefox, in the same browser tab. You could observe changes of the pointer of the pointing-device while the document is still begin loaded. You could observe that you can still type in the Address Bar then, that you can still show one of the browser's menus etc. pp. > [snip misconceptions] 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: Thomas 'PointedEars' Lahn on 19 Apr 2010 18:29 Johannes Baagoe wrote: > Stefan Weiss : >> There is a (rather hackish) way to encourage some browsers to do an >> immediate redraw, even in the middle of a running script. >> >> What it comes down to is letting some element on the page scroll by >> setting its scrollTop or scollLeft properties. That's probably even >> worse than "abusing" setTimeout, and it hurts the script's overall >> performance, but since you wanted a forced redraw, and the only answer >> was "can't be done"... I've added an example at the end. > > Yes, well, that is *much* too hackish for my taste, but I admire the > ingenuity. > >> Personally, I wouldn't try to force redraws at all. I would break up a >> long running calculation into steps, using setTimeout to connect them. > > That is what I ended up with doing, before asking the group if there > was a better way, and being told that there isn't. I have told you a different, less hackish way: threaded scripting native to recent JavaScript. It is possible that other recent implementations support that approach, too. Whether it qualifies as "better", though, depends on your definition of "better". PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Johannes Baagoe on 19 Apr 2010 21:54 Jorge : > function time /*contextContainer*/ (elements) { > function time1 (element) { ... } > function resetHandlers () { ... } > > (function loop /*iCarryTheContext*/ (e) { > if (e= elements.shift()) reset(e), time1(e); if (elements.length) > setTimeout(loop, 0); else resetHandlers(); > })(); > } I quite like that, many thanks. I have changed my code accordingly on http://baagoe.com/en/RandomMusings/javascript/time.js (With one tiny change, though - but which may be worth a separate thread, since it is a detail that appears again and again in javascript, and has not particular relevance to window refreshing via the DOM.) -- Johannes
From: Thomas 'PointedEars' Lahn on 22 Apr 2010 11:27 Johannes Baagoe wrote: > Thomas 'PointedEars' Lahn : >> Johannes Baagoe : >>> 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. > > It has been there since REC-DOM-Level-1-19981001. What earlier DOM > implementations do you have in mind? That which are known as "DOM Level 0", on which the W3C DOM is based, of course. <http://www.w3.org/TR/DOM-Level-2-HTML/glossary.html#dt-DOM-Level-0> >>> 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. > > If the rules are silent, it seems to me that the prudent approach is > to assume the worst, and to code accordingly. > > Which in this case means never update a visible DOM object unless > you are willing to risk it to be rendered immediately. See above. >> 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. > > Goodness! It was about replacing "<th/>" with "<th></th>". And other tags, including <script ../>. > [...] >> And when there is empirical evidence that something works as described >> you demand a specification reference before you would reconsider >> your design decision. > > Well, yes, I have never been much of a fan of trial and error. I > am surprised that you seem to rely on observed behaviour instead of > assuming the worst that could happen on a *conforming* platform. See above. You are ignoring the need for backwards compatibility in implementations. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Bwig Zomberi on 21 Apr 2010 06:34
Thomas 'PointedEars' Lahn wrote: > Jeremy J Starcher wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Jeremy J Starcher wrote: >>>> The browser window is single threaded. >>> Where did you get that piece of "wisdom" from? >> >> The same place we get the wisdom about other things that are not exactly >> specified in the specifications, or the same way we get the wisdom that >> things that /are/ in the specs yet implemented poorly. >> >> By observation and a bit of logic. > > You are a poor observer and reasoner then, because there are *a lot* of > examples to easily disprove your statement. You could, for example, try > Firebug's Net tab and see resources being loaded in parallel in Firefox, in > the same browser tab. You could observe changes of the pointer of the > pointing-device while the document is still begin loaded. You could observe > that you can still type in the Address Bar then, that you can still show one > of the browser's menus etc. pp. Just because an application performs several activities simultaneously does not mean it is multi-threaded. In event-driven programming, a single thread can create the illussion of parallel threads. It is called time-slicing and the technology is several decades old now. Windows of most browsers today have multiple threads. Browser code may or may not actively spawn those threads. Most of the time, runtime used by the browser code spawns those threads. Actual details can be known from people knowledgeable with the code base. Chrome creates a parent process (not thread), which spawns a child process for each tab. You an use Process Explorer from Microsoft SysInternals to check the details. -- Bwig Zomberi |