From: Jorge on
On Apr 19, 6:48 am, Johannes Baagoe <baa...(a)baagoe.com> wrote:
> Jorge:
>
> > (function contextContainer () {
> >   var contextData;
>
> >   (function iCarryTheContext () {
> >     workOn(contextData);
> >     !done() && setTimeout(iCarryTheContext, 0);
> >   })();
>
> > })();
>
> I presume that should be (you seem to have dropped a part in a
> copy/paste):
>
>   (function contextContainer () {
>     var contextData;
>
>     (function iCarryTheContext () {
>       do {
>         workOn(contextData);
>       } while (!done() && setTimeout(iCarryTheContext, 0));
>     })();
>
>   })();

No, no no.
--
Jorge.
From: Jorge on
On Apr 19, 6:48 am, Johannes Baagoe <baa...(a)baagoe.com> wrote:
>
> I see. What I had in mind was more basic, like
>
>   for (var i = 0; i < someLargeishNumber; i++) {
>     someJustAcceptablySlowFunction();
>     yield();
>   }
>
> or even
>
>    someJustAcceptablySlowFunction();
>    yield();
>    anotherJustAcceptablySlowFunction();
>    yield();
>
> etc.  

But normally you would have put this code inside a function, wouldn't
you ?
--
Jorge.
From: Johannes Baagoe on
Jorge :

> No, no no.

:) Got it. I was familiar with the '&&' idiom in shell scripts and Perl,
but it had never occurred to me that it could be used outside of
`if` and `while` conditions in javascript, too.

--
Johannes
From: Johannes Baagoe on
Jorge :

> I hope there is a good reason why they've decided that only a few
> events are to be handled synchronously (behaving ~ as interrupts),
> and the rest -most of them- are to be queued to be dispatched later.

On http://baagoe.com/en/RandomMusings/javascript/time.xhtml you may
get an idea of what kind of mess results by clicking several times on
"Time all", and then, when strange results appear, click on one or
two of those. Note in which order the cells get updated.

But it won't last for long - I shall make a click on "Time all"
remove the event listeners on all cells and on the button itself for
the duration of the tests. Which I should have done long ago.

--
Johannes
From: Jorge on
On Apr 19, 1:34 am, Stefan Weiss <krewech...(a)gmail.com> wrote:
> On 18/04/10 19:32, Johannes Baagoe wrote:
>
> > Jorge :
> >> Johannes Baagoe :
>
> >>> 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".
>
> There is a (rather hackish) way to encourage some browsers to do an
> immediate redraw, even in the middle of a running script. I've never
> needed this myself, but the question looked interesting, and what I came
> up with appears to work in FF 3.0 and MSIE 6+7; Opera didn't behave as
> nicely. I haven't tested any other browsers, and I wouldn't expect it to
> work everywhere.

Hi Stefan,

It works for me in Opera and Flock, but not in Safari, Chrome,
FF2..3.6, NSNavigator, iCab3.05 nor IE5.2.3, on Mac OSX 10.6.3.

BTW I seem to recall that Mozilla once had a command to redraw, but
I'm unable to find it and I don't remember its name. And as I might be
mistaken I didn't want to say a word about it. Well, I did, now.

Note that the way Pointy cheats, the screen is always redrawn: just
put an alert("")... :-)
--
Jorge.