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

[bugzilla-daemon at webkit.org]

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

Sergio Villar Senin <svillar at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |svillar at igalia.com

--- Comment #2 from Sergio Villar Senin <svillar at igalia.com> ---
(In reply to comment #1)
> 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 DrawingAreaImpl not reply back to the
> UI process after calling viewportSizeChanged() and add a wayt to be notified
> by the layer tree host when everything is ready to send the message back.

This is why I think that UI side compositing is much more appealing from the user POV, because you see immediate response to your actions like resizing or scrolling. It does not really matter that you don't have the final rendering very quickly because you could still do things like scrolling, zooming or resizing with the last rendered content while waiting for the webprocess to do all the heavy rendering stuff.

-- 
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/20160302/1a0c0eb9/attachment.html>