RESOLVED FIXED Bug 82406
[chromium] Compositor visibility setting must be updated even if not actively compositing
https://bugs.webkit.org/show_bug.cgi?id=82406
Summary [chromium] Compositor visibility setting must be updated even if not actively...
Vangelis Kokkevis
Reported 2012-03-27 17:55:34 PDT
This is a problem surfaced by the following bug: http://code.google.com/p/chromium/issues/detail?id=119812 WebViewImpl::setVisibilityState() only updates the visibility state in the compositor if it's in accelerated compositing mode. However, if a page falls out of compositing mode while it's hidden (e.g. a html5 video stops playing while the tab is not visible) then switching back to the tab never notifies the compositor that it has become visible again.
Attachments
Patch (1.69 KB, patch)
2012-03-27 18:17 PDT, James Robinson
no flags
Patch (1.60 KB, patch)
2012-03-27 21:18 PDT, James Robinson
no flags
James Robinson
Comment 1 2012-03-27 18:17:41 PDT
James Robinson
Comment 2 2012-03-27 18:18:56 PDT
Vangelis, do you know any way to confirm whether this patch fixes that bug? This is a blind fix (didn't even compile check) but seems like the behavior we want.
Vangelis Kokkevis
Comment 3 2012-03-27 18:28:56 PDT
Comment on attachment 134189 [details] Patch (unofficial) R+ . This will do the trick.
Nat Duca
Comment 4 2012-03-27 19:08:27 PDT
Comment on attachment 134189 [details] Patch Mmm I like this! We should do this regardless. Which draws my attention to another thing: if we create a layer tree view in !visible, we get the visibility wrong too, e.g. setIsAcceleratedCompositingActive. Can we fold a fix into there too?
Nat Duca
Comment 5 2012-03-27 19:09:38 PDT
Comment on attachment 134189 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=134189&action=review > Source/WebKit/chromium/src/WebViewImpl.cpp:3459 > + if (!visible && isAcceleratedCompositingActive()) This feels like a wart incidentally. I never knew this was here until just now. :(
Adrienne Walker
Comment 6 2012-03-27 19:10:49 PDT
Comment on attachment 134189 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=134189&action=review > Source/WebKit/chromium/src/WebViewImpl.cpp:3460 > - if (!visible) > - m_nonCompositedContentHost->protectVisibleTileTextures(); > m_layerTreeView.setVisible(visible); > + if (!visible && isAcceleratedCompositingActive()) > + m_nonCompositedContentHost->protectVisibleTileTextures(); Er, why is the call to protectVisibleTileTextures reordered? Don't we need to protect before setVisible which may drop tiles?
James Robinson
Comment 7 2012-03-27 21:15:41 PDT
(In reply to comment #6) > (From update of attachment 134189 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=134189&action=review > > > Source/WebKit/chromium/src/WebViewImpl.cpp:3460 > > - if (!visible) > > - m_nonCompositedContentHost->protectVisibleTileTextures(); > > m_layerTreeView.setVisible(visible); > > + if (!visible && isAcceleratedCompositingActive()) > > + m_nonCompositedContentHost->protectVisibleTileTextures(); > > Er, why is the call to protectVisibleTileTextures reordered? Don't we need to protect before setVisible which may drop tiles? Whoops, I did not mean to change that order. Will fix.
James Robinson
Comment 8 2012-03-27 21:18:18 PDT
Adrienne Walker
Comment 9 2012-03-28 10:53:22 PDT
Comment on attachment 134212 [details] Patch R=me.
WebKit Review Bot
Comment 10 2012-03-28 11:24:21 PDT
Comment on attachment 134212 [details] Patch Clearing flags on attachment: 134212 Committed r112417: <http://trac.webkit.org/changeset/112417>
WebKit Review Bot
Comment 11 2012-03-28 11:24:26 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.