Force update of on screen render after DOM element change

[joebloe]

I know this question comes up from time to time, but 10-15 minutes of
googling hasn't produced a useful answer for me. I'm looking for the
equivalent of insert_magic_he re() in:

some_element.st yle.color = 'red';
insert_magic_he re();
some_element.st yle.color = 'blue';
insert_magic_he re();

where insert_magic_he re() will cause the updated DOM to be rendered
immediately. I need to do some animation in the middle of an event
handler (keypress). Is the basic problem that Firefox doesn't do the
on screen render until the event handler returns? Or ...? Anyway there
is quite a bit of work to do after this completes, including,
potentially, many other similar sequences of events.

If it helps, this code is intended to run only in JavaScript >= 1.7,
with Firefox as a reference platform.

I can come up with various painful ways to do this with closures and
so on but I am looking for something that won't serve as an entry in
an obfuscated Javascript contest. Also I haven't looked at generators
as a solution yet.

Your Help Is Appreciated(TM) .

[joebloe]

Re: Force update of on screen render after DOM element change

Continuing, the simplest approach I've come up with, so far, is to
accumulate drawing requests in an Array as I handle the event,
with each object in the array specifying stuff that has to be
drawn atomically and a delay to be applied before the next
drawing happens, and then schedule all that to be processed after
the event handler returns. This would be fairly efficient and
possibly not drive the garbage collector crazy. I still have
to block receipt/processing of the next keypress until that
completes, though.

On May 16, 10:00 am, joebloe <remid0d...@gma il.comwrote:

I know this question comes up from time to time, but 10-15 minutes of
googling hasn't produced a useful answer for me. I'm looking for the
equivalent of insert_magic_he re() in:
>
some_element.st yle.color = 'red';
insert_magic_he re();
some_element.st yle.color = 'blue';
insert_magic_he re();
>
where insert_magic_he re() will cause the updated DOM to be rendered
immediately. I need to do some animation in the middle of an event
handler (keypress). Is the basic problem that Firefox doesn't do the
on screen render until the event handler returns? Or ...? Anyway there
is quite a bit of work to do after this completes, including,
potentially, many other similar sequences of events.
>
If it helps, this code is intended to run only in JavaScript >= 1.7,
with Firefox as a reference platform.
>
I can come up with various painful ways to do this with closures and
so on but I am looking for something that won't serve as an entry in
an obfuscated Javascript contest. Also I haven't looked at generators
as a solution yet.

[Jeremy J Starcher]

Re: Force update of on screen render after DOM element change

On Fri, 16 May 2008 10:00:18 -0700, joebloe wrote:

I know this question comes up from time to time, but 10-15 minutes of
googling hasn't produced a useful answer for me. I'm looking for the
equivalent of insert_magic_he re() in:
>
some_element.st yle.color = 'red';
insert_magic_he re();
some_element.st yle.color = 'blue';
insert_magic_he re();

Javascript is single threaded and (usually) runs in the same thread as
the window. As such, the window itself does not update while Javascript
is running. You must use one of the timeout features to allow the window
to refresh then start running the script again.

where insert_magic_he re() will cause the updated DOM to be rendered
immediately. I need to do some animation in the middle of an event
handler (keypress).

Is the basic problem that Firefox doesn't do the on
screen render until the event handler returns?

Correct.

Or ...? Anyway there is
quite a bit of work to do after this completes, including, potentially,
many other similar sequences of events.
>
If it helps, this code is intended to run only in JavaScript >= 1.7,
with Firefox as a reference platform.

Because of the highly dynamic nature of the software, and web browsers in
particular, I would hesitate to come up with any solution that only
worked in any single User Agent.

>
I can come up with various painful ways to do this with closures and so
on but I am looking for something that won't serve as an entry in an
obfuscated Javascript contest. Also I haven't looked at generators as a
solution yet.

Depending on the exact nature of your code, you might be able to use a
single global object to store important values from one execution to the
next.

Your Help Is Appreciated(TM) .

[joebloe]

Re: Force update of on screen render after DOM element change

On May 16, 1:06 pm, Jeremy J Starcher <r3...@yahoo.co mwrote:

On Fri, 16 May 2008 10:00:18 -0700, joebloe wrote:

I know this question comes up from time to time, but 10-15 minutes of
googling hasn't produced a useful answer for me. I'm looking for the
equivalent of insert_magic_he re() in:

>

some_element.st yle.color = 'red';
insert_magic_he re();
some_element.st yle.color = 'blue';
insert_magic_he re();

>
Javascript is single threaded and (usually) runs in the same thread as
the window. As such, the window itself does not update while Javascript
is running. You must use one of the timeout features to allow the window
to refresh then start running the script again.

I was aware that on at least some level (window, document, browser,
whatever) the execution model for JS is single threaded, but I wasn't
aware that rendering thread == execution thread. Well, okay, that
makes much more sense then. I'm going to give my "logic first, render
second" approach a try; should work fine but I hope there's not too
much memory management churn as a result. In other words, the stuff
that is animated, I'll generate a sequence of actions for, then
execute those with a series of timeout events.

If it helps, this code is intended to run only in JavaScript >= 1.7,
with Firefox as a reference platform.

>
Because of the highly dynamic nature of the software, and web browsers in
particular, I would hesitate to come up with any solution that only
worked in any single User Agent.

What I'm working on doesn't need to be portable in the short term; if
a year goes by and no more 1.7 support is on the horizon, then I'll
fix it for whatever else is available at that time. But for now you
will pry my 'let' from my cold, dead hands.

Depending on the exact nature of your code, you might be able to use a
single global object to store important values from one execution to the
next.

That won't really fly; there are 1000s of lines of code that have to
be executed serially per keypress event.

This is an oddball application; I'll drop a URL later if it gets
anywhere.

[joebloe]

Re: Force update of on screen render after DOM element change

Well this was entertaining to solve. I wound up postponing my drawing
until after the keypress event handler, then drawing a bit at a time
with timeout events. Had to disable the keypress handler while that
was going on; once I did that, each separate bit was rendered after
its timeout function returned. It's a little weird to wrap your head
around at first, but it works pretty well.

[Jeremy J Starcher]

Re: Force update of on screen render after DOM element change

On Mon, 19 May 2008 10:42:45 -0700, joebloe wrote:

Well this was entertaining to solve. I wound up postponing my drawing
until after the keypress event handler, then drawing a bit at a time
with timeout events. Had to disable the keypress handler while that was
going on; once I did that, each separate bit was rendered after its
timeout function returned. It's a little weird to wrap your head around
at first, but it works pretty well.

You've got me curious now.

Care to share a URL?