Bug 158689 - [GTK] Web view is not redrawn when reparented in force compositing mode
Summary: [GTK] Web view is not redrawn when reparented in force compositing mode
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks: 154444
  Show dependency tree / graph
 
Reported: 2016-06-13 04:55 PDT by Carlos Garcia Campos
Modified: 2016-06-21 04:05 PDT (History)
8 users (show)

See Also:

Attachments
Patch (9.69 KB, patch)
2016-06-13 05:06 PDT, Carlos Garcia Campos 		no flags Details | Formatted Diff | Diff
Updated patch (9.69 KB, patch)
2016-06-14 22:56 PDT, Carlos Garcia Campos 		zan: review+
Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2016-06-13 04:55:03 PDT 
This is easy to reproduce undocking the inspector:

1- Run MiniBrowser with WEBKIT_FORCE_COMPOSITING_MODE=1
2- Open the inspector
3- Click on undock button

The new window is created and the view is moved there but nothing is rendered. you need to force a redraw, by resizing the window, for example, to see the contents. This also happen when using the threaded compositor, since compositing mode is always enabled too.
Comment 1 Carlos Garcia Campos 2016-06-13 05:06:12 PDT 
Created attachment 281167 [details]
Patch
Comment 2 WebKit Commit Bot 2016-06-13 05:08:00 PDT 
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment 3 Michael Catanzaro 2016-06-13 08:47:52 PDT 
Does this fix the similar bug that occurs when resizing the window?
Comment 4 Carlos Garcia Campos 2016-06-13 23:48:41 PDT 
(In reply to comment #3)
> Does this fix the similar bug that occurs when resizing the window?

I don't know I haven't noticed that. Do you mean when resizing the window with the threaded compositor or without it but compositing mode forced?
Comment 5 Michael Catanzaro 2016-06-14 08:05:26 PDT 
(In reply to comment #4)
> (In reply to comment #3)
> > Does this fix the similar bug that occurs when resizing the window?
> 
> I don't know I haven't noticed that. Do you mean when resizing the window
> with the threaded compositor or without it but compositing mode forced?

With compositing mode, without threaded compositor... but actually, I can't reproduce it anymore. Let's forget about it for now; maybe it got fixed at some point.
Comment 6 Michael Catanzaro 2016-06-14 08:06:36 PDT 
Comment on attachment 281167 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=281167&action=review

(I think Zan would be a better reviewer for this.)

> Source/WebKit2/ChangeLog:9
> +        mode when the view is unrealized, because the native surface handle por compositing is destroyed, but it doesn't

for ;)

> Source/WebKit2/ChangeLog:12
> +        not. The Web process never exits accelerated mode when compositing mode is forzed, but the UI process doesn't

forced
Comment 7 Carlos Garcia Campos 2016-06-14 22:56:27 PDT 
Created attachment 281337 [details]
Updated patch

Previous patch broke the build with redirected X window disabled because of a wrong ifdef.
Comment 8 Zan Dobersek 2016-06-21 03:39:02 PDT 
Comment on attachment 281337 [details]
Updated patch

LGTM.
Comment 9 Carlos Garcia Campos 2016-06-21 04:05:15 PDT 
Committed r202273: <http://trac.webkit.org/changeset/202273>