Bug 105466

Created attachment 180232 [details] Patch

In theory, web process could send its pending delete layer events right before the flush event to ui process, but if the ui process runs a paint in between, it will cause a sync which will run those deletions without the flush, which would be an observable blink. I could not reproduce this sequence of events though, web process seems to send them in a batch of events to ui process, neither the ui process seems to read the incomplete sequence of events. What do you think?

Comment on attachment 180232 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=180232&action=review Could you check if there is no flash in http://media.24ways.org/2009/14/5/index.html after this patch. And Could you tell me which site flash that this patch fixes. In Bug 103522, I replaced detachedLayer after flushing layer states, because I wanted to fix above site flash. And this patch replaces again detachedLayer before flushing layer states. > Source/WebKit2/UIProcess/CoordinatedGraphics/LayerTreeRenderer.cpp:648 > + m_detachedLayers.clear(); It is not thread-safe. The rendering thread of QtQuick2 calls syncRemoteContent().

Comment on attachment 180232 [details] Patch This is the wrong way to go about it; You should accumulate the layersToDelete in the UI process, and then perform the actual deletion upon flush.

Created attachment 184149 [details] Test case - a blink in the end of animation when messages are sent right away

Created attachment 184151 [details] Changing CoreIPC to send messages right away to show bug and delaying web process This is a bit old patch showing how to reproduce this bug, by making CoreIPC send messages right away instead of scheduling. So right before WebProcess deliver "didRenderFrame", we could have done a series of delayed delete layers events. The blink occurs because we deliver those events on UIProcess and process them while painting (running animations make UIProcess schedule paints on its own).

I think this problem was "fixed" when we switched to "full state commits" rather than "action commits" that would sum themselves and define the changed state (i.e add and remove layers), so I'm closing this bug.