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: Stanimir Stamenkov on 18 Apr 2010 12:15 Sat, 17 Apr 2010 22:59:05 +0200, /Thomas 'PointedEars' Lahn/: > It is impossible for the DOM implementation to know what you are up to, so > many implementors take the conservative approach and queue all your DOM > "requests" until there is sufficient time allocated to the process to do so. > That is a Good Thing! After all, reflows are usually of less importance > than the script that is currently running. Think about it: Usually you do > not want to trigger a reflow every time you modify properties of a DOM > object; that would make the DOM-accessing script very slow. The DOM changes happen immediately. It is just the style/view/reflow which doesn't happen immediately. Implementations may invalidate certain view state on DOM changes immediately and then recompute and redraw when the script finishes. -- Stanimir
From: Jorge on 18 Apr 2010 12:22 On Apr 18, 5:54 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > VK wrote: > > > Learn Javascript, improve your practical programming skills, find > > topic more interesting than "JavaScript doesn't exist". > > > If you need an opponent on "JavaScript vs. Javascript vs. javascript > > vs. ECMAScript" or "HTML5 - does it exist or not?" or "getElementById > > method is missing - how should we properly workaround this actual > > problem" - if that then don't knock my door for that. ;-) > > <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: replace your window.onload with this one in order to see: window.onload= function (now) { now= +new Date()+ 20e3; while(+new Date() < now) {} init(); }; -- Jorge.
From: Thomas 'PointedEars' Lahn on 18 Apr 2010 12:23 Stanimir Stamenkov wrote: > Sat, 17 Apr 2010 22:59:05 +0200, /Thomas 'PointedEars' Lahn/: >> It is impossible for the DOM implementation to know what you are up to, >> so many implementors take the conservative approach and queue all your >> DOM "requests" until there is sufficient time allocated to the process to >> do so. >> That is a Good Thing! After all, reflows are usually of less importance >> than the script that is currently running. Think about it: Usually you >> do not want to trigger a reflow every time you modify properties of a DOM >> object; that would make the DOM-accessing script very slow. > > The DOM changes happen immediately. It is just the > style/view/reflow which doesn't happen immediately. Implementations > may invalidate certain view state on DOM changes immediately and > then recompute and redraw when the script finishes. I believe I have just said that. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: VK on 18 Apr 2010 12:34 > > <http://pointedears.de/scripts/test/dom/events/window-onload.mpeg> > > > Will you *please* shut up now? > > Why ? > He's right. Of course I am. It is an *applied* programming basic. Migrating C+ +'ers and Java'ers are definitely excused, but you really need to come to c.l.j. as the only place to make a surprise for claimed Javascript programmers :-)
From: Stanimir Stamenkov on 18 Apr 2010 12:41
Sun, 18 Apr 2010 18:23:12 +0200, /Thomas 'PointedEars' Lahn/: > Stanimir Stamenkov wrote: > >> The DOM changes happen immediately. It is just the >> style/view/reflow which doesn't happen immediately. Implementations >> may invalidate certain view state on DOM changes immediately and >> then recompute and redraw when the script finishes. > > I believe I have just said that. Sorry, I haven't really understood it that way. Sat, 17 Apr 2010 22:59:05 +0200, /Thomas 'PointedEars' Lahn/: > It is impossible for the DOM implementation to know what you are up to, > so many implementors take the conservative approach and queue all your > DOM "requests" until there is sufficient time allocated to the process to > do so. The above tells me pretty much unambiguously DOM changes may not happen immediately but would be queued for later execution somehow. If you've really meant changes to the view and not the DOM, then it should have been said more clear using the right term, IMO. -- Stanimir |