Bug 142347

Summary:

[GTK] Contents not shown when entering AC mode unless the window is resized

Product:

WebKit

Reporter:

Carlos Garcia Campos <cgarcia>

Component:

WebKitGTK

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

berto, commit-queue, gustavo, mrobinson, zan

Priority:

Keywords:

Gtk, Regression

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Patch	none
Updated patch	zan: review+

Carlos Garcia Campos

Reported 2015-03-05 09:16:52 PST

This can be easily reproduced with the simple tests case joanie posted in bug #142333. <html> <body> <div style="-webkit-transform: translate3d(0, 0, 0);">foo</div> </body> </html> Just open that in MiniBrowser, not always but very often the foo text is not shown. Resize the window and it appears. The problem is once again that we are now creating the redirected X window in realize method. When entering AC mode we resize the redirected window to the drawing area size. since the size hasn't changed from the drawing area point of view, the web process is not notified. The WebProcess always uses the window size, instead of the root layer size, to make sure it's in sync, see the comment in LayerTreeHostGtk::compositeLayersToContext(). So, we need to enforce a resize when we change the size of the redirected window when entering AC mode.

Attachments
Patch (2.65 KB, patch) 2015-03-05 09:18 PST, Carlos Garcia Campos	no flags	Details Formatted Diff Diff
Updated patch (3.28 KB, patch) 2015-03-08 04:01 PDT, Carlos Garcia Campos	zan: review+	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Carlos Garcia Campos

Comment 1 2015-03-05 09:18:53 PST

Created attachment 247956 [details] Patch

WebKit Commit Bot

Comment 2 2015-03-05 09:20:29 PST

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

Carlos Garcia Campos

Comment 3 2015-03-08 04:01:34 PDT

Created attachment 248187 [details] Updated patch I've realized that my previous patch only worked for the case when we enter AC mode after the web view is realized. If it's happens before, we have a pending resize on map, and we do the actual resize after the web view is realized and mapped. In that case we also need to enforce a resize to make sure the web process uses the right context size.

Zan Dobersek

Comment 4 2015-03-08 10:44:11 PDT

Comment on attachment 248187 [details] Updated patch OK.

Carlos Garcia Campos

Comment 5 2015-03-09 02:07:27 PDT

hmm, I'm still not sure this patch is enough :-( I've noticed that the problem still happens when the web process enters in AC mode before the web view is realized, not that often, but still happens. The thing is that the web process enters in AC mode, and the layer tree host is created, but without a native window handle. Thant means that from the UI process point of view we haven't entered AC mode, because the layer tree context (which is the native window handle) is still 0. When the web view is realized, we create the redirected window, but we don't know id the web process is in AC mode or not, so we always create the window at 1x1, and we send the native window handle. Then the texture mapper is created in the web process and layers are flushed. Layers are composited to context for resizing, but using a 1x1 context size. The next DidUpdateBackingStoreState message received in the UI process contains the layer tree context, and then is when we enter AC mode from the UI process point of view, and we resize the redirected composite window. So, I think the problem is that point where the web process is in AC mode, but the UI isn't. Maybe we could notify the UI process somehow when the layer tree host is created, and if we still don't have a valid layer tree context we know we are waiting for the native window handle. When the web view is realized, if we know that the web process is in AC mode, we can create the redirected window with the right size and we don't need to resize it. The problem I'm seeing when the web process enters AC mode before the web view is realized is not exactly the same than the other case, contents are rendered, but layout is not correct. So, maybe this is a different issue. It's easy to reproduce with epiphany: 1- Go to google, and search for something you know will give a youtube link 2- Middle click the youtube link to open a new tab 3- Visit the tab After 3, sometimes the layout of youtube is like if the web view were a lot smaller (like the mobile layout, using a single column).

Carlos Garcia Campos

Comment 6 2015-03-09 02:45:49 PDT

I'm not sure the problem i actually related to the accelerated compositing mode, I've managed to reproduce the issue disabling AC, it didn't happen that often, but I could still reproduce the problem. So, maybe this is a completely different issue, more related with the layout, and probably related with the delayed resize we do when the web view hasn't been mapped yet.

Carlos Garcia Campos

Comment 7 2015-03-10 06:39:07 PDT

Committed r181324: <http://trac.webkit.org/changeset/181324>

Carlos Garcia Campos

Comment 8 2015-03-10 06:40:12 PDT

Landed the first patch in the end, since the other problem seems to be a different issue, I'll open a new bug report for that.

Note You need to log in before you can comment on or make changes to this bug.