Use compositor with select popups.

Use compositor with select popups.

BUG=271575
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=165977

[jamesr, 2014-01-21 21:59:23]

Do we have to do the tree setup/etc on the blink side for these?  We do that for
WebViewImpls since we have to set up the scroll layer in a special way, but if
this only has one painted layer it might be easier to do things on the
content/renderer/ side and just expose a paint callback through to blink.

https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
File Source/web/WebPopupMenuImpl.cpp (right):

https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
Source/web/WebPopupMenuImpl.cpp:239: m_client->didInvalidateRect(IntRect(0, 0,
m_size.width, m_size.height));
hmm, does this mean the popups are still switching between composited and
non-composited mode?

https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
File Source/web/WebPopupMenuImpl.h (right):

https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
Source/web/WebPopupMenuImpl.h:64: , public WebCore::FramelessScrollViewClient
this formatting is very funky - I don't think we do the leading comma thing for
subclasses in blink, just for initializers in constructors

[jamesr, 2014-01-21 22:01:28]

If we did that we could also maybe hide the enter/leaving composited mode crap
too.

[jbauman, 2014-01-21 22:08:55]

On 2014/01/21 21:59:23, jamesr wrote:
> Do we have to do the tree setup/etc on the blink side for these?  We do that
for
> WebViewImpls since we have to set up the scroll layer in a special way, but if
> this only has one painted layer it might be easier to do things on the
> content/renderer/ side and just expose a paint callback through to blink.

That might work, but I think it makes more sense to leave the content/renderer
code alone and just always create the compositor in blink, so the interface is
more uniform. Maybe we can move more of the compositor setup code for every case
into the renderwidget at some point.
> 
>
https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
> File Source/web/WebPopupMenuImpl.cpp (right):
> 
>
https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
> Source/web/WebPopupMenuImpl.cpp:239: m_client->didInvalidateRect(IntRect(0, 0,
> m_size.width, m_size.height));
> hmm, does this mean the popups are still switching between composited and
> non-composited mode?

Only on systems that don't have a software compositor (linux gtk for now). Once
we're rid of those, we should be able to kill a bunch of this fallback code.
> 
>
https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
> File Source/web/WebPopupMenuImpl.h (right):
> 
>
https://codereview.chromium.org/132173005/diff/50001/Source/web/WebPopupMenuI...
> Source/web/WebPopupMenuImpl.h:64: , public WebCore::FramelessScrollViewClient
> this formatting is very funky - I don't think we do the leading comma thing
for
> subclasses in blink, just for initializers in constructors

The presubmit complained about this before I changed it, though maybe I
misinterpreted its complaint.

[jamesr, 2014-01-24 18:36:56]

Fix up the formatting then lgtm.  Do we have to force these to be s/w comp (on
the chromium side) to deal with crbug.com/333380 ?

[jbauman, 2014-01-24 23:45:26]

On 2014/01/24 18:36:56, jamesr wrote:
> Fix up the formatting then lgtm.  Do we have to force these to be s/w comp (on
> the chromium side) to deal with crbug.com/333380 ?

I don't think so (select popups didn't seem to be affected by that bug, so
hopefully they won't be affected by the fix), but I'll have to check to be sure.

[jamesr, 2014-01-24 23:47:41]

I think the key bit is if they are top-level windows they might be impacted.  If
they aren't, no worries.

[commit-bot: I haz the power, 2014-01-29 00:08:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jbauman@chromium.org/132173005/170001

[commit-bot: I haz the power, 2014-01-29 00:14:47]

Change committed as 165977

[commit-bot: I haz the power, 2014-01-29 00:16:46]

CQ bit was unchecked on CL. Ignoring.