Force update of on screen render after DOM element change
joebloe
googling hasn't produced a useful answer for me. I'm looking for the
equivalent of insert_magic_here() in:
some_element.style.color = 'red';
insert_magic_here();
some_element.style.color = 'blue';
insert_magic_here();
where insert_magic_here() 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
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.
Jeremy J Starcher
> 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_here() in:
>
> some_element.style.color = 'red';
> insert_magic_here();
> some_element.style.color = 'blue';
> insert_magic_here();
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_here() 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
> 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_here() in:
>
> > some_element.style.color = 'red';
> > insert_magic_here();
> > some_element.style.color = 'blue';
> > insert_magic_here();
>
> 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
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
You've got me curious now.
Care to share a URL?