WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(1.60 KB, patch)
2012-03-27 21:18 PDT
,
James Robinson
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
James Robinson
Comment 1
2012-03-27 18:17:41 PDT
Created
attachment 134189
[details]
Patch
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
Created
attachment 134212
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug