From: David Mark on
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
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
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
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
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.