[Webkit-unassigned] [Bug 154070] [Threaded Compositor] Flickering and rendering artifacts when resizing the web view

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 26 05:57:58 PST 2016


--- Comment #1 from Carlos Garcia Campos <cgarcia at igalia.com> ---
I've been investigating this and I think I know what's going on. First lets see how resize works in non-threaded compositor case. 

1- The web view is resized (size-allocate), and it notifies the DrawingArea.
2.- DrawingAreaProxyImpl creates a new backing store state ID and notifies the web process about it asking it to reply immediately. It waits for the reply up to 500ms.
3.- In the web process DrawingAreaImpl updates its backing store state ID to the given one, and sets the new size in the web page and layer tree host. then sends a message to the UI process that stops waiting.

This way, while the web process is updating for the new size, the UI process doesn't render anything, and when it finishes waiting, the backing stores in both web and UI are in sync in terms of size. 

This doesn't work with the threaded compositor and we end up rendering in the UI process with the new size while the web process is still using the old size. The problem is in the step 3), in non-threaded compositor case, the layer tree host updates everything (layer sizes), and it repaints so that when we reply back to the UI process, the layers are already using the new size and new contents have been rendered. In the threaded-compositor case this happens asynchronously, we have to go notify the compositing thread and when updated this notifies the main thread back. But when we reply to the UI process, the compositing thread hasn't been notified yet or it hasn't painted anything yet. So, I think we have to wait until everything has been updated to the new size and contents have been repainted to reply back to the UI process. In other words, we need to make ThreadedCoordinatedLayerTreeHost::viewportSizeChanged() sync and wait until everything has been updated, or make DrawingAreaImp

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160226/2c057578/attachment-0001.html>

More information about the webkit-unassigned mailing list