WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
142347
[GTK] Contents not shown when entering AC mode unless the window is resized
https://bugs.webkit.org/show_bug.cgi?id=142347
Summary
[GTK] Contents not shown when entering AC mode unless the window is resized
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.
Top of Page
Format For Printing
XML
Clone This Bug