| 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: | P2 | Keywords: | Gtk, Regression | ||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
|
Description
Carlos Garcia Campos
2015-03-05 09:16:52 PST
Created attachment 247956 [details]
Patch
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 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.
Comment on attachment 248187 [details]
Updated patch
OK.
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). 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. Committed r181324: <http://trac.webkit.org/changeset/181324> 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. |