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.
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.