[merge-m52] Do not SchedulePaint() inside views::Label::OnPaint()

[merge-m52] Do not SchedulePaint() inside views::Label::OnPaint()

View::SchedulePaint() shouldn't be called inside an OnPaint() method. At
best it wastes computation doing a follow-up, redundant paint. On Mac
it's causing a weird interaction with transparent backgrounds for
strings of particular lengths on retina screens.

For performance, MaybeBuildRenderTextLines() is always deferred until a
Paint. It calls RecalculateColors() to apply colors to the lines it
newly creates, and that schedules a paint. But
MaybeBuildRenderTextLines() just needs to apply the colors that have
already been calculated.

So, to fix, split RecalculateColors() into the color calculation and
ApplyTextColors(), which can be called from OnPaint().

BUG=604092
TEST=On a retina-screen Mac with a fresh profile, navigate (e.g. to
chrome://version), then press Backspace, The "Press <key> to go back"
popup should appear and it should have a consistent, transparent
background.

Review-Url: https://codereview.chromium.org/2065003002
Cr-Commit-Position: refs/heads/master@{#400273}
(cherry picked from commit 2b40c5ca82b21f503cc7cc75ac101f1d2b710fc1)

Committed: https://chromium.googlesource.com/chromium/src/+/1812ed000f950a01a19e12f0bc3dfdc5b1642724

[tapted, 2016-06-21 11:59:29]

Description was changed from

==========
[merge-m52] Do not SchedulePaint() inside views::Label::OnPaint()

View::SchedulePaint() shouldn't be called inside an OnPaint() method. At
best it wastes computation doing a follow-up, redundant paint. On Mac
it's causing a weird interaction with transparent backgrounds for
strings of particular lengths on retina screens.

For performance, MaybeBuildRenderTextLines() is always deferred until a
Paint. It calls RecalculateColors() to apply colors to the lines it
newly creates, and that schedules a paint. But
MaybeBuildRenderTextLines() just needs to apply the colors that have
already been calculated.

So, to fix, split RecalculateColors() into the color calculation and
ApplyTextColors(), which can be called from OnPaint().

BUG=604092
TEST=On a retina-screen Mac with a fresh profile, navigate (e.g. to
chrome://version), then press Backspace, The "Press <key> to go back"
popup should appear and it should have a consistent, transparent
background.

Review-Url: https://codereview.chromium.org/2065003002
Cr-Commit-Position: refs/heads/master@{#400273}
(cherry picked from commit 2b40c5ca82b21f503cc7cc75ac101f1d2b710fc1)
==========

to

==========
[merge-m52] Do not SchedulePaint() inside views::Label::OnPaint()

View::SchedulePaint() shouldn't be called inside an OnPaint() method. At
best it wastes computation doing a follow-up, redundant paint. On Mac
it's causing a weird interaction with transparent backgrounds for
strings of particular lengths on retina screens.

For performance, MaybeBuildRenderTextLines() is always deferred until a
Paint. It calls RecalculateColors() to apply colors to the lines it
newly creates, and that schedules a paint. But
MaybeBuildRenderTextLines() just needs to apply the colors that have
already been calculated.

So, to fix, split RecalculateColors() into the color calculation and
ApplyTextColors(), which can be called from OnPaint().

BUG=604092
TEST=On a retina-screen Mac with a fresh profile, navigate (e.g. to
chrome://version), then press Backspace, The "Press <key> to go back"
popup should appear and it should have a consistent, transparent
background.

Review-Url: https://codereview.chromium.org/2065003002
Cr-Commit-Position: refs/heads/master@{#400273}
(cherry picked from commit 2b40c5ca82b21f503cc7cc75ac101f1d2b710fc1)

Committed:
https://chromium.googlesource.com/chromium/src/+/1812ed000f950a01a19e12f0bc3d...
==========

[tapted, 2016-06-21 11:59:33]

Committed patchset #1 (id:1) manually as
1812ed000f950a01a19e12f0bc3dfdc5b1642724.