Add a flag use_software_compositing to the Widget::InitParams structure.

Add a flag use_software_compositing to the Widget::InitParams structure.

This flag when set will force the widget to use the software compositor on Windows. Currently only the menu
omnibox drop down and status bubble widgets set this flag. The flag defaults to false.

This removes the old hack of using the menu type to determine whether the software compositor should be used
on Windows.

BUG=508717
R=sky

Committed: https://crrev.com/82c3ae62ef39c74658610a3f4b28cc99c9c60287
Cr-Commit-Position: refs/heads/master@{#352405}

[sky, 2015-10-05 15:06:00]

How come we only need to do this for some TYPE_POPUPS? Why doesn't the bug
effect all?

[ananta, 2015-10-05 15:47:06]

On 2015/10/05 15:06:00, sky wrote:
> How come we only need to do this for some TYPE_POPUPS? Why doesn't the bug
> effect all?

Ideally we don't want to do this for any window. However given that compositing
windows can block the UI thread we want to avoid this as much
as possible especially for windows like the omnibox drop down which display in
response to user action. Once the bug mentioned in the comments is addressed we
can remove this flag.

[sky, 2015-10-05 16:02:43]

I wasn't suggesting any window, but widgets of TYPE_POPUP. Again,
what's different about the status bubble and omnibox that we need to
special case them? To be clear, I'm not opposed to adding special
casing if needed, but I'm not understanding why we need to treat the
omnibox popup and status bubble differently then say a bookmark
bubble.

  -Scott

On Mon, Oct 5, 2015 at 8:47 AM,  <ananta@chromium.org> wrote:
> On 2015/10/05 15:06:00, sky wrote:
>>
>> How come we only need to do this for some TYPE_POPUPS? Why doesn't the bug
>> effect all?
>
>
> Ideally we don't want to do this for any window. However given that
> compositing
> windows can block the UI thread we want to avoid this as much
> as possible especially for windows like the omnibox drop down which display
> in
> response to user action. Once the bug mentioned in the comments is addressed
> we
> can remove this flag.
>
>
>
>
> https://codereview.chromium.org/1380973003/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[ananta, 2015-10-05 16:06:20]

On 2015/10/05 16:02:43, sky wrote:
> I wasn't suggesting any window, but widgets of TYPE_POPUP. Again,
> what's different about the status bubble and omnibox that we need to
> special case them? To be clear, I'm not opposed to adding special
> casing if needed, but I'm not understanding why we need to treat the
> omnibox popup and status bubble differently then say a bookmark
> bubble.
> 
>   -Scott
> 
> On Mon, Oct 5, 2015 at 8:47 AM,  <mailto:ananta@chromium.org> wrote:
> > On 2015/10/05 15:06:00, sky wrote:
> >>
> >> How come we only need to do this for some TYPE_POPUPS? Why doesn't the bug
> >> effect all?
> >
> >
> > Ideally we don't want to do this for any window. However given that
> > compositing
> > windows can block the UI thread we want to avoid this as much
> > as possible especially for windows like the omnibox drop down which display
> > in
> > response to user action. Once the bug mentioned in the comments is addressed
> > we
> > can remove this flag.
> >
> >
> >
> >
> > https://codereview.chromium.org/1380973003/
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

The bookmark bubble for e.g. needs animation. That does not work well with
software compositing.
Again the other bubbles show up in uncommon actions. We want the normal use case
to not feel slow.

[sky, 2015-10-05 17:41:23]

Ok, LGTM

[ananta, 2015-10-05 19:15:50]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2015-10-05 19:17:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1380973003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1380973003/20001

[commit-bot: I haz the power, 2015-10-05 20:18:59]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-10-05 20:20:33]

Patchset 2 (id:??) landed as
https://crrev.com/82c3ae62ef39c74658610a3f4b28cc99c9c60287
Cr-Commit-Position: refs/heads/master@{#352405}