My understanding of the Mozilla system is that it has real trouble
firing timers at the correct times because of the additional
processing delays you described.
I think our current model is sound (given that we have to process
these timers on the main thread anyway, so they all wait on one
another regardless), with the caveat that we should always be on the
lookout for any timers that can take a long time, since we'll want to
add code to force those kinds of callbacks to break up their work (we
do this already when parsing for example, and we also warn about slow
JS).
It's also worth noting that the OS X timer is very accurate, but the
current Windows code is just using SetTimer, and so is very
inaccurate. Any testing should be done on OS X only, since the Win32
timer code imposes additional processing delays because it lacks high
resolution timing. In my experiments, some DHTML movement test cases
can be as much as 1.5-2x slower on Win32 than OS X because of this
issue.
dave
On Jan 11, 2007, at 7:10 PM, Don Gibson wrote:
I've been looking at the code in Timer.cpp lately, and I have a
vague worry that there might be problems, but no real concrete
testcases of something actually being wrong.
When firing timers, we set a single system timer for the soonest
timer. When it goes off, TimerBase::fireTimers() sequentially
pulls off all the timers in the ready queue and fires them. This
firing is done via callback directly to the fire handlers, which
can take arbitrary time to execute. More worryingly, we process
all timers before returning to the global message loop. I'm
concerned that setting a large number of timers, or having handlers
that take a while to execute, could cause poor performance/
responsiveness due to starving the global message loop.
The Mozilla timer system gets around this problem by posting
individual messages to the main message queue for each timer that
needs to fire instead of directly calling back to handlers from the
timer-processing loop. However, this means the actual firing of
each timer is additionally delayed by other processing other items
in the message queue. Also, a careless design for this could queue
up multiple "timer fired" messages for a timer that was behind on
processing them. (Imagine an autoscroll timer set to repeat every
100 ms, and a page that took a long time to do individual paints.
Multiple scroll messages might queue up by the time the user's
mouse input messages could be processed to cancel the scroll,
leading to scrolling continuing for a while after the user had
cancelled.)
Still, even with these concerns, I wonder if the Mozilla system
might not be better. Any thoughts on particular cases that would
perform poorly in either system, or whether this change would be
beneficial?
Don
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
