Initial skeleton of high-contrast mode.

Initial skeleton of high-contrast mode.

Adds frame settings for high-contrast mode - one to invert colors, one
to convert to grayscale, and one to adjust contrast. Eventually these
will be controlled by the browser and remembered on a per-site basis,
like zoom.

High-contrast mode is implemented as a color filter in
GraphicsContext.  Most primitive drawing operations like rects and
lines can be filtered simply by applying the color filter to the
provided color, so the performance impact is minimal. Follow-up
changes will address trickier cases like images, gradients, layers,
theme drawing, and more, plus heuristics to optionally avoid inverting
some images (such as photos or video).

For testing, introduces a virtual test suite that runs tests with
high contrast mode enabled. This patch just introduces one test, but
follow-up changes will run a subset of existing LayoutTests to ensure
broad coverage. I also intend to add an additional image_diff switch
to enable comparing inverted images with uninverted expectations, to
help quickly identify failing pixel tests without manually inspecting
output.

BUG=685242
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2878573003
Cr-Commit-Position: refs/heads/master@{#478362}
Committed: https://chromium.googlesource.com/chromium/src/+/36fd0123a492075ae8d6c12675ecfd58de596cfd

[dmazzoni, 2017-05-11 16:52:41]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-11 16:53:28]

Dry run: CQ is trying da patch.

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

[dmazzoni, 2017-05-11 18:10:42]

dmazzoni@chromium.org changed reviewers:
+ chrishtr@chromium.org, schenney@chromium.org

[dmazzoni, 2017-05-11 18:10:42]

Ready for review, PTAL when you have a chance.

As previously discussed, applying the color
filter directly in GraphicsContext has a
negligible performance impact when disabled
and it doesn't hurt code readability much.

I've got a solution for most of the trickier
cases like layers, theme painting, etc. - but
I'd like to start with the basic skeleton here
and then tackle the harder cases in follow-ups
one at a time with tests.

Thanks!

[commit-bot: I haz the power, 2017-05-11 19:05:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-11 19:05:52]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[chrishtr, 2017-06-01 04:10:51]

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp (right):

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:145: void
GraphicsContext::SetHighContrast(const HighContrastSettings& settings) {
PaintRecordBuilder, and a couple of other cases, create GraphicsContexts
from parent GraphicsContexts. you'll need to copy this setting across to
child GraphicsContexts. See the callsites to SetPrinting for examples.

Also, I think you can make HighContrastSettings a constructor parameter to
GraphicsContext.

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:169: default:
I don't think you need this, since there are labels for all four
values of settings.mode.

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp (right):

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp:278:
HighContrastSettings* high_contrast,
high_contrast_settings

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp:325:
client_->PaintContents(this, context, painting_phase_, *interest_rect);
Instead of passing the high_contrast object through to client_, set it
there (in PaintLayerPainter perhaps). This avoids the need to pass this
auxiliary parameter to GrpahicsLayer, which conceptually should not
need it.

[dmazzoni, 2017-06-01 21:43:45]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[dmazzoni, 2017-06-01 21:44:02]

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp (right):

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:145: void
GraphicsContext::SetHighContrast(const HighContrastSettings& settings) {
On 2017/06/01 04:10:51, chrishtr wrote:
> PaintRecordBuilder, and a couple of other cases, create GraphicsContexts
> from parent GraphicsContexts. you'll need to copy this setting across to
> child GraphicsContexts. See the callsites to SetPrinting for examples.
> 
> Also, I think you can make HighContrastSettings a constructor parameter to
> GraphicsContext.

OK, I made it an optional constructor parameter and fixed the case
where it's copying from a containing context in PaintRecordBuilder.
I couldn't find another case where it was clear that we should
copy the settings. Let me know if you see one, otherwise it might
become apparent as I try to run more layout tests.

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:169: default:
On 2017/06/01 04:10:51, chrishtr wrote:
> I don't think you need this, since there are labels for all four
> values of settings.mode.

Done.

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp (right):

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp:278:
HighContrastSettings* high_contrast,
On 2017/06/01 04:10:51, chrishtr wrote:
> high_contrast_settings

Moot since I'm not passing anything to GraphicsLayer anymore.

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp:325:
client_->PaintContents(this, context, painting_phase_, *interest_rect);
On 2017/06/01 04:10:51, chrishtr wrote:
> Instead of passing the high_contrast object through to client_, set it
> there (in PaintLayerPainter perhaps). This avoids the need to pass this
> auxiliary parameter to GrpahicsLayer, which conceptually should not
> need it.

Sure, done. That seems to work just as well.

Conceptually is it fine that PaintLayerPainter::Paint()
essentially changes the state of the GraphicsContext
and leaves it that way? Is there any reason it should
reset the high contrast mode when done painting or is it
expected that it modifies the GraphicsContext as
necessary?

Along those lines, should the high contrast mode be
part of the state that's controlled by Save/Restore?
Right now I'm thinking that it's more of a global
flag and not really part of the state, but I'm just
checking if you see any potential problem with that.

[commit-bot: I haz the power, 2017-06-01 21:44:36]

Dry run: 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-06-01 21:47:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-01 21:47:58]

Dry run: Try jobs failed on following builders:
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[chrishtr, 2017-06-02 21:12:30]

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp (right):

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:145: void
GraphicsContext::SetHighContrast(const HighContrastSettings& settings) {
On 2017/06/01 at 21:44:01, dmazzoni wrote:
> On 2017/06/01 04:10:51, chrishtr wrote:
> > PaintRecordBuilder, and a couple of other cases, create GraphicsContexts
> > from parent GraphicsContexts. you'll need to copy this setting across to
> > child GraphicsContexts. See the callsites to SetPrinting for examples.
> > 
> > Also, I think you can make HighContrastSettings a constructor parameter to
> > GraphicsContext.
> 
> OK, I made it an optional constructor parameter and fixed the case
> where it's copying from a containing context in PaintRecordBuilder.
> I couldn't find another case where it was clear that we should
> copy the settings. Let me know if you see one, otherwise it might
> become apparent as I try to run more layout tests.

Do you care about anything except the mainline case of drawing to the screen?
e.g. drag images, and a few other exotic cases.

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp (right):

https://codereview.chromium.org/2878573003/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp:325:
client_->PaintContents(this, context, painting_phase_, *interest_rect);
On 2017/06/01 at 21:44:01, dmazzoni wrote:
> On 2017/06/01 04:10:51, chrishtr wrote:
> > Instead of passing the high_contrast object through to client_, set it
> > there (in PaintLayerPainter perhaps). This avoids the need to pass this
> > auxiliary parameter to GrpahicsLayer, which conceptually should not
> > need it.
> 
> Sure, done. That seems to work just as well.
> 
> Conceptually is it fine that PaintLayerPainter::Paint()
> essentially changes the state of the GraphicsContext
> and leaves it that way? Is there any reason it should
> reset the high contrast mode when done painting or is it
> expected that it modifies the GraphicsContext as
> necessary?
> 
> Along those lines, should the high contrast mode be
> part of the state that's controlled by Save/Restore?
> Right now I'm thinking that it's more of a global
> flag and not really part of the state, but I'm just
> checking if you see any potential problem with that.


Good point. For this reason, please move the application of the
HighContrastSettings struct
into CompositedLayerMapping::doPaintTask.

https://codereview.chromium.org/2878573003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp (right):

https://codereview.chromium.org/2878573003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:1303: void
GraphicsContext::UpdateHighContrastFilterFromSettings() {
Please unittest these.

[dmazzoni, 2017-06-05 07:15:36]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 07:15:54]

Dry run: 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-06-05 08:33:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-05 08:33:43]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[dmazzoni, 2017-06-05 15:53:48]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 15:54:07]

Dry run: CQ is trying da patch.

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

[dmazzoni, 2017-06-05 15:55:37]

On 2017/06/02 21:12:30, chrishtr wrote:
> Do you care about anything except the mainline case of drawing to the screen?
> e.g. drag images, and a few other exotic cases.

Good question. Not sure about drag images - if dragging outside of the browser,
unfiltered might be more accurate.

Either way, not in this patch. Would printing, drag images, and any other exotic
cases be covered by pixel tests? Or only by other tests?

> Good point. For this reason, please move the application of the
> HighContrastSettings struct
> into CompositedLayerMapping::doPaintTask.

Done.

[dmazzoni, 2017-06-05 15:56:37]

Ready for a look. Also I'll be in SF today if it'd help to
chat in person.

https://codereview.chromium.org/2878573003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp (right):

https://codereview.chromium.org/2878573003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp:1303: void
GraphicsContext::UpdateHighContrastFilterFromSettings() {
On 2017/06/02 21:12:30, chrishtr wrote:
> Please unittest these.

Done. I didn't see many examples of calling private methods from unit tests,
so I tested it by applying the filter to 1x1 pixel rectangles drawn to a canvas
and then testing the resulting canvas pixels, similar to existing
GraphicsContext
unit tests. Let me know if you think something a little more low-level would be
better, maybe by making the test a friend.

[commit-bot: I haz the power, 2017-06-05 16:26:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-05 16:26:28]

Dry run: Try jobs failed on following builders:
  linux_chromium_headless_rel on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[chrishtr, 2017-06-05 16:35:19]

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:3109:
GetLayoutObject().GetFrame()->GetSettings());
Can GetSettings ever return nullptr? If not then pass a const & and avoid
null-checks in InitHighContrastSettingsFromSettings.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/GraphicsContext.h (right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/GraphicsContext.h:74: const
HighContrastSettings* = nullptr,
Hmm. It seems that the constructor is not used at all after all most
of the time. Seems better to remove this and just have the setter.
Sorry for the churn, I was thinking it would be possible to 
have the high-contrast settings available at time of creation,
but since the creation is in platform/, that is not possible.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/GraphicsContextTest.cpp
(right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/GraphicsContextTest.cpp:161:
context.FillRect(FloatRect(0, 0, 1, 1), black);
It would be clearer to put each mode you're testing here into its
own TEST() macro.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/HighContrast.h (right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/HighContrast.h:6: #define
HighContrast_h
Rename this file HighContrastSettings to match the name of the struct.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/HighContrast.h:20: HighContrastMode
mode;
Initialize these to the defaults.

[dmazzoni, 2017-06-06 05:23:15]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[dmazzoni, 2017-06-06 05:23:25]

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
(right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp:3109:
GetLayoutObject().GetFrame()->GetSettings());
On 2017/06/05 16:35:18, chrishtr wrote:
> Can GetSettings ever return nullptr? If not then pass a const & and avoid
> null-checks in InitHighContrastSettingsFromSettings.

Looks like there's no way it can return nullptr, so I just got rid of the helper
and initialized it here. Seems simpler that way since it's only 3 lines of code.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/GraphicsContext.h (right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/GraphicsContext.h:74: const
HighContrastSettings* = nullptr,
On 2017/06/05 16:35:18, chrishtr wrote:
> Hmm. It seems that the constructor is not used at all after all most
> of the time. Seems better to remove this and just have the setter.
> Sorry for the churn, I was thinking it would be possible to 
> have the high-contrast settings available at time of creation,
> but since the creation is in platform/, that is not possible.

Done.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/GraphicsContextTest.cpp
(right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/GraphicsContextTest.cpp:161:
context.FillRect(FloatRect(0, 0, 1, 1), black);
On 2017/06/05 16:35:18, chrishtr wrote:
> It would be clearer to put each mode you're testing here into its
> own TEST() macro.

Done.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/HighContrast.h (right):

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/HighContrast.h:6: #define
HighContrast_h
On 2017/06/05 16:35:19, chrishtr wrote:
> Rename this file HighContrastSettings to match the name of the struct.

Done.

https://codereview.chromium.org/2878573003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/HighContrast.h:20: HighContrastMode
mode;
On 2017/06/05 16:35:18, chrishtr wrote:
> Initialize these to the defaults.

Done.

[commit-bot: I haz the power, 2017-06-06 05:23:34]

Dry run: 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-06-06 05:51:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-06 05:51:02]

Dry run: Try jobs failed on following builders:
  linux_chromium_headless_rel on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[chrishtr, 2017-06-06 15:08:09]

lgtm

[dmazzoni, 2017-06-06 15:15:59]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-06 15:16:23]

Dry run: 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-06-06 16:39:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-06 16:39:35]

Dry run: Try jobs failed on following builders:
  linux_layout_tests_slimming_paint_v2 on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_layout_te...)

[dmazzoni, 2017-06-07 18:24:53]

> > Conceptually is it fine that PaintLayerPainter::Paint()
> > essentially changes the state of the GraphicsContext
> > and leaves it that way? Is there any reason it should
> > reset the high contrast mode when done painting or is it
> > expected that it modifies the GraphicsContext as
> > necessary?
> 
> Good point. For this reason, please move the application of the
> HighContrastSettings struct
> into CompositedLayerMapping::doPaintTask.

One wrinkle - now it doesn't work with --enable-slimming-paint-v2,
because CompositedLayerMapping::doPaintTask is never called.
I'm seeing these call stacks.

Without slimming paint v2:

PaintLayerPainter::PaintLayerContents()
CompositedLayerMapping::DoPaintTask()
CompositedLayerMapping::PaintContents()
GraphicsLayer::PaintWithoutCommit()
GraphicsLayer::Paint()
LocalFrameView::PaintGraphicsLayerRecursively()

With slimming paint v2:

PaintLayerPainter::PaintLayerContents()
PaintLayerPainter::PaintLayerContentsCompositingAllPhases()
PaintLayerPainter::Paint()
PaintLayerPainter::Paint()
FramePainter::PaintContents()
FramePainter::Paint()
LocalFrameView::Paint()

Should I move the high contrast code back to PaintLayerPainter,
or keep it in CompositedLayerMapping::doPaintTask and add similar
code somewhere in the slimming paint v2 stack?

[chrishtr, 2017-06-07 23:57:56]

On 2017/06/07 at 18:24:53, dmazzoni wrote:
> > > Conceptually is it fine that PaintLayerPainter::Paint()
> > > essentially changes the state of the GraphicsContext
> > > and leaves it that way? Is there any reason it should
> > > reset the high contrast mode when done painting or is it
> > > expected that it modifies the GraphicsContext as
> > > necessary?
> > 
> > Good point. For this reason, please move the application of the
> > HighContrastSettings struct
> > into CompositedLayerMapping::doPaintTask.
> 
> One wrinkle - now it doesn't work with --enable-slimming-paint-v2,
> because CompositedLayerMapping::doPaintTask is never called.
> I'm seeing these call stacks.
> 
> Without slimming paint v2:
> 
> PaintLayerPainter::PaintLayerContents()
> CompositedLayerMapping::DoPaintTask()
> CompositedLayerMapping::PaintContents()
> GraphicsLayer::PaintWithoutCommit()
> GraphicsLayer::Paint()
> LocalFrameView::PaintGraphicsLayerRecursively()
> 
> With slimming paint v2:
> 
> PaintLayerPainter::PaintLayerContents()
> PaintLayerPainter::PaintLayerContentsCompositingAllPhases()
> PaintLayerPainter::Paint()
> PaintLayerPainter::Paint()
> FramePainter::PaintContents()
> FramePainter::Paint()
> LocalFrameView::Paint()
> 
> Should I move the high contrast code back to PaintLayerPainter,
> or keep it in CompositedLayerMapping::doPaintTask and add similar
> code somewhere in the slimming paint v2 stack?

I think you should add SPv2 code elsewhere. Here seems good:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/Loc...

[dmazzoni, 2017-06-08 18:26:34]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-08 18:27:18]

Dry run: 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-06-08 19:42:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-08 19:42:59]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[dmazzoni, 2017-06-08 21:15:15]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2017-06-08 21:15:16]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/2878573003/#ps130001
(title: "Fix for slimming paint v2")

[commit-bot: I haz the power, 2017-06-08 21:15:41]

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-06-08 22:49:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-08 22:49:20]

Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[dmazzoni, 2017-06-09 17:13:45]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2017-06-09 17:13:45]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/2878573003/#ps150001
(title: "Rebase")

[commit-bot: I haz the power, 2017-06-09 17:14:03]

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-06-09 19:13:10]

CQ is committing da patch.

Bot data: {"patchset_id": 150001, "attempt_start_ts": 1497028425554190,
"parent_rev": "c95155fce139aa9bd5eee85967fdb7f3ad877f74", "commit_rev":
"36fd0123a492075ae8d6c12675ecfd58de596cfd"}

[commit-bot: I haz the power, 2017-06-09 19:13:25]

Description was changed from

==========
Initial skeleton of high-contrast mode.

Adds frame settings for high-contrast mode - one to invert colors, one
to convert to grayscale, and one to adjust contrast. Eventually these
will be controlled by the browser and remembered on a per-site basis,
like zoom.

High-contrast mode is implemented as a color filter in
GraphicsContext.  Most primitive drawing operations like rects and
lines can be filtered simply by applying the color filter to the
provided color, so the performance impact is minimal. Follow-up
changes will address trickier cases like images, gradients, layers,
theme drawing, and more, plus heuristics to optionally avoid inverting
some images (such as photos or video).

For testing, introduces a virtual test suite that runs tests with
high contrast mode enabled. This patch just introduces one test, but
follow-up changes will run a subset of existing LayoutTests to ensure
broad coverage. I also intend to add an additional image_diff switch
to enable comparing inverted images with uninverted expectations, to
help quickly identify failing pixel tests without manually inspecting
output.

BUG=685242
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
==========

to

==========
Initial skeleton of high-contrast mode.

Adds frame settings for high-contrast mode - one to invert colors, one
to convert to grayscale, and one to adjust contrast. Eventually these
will be controlled by the browser and remembered on a per-site basis,
like zoom.

High-contrast mode is implemented as a color filter in
GraphicsContext.  Most primitive drawing operations like rects and
lines can be filtered simply by applying the color filter to the
provided color, so the performance impact is minimal. Follow-up
changes will address trickier cases like images, gradients, layers,
theme drawing, and more, plus heuristics to optionally avoid inverting
some images (such as photos or video).

For testing, introduces a virtual test suite that runs tests with
high contrast mode enabled. This patch just introduces one test, but
follow-up changes will run a subset of existing LayoutTests to ensure
broad coverage. I also intend to add an additional image_diff switch
to enable comparing inverted images with uninverted expectations, to
help quickly identify failing pixel tests without manually inspecting
output.

BUG=685242
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2878573003
Cr-Commit-Position: refs/heads/master@{#478362}
Committed:
https://chromium.googlesource.com/chromium/src/+/36fd0123a492075ae8d6c12675ec...
==========

[commit-bot: I haz the power, 2017-06-09 19:13:27]

Committed patchset #9 (id:150001) as
https://chromium.googlesource.com/chromium/src/+/36fd0123a492075ae8d6c12675ec...