Event wanted after page is refreshed
in [JavaScript]
|
Prev: Earn Money from Home as Part Time Job!
Next: FAQ Topic - Why do I get permission denied when accessing a frame/window? (2009-12-27)
From: David Mark on 13 Jan 2010 04:07 Jorge wrote: > On Jan 13, 9:40 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> (...) >> It's a simple click listener that needs to prevent re-entry in some >> cases. (...) > > Mine not only does, but in addition warrants a redraw between sorts > (e.g. if the user clicked on a second column while the previous sort > was still running). Not only does what?! And "warrants a redraw?" What do any of your posts mean?
From: Jorge on 13 Jan 2010 04:35 On Jan 13, 10:07 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > Not only does what?! And "warrants a redraw?" What do any of your > posts mean? Too much thinking for you today... :-) -- Jorge.
From: David Mark on 13 Jan 2010 04:38 Jorge wrote: > On Jan 13, 10:07 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> Not only does what?! And "warrants a redraw?" What do any of your >> posts mean? > > Too much thinking for you today... :-) No, too much time reading your ludicrous one-liners. :(
From: Hans-Georg Michna on 13 Jan 2010 04:52 On Wed, 13 Jan 2010 03:46:42 -0500, David Mark wrote: >Hans-Georg Michna wrote: >> Most browsers don't even render to screen, as long as any >> JavaScript task is running, with the exception of Opera. >That's incorrect. They virtually all re-flow on exiting an execution >context. Though it makes no difference for this "problem" (can't stress >that enough), it is very useful to know this. > >So if you see code that sets multiple styles and it calls a function to >set a single style in a loop (sound familiar?), you can figure on at >least one and maybe n re-flows during that loop. I see these patterns >all the time and adjusting them out usually leads to huge performance >increases (with very little effort invested), particularly for large and >complex DOM's (the norm, of course). You are saying that most browsers re-render to screen while some JavaScript code is still to be or being executed? I haven't seen that. What I see is that the browsers, except perhaps Opera, don't do anything at all on screen until the JavaScript code finishes execution or is killed because it ran for too long. But I haven't done any exhausting tests on this. Has anybody else here tested this thoroughly? Hans-Georg
From: Jorge on 13 Jan 2010 04:59
On Jan 13, 10:52 am, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > On Wed, 13 Jan 2010 03:46:42 -0500, David Mark wrote: > >Hans-Georg Michna wrote: > >> Most browsers don't even render to screen, as long as any > >> JavaScript task is running, with the exception of Opera. > >That's incorrect. They virtually all re-flow on exiting an execution > >context. Though it makes no difference for this "problem" (can't stress > >that enough), it is very useful to know this. > > >So if you see code that sets multiple styles and it calls a function to > >set a single style in a loop (sound familiar?), you can figure on at > >least one and maybe n re-flows during that loop. I see these patterns > >all the time and adjusting them out usually leads to huge performance > >increases (with very little effort invested), particularly for large and > >complex DOM's (the norm, of course). > > You are saying that most browsers re-render to screen while some > JavaScript code is still to be or being executed? I haven't seen > that. What I see is that the browsers, except perhaps Opera, > don't do anything at all on screen until the JavaScript code > finishes execution or is killed because it ran for too long. > > But I haven't done any exhausting tests on this. Has anybody > else here tested this thoroughly? A reflow is not a redraw. There's (usually) many (more) reflows per redraw. Reflows happen during normal JS execution, but redraws (exception: Opera) don't. -- Jorge. |