Switch back to the original brightness filter implementation.

Switch back to the original brightness filter implementation.

As requested by Dirk Schulze, revert Chromium's brightness filter to the old spec-compliant
implementation (RGB multiplier instead of color space translation).

Dirk also updated WK/Safari to use the same brightness matrix.

http://trac.webkit.org/changeset/139770
https://bugs.webkit.org/show_bug.cgi?id=106674


BUG=


Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=181940

[Stephen White, 2013-01-24 15:31:32]

LGTM

[fmalita_google_do_not_use, 2013-01-24 15:34:04]

On 2013/01/24 15:31:32, Stephen White wrote:
> LGTM

Thanks. Looks like this is covered in unit tests, so I'll need to update those
too.

[Stephen White, 2013-01-24 18:17:38]

Ahh, yes.  piman@, could you take a look to see if the tests still cover what
they should?

This will also affect the startup screen on ChromeOS, so those may need to be
tweaked as well to achieve the same effect.

[piman, 2013-01-24 18:32:53]

On 2013/01/24 18:17:38, Stephen White wrote:
> Ahh, yes.  piman@, could you take a look to see if the tests still cover what
> they should?
> 
> This will also affect the startup screen on ChromeOS, so those may need to be
> tweaked as well to achieve the same effect.

Yeah, you'll want to change the implementation in the callers of
ui::Layer::SetLayerBrightness.
In particular, the effect relies on the saturating behavior of the brightness
filter, so if that disappears, what's the alternative?

[Stephen White, 2013-01-24 18:47:14]

On 2013/01/24 18:32:53, piman wrote:
> On 2013/01/24 18:17:38, Stephen White wrote:
> > Ahh, yes.  piman@, could you take a look to see if the tests still cover
what
> > they should?
> > 
> > This will also affect the startup screen on ChromeOS, so those may need to
be
> > tweaked as well to achieve the same effect.
> 
> Yeah, you'll want to change the implementation in the callers of
> ui::Layer::SetLayerBrightness.
> In particular, the effect relies on the saturating behavior of the brightness
> filter, so if that disappears, what's the alternative?

Hmmm.  I don't think there's an equivalent of a translate-brightness in CSS
anymore.  You could use the new SkImageFilter path, and provide a saturating
matrix yourself, but that path may be problematic for ubercompositor (for
reasons piman@ can explain).

We could also leave in some kind of "saturating-brightness" or "translation"
function with the old behaviour for ChromeOS, I suppose.  You'd have to leave it
in the compositor, but without exposing it in WebKit.

[fmalita_google_do_not_use, 2013-01-24 19:21:18]

On 2013/01/24 18:32:53, piman wrote:
> On 2013/01/24 18:17:38, Stephen White wrote:
> > Ahh, yes.  piman@, could you take a look to see if the tests still cover
what
> > they should?
> > 
> > This will also affect the startup screen on ChromeOS, so those may need to
be
> > tweaked as well to achieve the same effect.
> 
> Yeah, you'll want to change the implementation in the callers of
> ui::Layer::SetLayerBrightness.
> In particular, the effect relies on the saturating behavior of the brightness
> filter, so if that disappears, what's the alternative?

My understanding was that the new implementation still saturates, and the only
difference is in the way the parameter is interpreted - multiplier vs. offset.
Is this not the case?

Callers definitely need to be updated though.

[piman, 2013-01-24 21:08:33]

On 2013/01/24 19:21:18, fmalita wrote:
> On 2013/01/24 18:32:53, piman wrote:
> > On 2013/01/24 18:17:38, Stephen White wrote:
> > > Ahh, yes.  piman@, could you take a look to see if the tests still cover
> what
> > > they should?
> > > 
> > > This will also affect the startup screen on ChromeOS, so those may need to
> be
> > > tweaked as well to achieve the same effect.
> > 
> > Yeah, you'll want to change the implementation in the callers of
> > ui::Layer::SetLayerBrightness.
> > In particular, the effect relies on the saturating behavior of the
brightness
> > filter, so if that disappears, what's the alternative?
> 
> My understanding was that the new implementation still saturates, and the only
> difference is in the way the parameter is interpreted - multiplier vs. offset.
> Is this not the case?

The effect will be different. In particular a 0 value will never saturate to
white.

> 
> Callers definitely need to be updated though.

[fmalita_google_do_not_use, 2013-02-10 18:20:07]

Updated to keep the old implementation around for internal users (renamed to
SaturatingBrightness).

The CL depends on https://bugs.webkit.org/show_bug.cgi?id=109380 landing &
getting rolled into CR.

[piman, 2013-02-11 19:42:11]

lgtm

[fmalita_google_do_not_use, 2013-02-11 19:45:43]

On 2013/02/11 19:42:11, piman wrote:
> lgtm

Thanks.

Could you also lgtm https://codereview.chromium.org/12209071/ if you get a
chance? Even thought the EWS bots don't seem to mind, my local build breaks on
the WK change without it (different build flags maybe?) so I'd rather be safe.

[commit-bot: I haz the power, 2013-02-12 13:11:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fmalita@google.com/12033075/15001

[commit-bot: I haz the power, 2013-02-12 14:10:42]

Retried try job too often on mac_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2013-02-12 14:12:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fmalita@google.com/12033075/15001

[commit-bot: I haz the power, 2013-02-12 17:10:42]

Change committed as 181940