Bug 82406 - [chromium] Compositor visibility setting must be updated even if not actively compositing
Summary: [chromium] Compositor visibility setting must be updated even if not actively...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Vangelis Kokkevis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-27 17:55 PDT by Vangelis Kokkevis
Modified: 2012-03-28 11:24 PDT (History)
8 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Vangelis Kokkevis 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.
Comment 1 James Robinson 2012-03-27 18:17:41 PDT
Created attachment 134189 [details]
Patch
Comment 2 James Robinson 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.
Comment 3 Vangelis Kokkevis 2012-03-27 18:28:56 PDT
Comment on attachment 134189 [details]
Patch

(unofficial) R+ .  This will do the trick.
Comment 4 Nat Duca 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?
Comment 5 Nat Duca 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. :(
Comment 6 Adrienne Walker 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?
Comment 7 James Robinson 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.
Comment 8 James Robinson 2012-03-27 21:18:18 PDT
Created attachment 134212 [details]
Patch
Comment 9 Adrienne Walker 2012-03-28 10:53:22 PDT
Comment on attachment 134212 [details]
Patch

R=me.
Comment 10 WebKit Review Bot 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>
Comment 11 WebKit Review Bot 2012-03-28 11:24:26 PDT
All reviewed patches have been landed.  Closing bug.