[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

--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #8)
> I know that for non-threaded compositor task the resize is already an almost
> sync operation

It doesn't really matter whether to use the threaded compositor or not, the UI process sends a messages and keeps waiting until the resize is done, so it's *always* a sync operation.

> but making resizing in the threaded compositor sync as well
> seems a step in the wrong direction.

My first attempt to fix this was to wait until the resize is done in the compositor thread to reply back to the UI process, but it didn't really work. Between the time the task is scheduled and when it's done all other updates that happens in the compositor thread end upo producing flickering and rendering artifacts. Note that resizing is not a so common operation and it's usually done by user interaction, so it's impossible that the user notices any block or hang.

> I think that being out of sync for some time is OK-ish.

Have you seen the effects of that? The flickering and rendering artifacts are embarrassing and annoying. Doing it sync makes everything smooth.

> Isn't it possible to
> ask the WP to resize the backing store and return immediately?

The main problem of this is that the backing store in this case is not in the web process, but in the UI process. In non-accelerated compositing mode there are two backing stores, one in the UI process and one in the web process. When there's a resize a message is sent to the web process that resizes its backing store and redraws. When it replies back to the UI process the backing store in the UI process is then resized and the new image is rendered. In AC mode the backing store in the Ui process is the redirected window, and the web process renders directly into it. So, when a resize happens, we need to resize the redirected window before sending the message the web process, then we send the message that updates the GL viewport to the new size and schedules a layer flush.

-- 
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/20160613/69affebf/attachment.html>