Revert of [Mac] Fix rough-looking profile picker text, especially with a dark theme.

Revert of [Mac] Fix rough-looking profile picker text, especially with a dark theme. (patchset #9 id:180001 of https://codereview.chromium.org/2430493002/ )

Reason for revert:
FullscreenControllerTest.FullscreenOnFileURL from browser_tests flakes chromium.mac/Mac10.10 Tests builder.

Original issue's description:
> [Mac] Fix rough-looking profile picker text, especially with a dark theme.
> 
> Issue 593835 shows the AvatarButton's text having jagged, rainbow tinted
> edges. It turns out that the text cell gets a hint about anti-aliasing
> from the NSVisualEffect view below it, but the hint is wrong because the
> NSVisualEffectView is itself below the theme background.
> 
> This only happens when the NSVisualEffectView's blendingMode is set to
> NSVisualEffectBlendingModeBehindWindow (which makes the content behind
> the window show through with a blur effect). To create the effect, the
> view cuts a hole in the window and generates a mask which the window
> server uses to render a translucent material behind the window.
> 
> Because the translucent parts of the window are invisible to the app,
> the text can't render itself with correct subpixel anti-aliasing, which
> needs information about the background. To help, NSVisualEffectView
> implements two undocumented methods:
> `-shouldSetFontSmoothingBackgroundColor` and
> `-_backgroundColorForFontSmoothing`. It provides the base color of the
> translucent material, and for the purpose of antialiasing the text cell
> pretends that it's over an opaque background of that color. Because the
> translucency effect is subtle, it's not obvious that the antialiasing is
> done with a fixed color.
> 
> NSView implements these methods to first search its immediate subviews
> and return the first YES/non-nil answer, or return NO/nil if
> `self.opaque == YES`, then tail call the same method on its superview.
> 
> A quirk of this strategy is that, to provide a background color to a
> text view, an NSVisualEffectView must be either a superview or an
> immediate subview of a superview. So, the AvatarButton's text does get a
> background color hint with the current hierarchy:
> 
>     - NSThemeFrame
>        |- NSVisualEffectView
>        |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> …but, if the NSVisualEffectView were wrapped in another view, it doesn't
> (because each step of the search just looks at immediate subviews):
> 
>     - NSThemeFrame
>        |- NSView
>        | |- NSVisualEffectView
>        | |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> Anyway, back on topic, our issue is that the text cell accepts the
> hinted background color, which is never right since Chrome always
> draws a tint over the visual effect view, and in some cases the hint is
> drastically wrong.
> 
> Ideally, we'd provide a fake background for the text to perform subpixel
> anti-aliasing against, but it's unclear how to do that. For now, the
> simplest solution is to wrap it in another view.
> 
> This CL sucks all of the tab strip background drawing into
> TabStripBackgroundView, and makes it so that other views don't need to
> know about the NSVisualEffectView at all.
> 
> It also only creates the NSVisualEffectView when it's used, and gets rid
> of it when it's not used (like in full screen, or when a theme is
> installed).
> 
> BUG=593835
> 
> Review-Url: https://codereview.chromium.org/2430493002
> Cr-Commit-Position: refs/heads/master@{#443707}
> Committed: https://chromium.googlesource.com/chromium/src/+/a5fd3c415f3cc4f8813ba9772d838bee41040ae8

TBR=spqchan@chromium.org,avi@chromium.org,rsesek@chromium.org,sdy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=593835, 681772
Review-Url: https://codereview.chromium.org/2638873002
Cr-Commit-Position: refs/heads/master@{#444028}
Committed: https://chromium.googlesource.com/chromium/src/+/23d8cf2f9da96b2e9e3496738688b6e9615ea094

[pkalinnikov, 2017-01-17 09:54:41]

Created Revert of [Mac] Fix rough-looking profile picker text, especially with a
dark theme.

[pkalinnikov, 2017-01-17 09:55:38]

Description was changed from

==========
Revert of [Mac] Fix rough-looking profile picker text, especially with a dark
theme. (patchset #9 id:180001 of https://codereview.chromium.org/2430493002/ )

Reason for revert:
FullscreenControllerTest.FullscreenOnFileURL from browser_tests flakes
chromium.mac/Mac10.10 Tests builder.

Original issue's description:
> [Mac] Fix rough-looking profile picker text, especially with a dark theme.
> 
> Issue 593835 shows the AvatarButton's text having jagged, rainbow tinted
> edges. It turns out that the text cell gets a hint about anti-aliasing
> from the NSVisualEffect view below it, but the hint is wrong because the
> NSVisualEffectView is itself below the theme background.
> 
> This only happens when the NSVisualEffectView's blendingMode is set to
> NSVisualEffectBlendingModeBehindWindow (which makes the content behind
> the window show through with a blur effect). To create the effect, the
> view cuts a hole in the window and generates a mask which the window
> server uses to render a translucent material behind the window.
> 
> Because the translucent parts of the window are invisible to the app,
> the text can't render itself with correct subpixel anti-aliasing, which
> needs information about the background. To help, NSVisualEffectView
> implements two undocumented methods:
> `-shouldSetFontSmoothingBackgroundColor` and
> `-_backgroundColorForFontSmoothing`. It provides the base color of the
> translucent material, and for the purpose of antialiasing the text cell
> pretends that it's over an opaque background of that color. Because the
> translucency effect is subtle, it's not obvious that the antialiasing is
> done with a fixed color.
> 
> NSView implements these methods to first search its immediate subviews
> and return the first YES/non-nil answer, or return NO/nil if
> `self.opaque == YES`, then tail call the same method on its superview.
> 
> A quirk of this strategy is that, to provide a background color to a
> text view, an NSVisualEffectView must be either a superview or an
> immediate subview of a superview. So, the AvatarButton's text does get a
> background color hint with the current hierarchy:
> 
>     - NSThemeFrame
>        |- NSVisualEffectView
>        |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> …but, if the NSVisualEffectView were wrapped in another view, it doesn't
> (because each step of the search just looks at immediate subviews):
> 
>     - NSThemeFrame
>        |- NSView
>        | |- NSVisualEffectView
>        | |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> Anyway, back on topic, our issue is that the text cell accepts the
> hinted background color, which is never right since Chrome always
> draws a tint over the visual effect view, and in some cases the hint is
> drastically wrong.
> 
> Ideally, we'd provide a fake background for the text to perform subpixel
> anti-aliasing against, but it's unclear how to do that. For now, the
> simplest solution is to wrap it in another view.
> 
> This CL sucks all of the tab strip background drawing into
> TabStripBackgroundView, and makes it so that other views don't need to
> know about the NSVisualEffectView at all.
> 
> It also only creates the NSVisualEffectView when it's used, and gets rid
> of it when it's not used (like in full screen, or when a theme is
> installed).
> 
> BUG=593835
> 
> Review-Url: https://codereview.chromium.org/2430493002
> Cr-Commit-Position: refs/heads/master@{#443707}
> Committed:
https://chromium.googlesource.com/chromium/src/+/a5fd3c415f3cc4f8813ba9772d83...

TBR=spqchan@chromium.org,avi@chromium.org,rsesek@chromium.org,sdy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=593835
==========

to

==========
Revert of [Mac] Fix rough-looking profile picker text, especially with a dark
theme. (patchset #9 id:180001 of https://codereview.chromium.org/2430493002/ )

Reason for revert:
FullscreenControllerTest.FullscreenOnFileURL from browser_tests flakes
chromium.mac/Mac10.10 Tests builder.

Original issue's description:
> [Mac] Fix rough-looking profile picker text, especially with a dark theme.
> 
> Issue 593835 shows the AvatarButton's text having jagged, rainbow tinted
> edges. It turns out that the text cell gets a hint about anti-aliasing
> from the NSVisualEffect view below it, but the hint is wrong because the
> NSVisualEffectView is itself below the theme background.
> 
> This only happens when the NSVisualEffectView's blendingMode is set to
> NSVisualEffectBlendingModeBehindWindow (which makes the content behind
> the window show through with a blur effect). To create the effect, the
> view cuts a hole in the window and generates a mask which the window
> server uses to render a translucent material behind the window.
> 
> Because the translucent parts of the window are invisible to the app,
> the text can't render itself with correct subpixel anti-aliasing, which
> needs information about the background. To help, NSVisualEffectView
> implements two undocumented methods:
> `-shouldSetFontSmoothingBackgroundColor` and
> `-_backgroundColorForFontSmoothing`. It provides the base color of the
> translucent material, and for the purpose of antialiasing the text cell
> pretends that it's over an opaque background of that color. Because the
> translucency effect is subtle, it's not obvious that the antialiasing is
> done with a fixed color.
> 
> NSView implements these methods to first search its immediate subviews
> and return the first YES/non-nil answer, or return NO/nil if
> `self.opaque == YES`, then tail call the same method on its superview.
> 
> A quirk of this strategy is that, to provide a background color to a
> text view, an NSVisualEffectView must be either a superview or an
> immediate subview of a superview. So, the AvatarButton's text does get a
> background color hint with the current hierarchy:
> 
>     - NSThemeFrame
>        |- NSVisualEffectView
>        |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> …but, if the NSVisualEffectView were wrapped in another view, it doesn't
> (because each step of the search just looks at immediate subviews):
> 
>     - NSThemeFrame
>        |- NSView
>        | |- NSVisualEffectView
>        | |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> Anyway, back on topic, our issue is that the text cell accepts the
> hinted background color, which is never right since Chrome always
> draws a tint over the visual effect view, and in some cases the hint is
> drastically wrong.
> 
> Ideally, we'd provide a fake background for the text to perform subpixel
> anti-aliasing against, but it's unclear how to do that. For now, the
> simplest solution is to wrap it in another view.
> 
> This CL sucks all of the tab strip background drawing into
> TabStripBackgroundView, and makes it so that other views don't need to
> know about the NSVisualEffectView at all.
> 
> It also only creates the NSVisualEffectView when it's used, and gets rid
> of it when it's not used (like in full screen, or when a theme is
> installed).
> 
> BUG=593835
> 
> Review-Url: https://codereview.chromium.org/2430493002
> Cr-Commit-Position: refs/heads/master@{#443707}
> Committed:
https://chromium.googlesource.com/chromium/src/+/a5fd3c415f3cc4f8813ba9772d83...

TBR=spqchan@chromium.org,avi@chromium.org,rsesek@chromium.org,sdy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=593835,681772
==========

[pkalinnikov, 2017-01-17 09:56:27]

The CQ bit was checked by pkalinnikov@chromium.org

[commit-bot: I haz the power, 2017-01-17 09:56:43]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[pkalinnikov, 2017-01-17 09:58:43]

The CQ bit was unchecked by pkalinnikov@chromium.org

[pkalinnikov, 2017-01-17 11:34:31]

The CQ bit was checked by pkalinnikov@chromium.org

[commit-bot: I haz the power, 2017-01-17 11:34:48]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-17 11:38:41]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1484652871108620, "parent_rev":
"f518baaa99a18fb01196946dafe59218ffbf4285", "commit_rev":
"23d8cf2f9da96b2e9e3496738688b6e9615ea094"}

[commit-bot: I haz the power, 2017-01-17 11:39:10]

Description was changed from

==========
Revert of [Mac] Fix rough-looking profile picker text, especially with a dark
theme. (patchset #9 id:180001 of https://codereview.chromium.org/2430493002/ )

Reason for revert:
FullscreenControllerTest.FullscreenOnFileURL from browser_tests flakes
chromium.mac/Mac10.10 Tests builder.

Original issue's description:
> [Mac] Fix rough-looking profile picker text, especially with a dark theme.
> 
> Issue 593835 shows the AvatarButton's text having jagged, rainbow tinted
> edges. It turns out that the text cell gets a hint about anti-aliasing
> from the NSVisualEffect view below it, but the hint is wrong because the
> NSVisualEffectView is itself below the theme background.
> 
> This only happens when the NSVisualEffectView's blendingMode is set to
> NSVisualEffectBlendingModeBehindWindow (which makes the content behind
> the window show through with a blur effect). To create the effect, the
> view cuts a hole in the window and generates a mask which the window
> server uses to render a translucent material behind the window.
> 
> Because the translucent parts of the window are invisible to the app,
> the text can't render itself with correct subpixel anti-aliasing, which
> needs information about the background. To help, NSVisualEffectView
> implements two undocumented methods:
> `-shouldSetFontSmoothingBackgroundColor` and
> `-_backgroundColorForFontSmoothing`. It provides the base color of the
> translucent material, and for the purpose of antialiasing the text cell
> pretends that it's over an opaque background of that color. Because the
> translucency effect is subtle, it's not obvious that the antialiasing is
> done with a fixed color.
> 
> NSView implements these methods to first search its immediate subviews
> and return the first YES/non-nil answer, or return NO/nil if
> `self.opaque == YES`, then tail call the same method on its superview.
> 
> A quirk of this strategy is that, to provide a background color to a
> text view, an NSVisualEffectView must be either a superview or an
> immediate subview of a superview. So, the AvatarButton's text does get a
> background color hint with the current hierarchy:
> 
>     - NSThemeFrame
>        |- NSVisualEffectView
>        |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> …but, if the NSVisualEffectView were wrapped in another view, it doesn't
> (because each step of the search just looks at immediate subviews):
> 
>     - NSThemeFrame
>        |- NSView
>        | |- NSVisualEffectView
>        | |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> Anyway, back on topic, our issue is that the text cell accepts the
> hinted background color, which is never right since Chrome always
> draws a tint over the visual effect view, and in some cases the hint is
> drastically wrong.
> 
> Ideally, we'd provide a fake background for the text to perform subpixel
> anti-aliasing against, but it's unclear how to do that. For now, the
> simplest solution is to wrap it in another view.
> 
> This CL sucks all of the tab strip background drawing into
> TabStripBackgroundView, and makes it so that other views don't need to
> know about the NSVisualEffectView at all.
> 
> It also only creates the NSVisualEffectView when it's used, and gets rid
> of it when it's not used (like in full screen, or when a theme is
> installed).
> 
> BUG=593835
> 
> Review-Url: https://codereview.chromium.org/2430493002
> Cr-Commit-Position: refs/heads/master@{#443707}
> Committed:
https://chromium.googlesource.com/chromium/src/+/a5fd3c415f3cc4f8813ba9772d83...

TBR=spqchan@chromium.org,avi@chromium.org,rsesek@chromium.org,sdy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=593835,681772
==========

to

==========
Revert of [Mac] Fix rough-looking profile picker text, especially with a dark
theme. (patchset #9 id:180001 of https://codereview.chromium.org/2430493002/ )

Reason for revert:
FullscreenControllerTest.FullscreenOnFileURL from browser_tests flakes
chromium.mac/Mac10.10 Tests builder.

Original issue's description:
> [Mac] Fix rough-looking profile picker text, especially with a dark theme.
> 
> Issue 593835 shows the AvatarButton's text having jagged, rainbow tinted
> edges. It turns out that the text cell gets a hint about anti-aliasing
> from the NSVisualEffect view below it, but the hint is wrong because the
> NSVisualEffectView is itself below the theme background.
> 
> This only happens when the NSVisualEffectView's blendingMode is set to
> NSVisualEffectBlendingModeBehindWindow (which makes the content behind
> the window show through with a blur effect). To create the effect, the
> view cuts a hole in the window and generates a mask which the window
> server uses to render a translucent material behind the window.
> 
> Because the translucent parts of the window are invisible to the app,
> the text can't render itself with correct subpixel anti-aliasing, which
> needs information about the background. To help, NSVisualEffectView
> implements two undocumented methods:
> `-shouldSetFontSmoothingBackgroundColor` and
> `-_backgroundColorForFontSmoothing`. It provides the base color of the
> translucent material, and for the purpose of antialiasing the text cell
> pretends that it's over an opaque background of that color. Because the
> translucency effect is subtle, it's not obvious that the antialiasing is
> done with a fixed color.
> 
> NSView implements these methods to first search its immediate subviews
> and return the first YES/non-nil answer, or return NO/nil if
> `self.opaque == YES`, then tail call the same method on its superview.
> 
> A quirk of this strategy is that, to provide a background color to a
> text view, an NSVisualEffectView must be either a superview or an
> immediate subview of a superview. So, the AvatarButton's text does get a
> background color hint with the current hierarchy:
> 
>     - NSThemeFrame
>        |- NSVisualEffectView
>        |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> …but, if the NSVisualEffectView were wrapped in another view, it doesn't
> (because each step of the search just looks at immediate subviews):
> 
>     - NSThemeFrame
>        |- NSView
>        | |- NSVisualEffectView
>        | |  |- TabStripBackgroundView
>        |- FullSizeContentView
>           |- AvatarButton
> 
> Anyway, back on topic, our issue is that the text cell accepts the
> hinted background color, which is never right since Chrome always
> draws a tint over the visual effect view, and in some cases the hint is
> drastically wrong.
> 
> Ideally, we'd provide a fake background for the text to perform subpixel
> anti-aliasing against, but it's unclear how to do that. For now, the
> simplest solution is to wrap it in another view.
> 
> This CL sucks all of the tab strip background drawing into
> TabStripBackgroundView, and makes it so that other views don't need to
> know about the NSVisualEffectView at all.
> 
> It also only creates the NSVisualEffectView when it's used, and gets rid
> of it when it's not used (like in full screen, or when a theme is
> installed).
> 
> BUG=593835
> 
> Review-Url: https://codereview.chromium.org/2430493002
> Cr-Commit-Position: refs/heads/master@{#443707}
> Committed:
https://chromium.googlesource.com/chromium/src/+/a5fd3c415f3cc4f8813ba9772d83...

TBR=spqchan@chromium.org,avi@chromium.org,rsesek@chromium.org,sdy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=593835,681772

Review-Url: https://codereview.chromium.org/2638873002
Cr-Commit-Position: refs/heads/master@{#444028}
Committed:
https://chromium.googlesource.com/chromium/src/+/23d8cf2f9da96b2e9e3496738688...
==========

[commit-bot: I haz the power, 2017-01-17 11:39:13]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/23d8cf2f9da96b2e9e3496738688...