[Webkit-unassigned] [Bug 93146] Coordinated Graphics: Enable threaded animations

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=93146





--- Comment #4 from Huang Dongsung <luxtella at company100.net>  2012-10-17 01:49:58 PST ---
(In reply to comment #3)
> Yes, that's they way it was before. The problem (which is solvable, but tricky) is in synchronization.

Thanks for explanation! I understand.

> We've had cases where, for example, an animated layer stops being composited, and then it gets repainted with the rest of the "non-composited" content.
> The issue is that if painting the non-composited contents takes too much time, there might be a few extra animation frames in the UI process, which would go beyond the end point of the animation. If we can fix that, we can bring back UI-side animations...

I agree that we can get succinct code and relatively fast css animations by threaded animations.

I also understand why chromium compositor has duplicated code to make progress animations in both main thread and impl thread after reading your explanation.
Chromium Compositor(a.k.a CC) delegates impl thread to make progress animations in default (like UI-side animations). The code is in CCLayerTreeHostImpl::animateLayers()
However, When CC must synchronize animations between both thread, main thread makes progress animaitions (like threaded animations). The code is in CCLayerTreeHost::animateLayers()

I prefer threaded animations in now.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.