[webkit-reviews] review requested: [Bug 22738] Get rid of animation start, end and iteration timers : [Attachment 25848] Patch to fix bug

[bugzilla-daemon at webkit.org]

Chris Marrin <cmarrin at apple.com> has asked  for review:
Bug 22738: Get rid of animation start, end and iteration timers
https://bugs.webkit.org/show_bug.cgi?id=22738

Attachment 25848: Patch to fix bug
https://bugs.webkit.org/attachment.cgi?id=25848&action=review

------- Additional Comments from Chris Marrin <cmarrin at apple.com>
	Fixed https://bugs.webkit.org/show_bug.cgi?id=22738

	This gets rid of the per-animation timers which were used when an
animation
	started, ended and looped. Their job is now done by the main
AnimationController's
	timer. It is now set to fire as needed. For instance, if there is a
delay, it will
	fire after the delay time and then every 30ms to run the animation. The
start, loop
	and end events are generated as needed during the firing of this timer.


	I had to add one more bit of code. When animation timers used to fire
the animation events.
	This would always happen from the RunLoop, so any style changes that
happened in the
	event handler would get picked up on the next updateRendering() call.
But now the start
	event is generated during the styleIsAvailable() call, which is in the
middle of the 
	updateRendering() cycle. And calling an event handler in the middle of
updateRendering()
	is not allowed and causes style changes to get missed. We already have
a mechanism in
	AnimationController to defer updateRendering() calls. So I added logic
to defer all
	event handling to there. Now, I put any request for event handling into
a list and ask
	for a deferred updateRendering() call. When that deferred timer fires,
I go through that
	list, send all the events and then call updateRendering().