Fix greenish text rendering on Linux.

[bungeman, 2012-08-22 21:32:28]

One of the (many) complaints at
https://code.google.com/p/chromium/issues/detail?id=141425 is that on Linux the
text looks too green. This is mostly a result of the Chrome UI using #303942 as
the primary text color which is, quite possibly, the worst text color for
SkMaskGamma<2, 2, 2>. Also contributing is the use of a bad LCD filter.

This change uses SkMaskGamma<3, 3, 3>, a default filter of 'LIGHT' (better for
gamma corrected text than the existing 'DEFAULT'), and a sane gaussian style
filter if possible.

[reed1, 2012-08-27 15:30:08]

https://codereview.appspot.com/6484048/diff/6001/src/core/SkMaskGamma.cpp
File src/core/SkMaskGamma.cpp (right):

https://codereview.appspot.com/6484048/diff/6001/src/core/SkMaskGamma.cpp#new...
src/core/SkMaskGamma.cpp:59: //See
https://code.google.com/p/chromium/issues/detail?id=141425#c59 .
I like the bug reference, but can you expand the comment to describe what the
obvious code was (fromLum()) and why we want to change to to toLuma()? Is the
better encapsulated in some local helper function, where there might be more
room to show alternative code paths, and why they were rejected?

https://codereview.appspot.com/6484048/diff/6001/src/core/SkScalerContext.h
File src/core/SkScalerContext.h (right):

https://codereview.appspot.com/6484048/diff/6001/src/core/SkScalerContext.h#n...
src/core/SkScalerContext.h:112: //the Chrome UI) turned out too green.
1. Can/should this be a runtime API instead of compile-time?
2. If compile-time, can we express this in a #define so Chrome can change their
mind in their .gyp file (assuming there is a cost to making these values bigger
i.e. fewer font-cache hits)?

[bungeman, 2012-08-27 15:48:34]

https://codereview.appspot.com/6484048/diff/6001/src/core/SkMaskGamma.cpp
File src/core/SkMaskGamma.cpp (right):

https://codereview.appspot.com/6484048/diff/6001/src/core/SkMaskGamma.cpp#new...
src/core/SkMaskGamma.cpp:59: //See
https://code.google.com/p/chromium/issues/detail?id=141425#c59 .
On 2012/08/27 15:30:08, reed1 wrote:
> I like the bug reference, but can you expand the comment to describe what the
> obvious code was (fromLum()) and why we want to change to to toLuma()? Is the
> better encapsulated in some local helper function, where there might be more
> room to show alternative code paths, and why they were rejected?

This just changes the guess at the dest. Previously the guess was the linear
inverse, this change makes the guess the perceptual inverse. This actually makes
a lot more sense and should have been what was used originally.

https://codereview.appspot.com/6484048/diff/6001/src/core/SkScalerContext.h
File src/core/SkScalerContext.h (right):

https://codereview.appspot.com/6484048/diff/6001/src/core/SkScalerContext.h#n...
src/core/SkScalerContext.h:112: //the Chrome UI) turned out too green.
On 2012/08/27 15:30:08, reed1 wrote:
> 1. Can/should this be a runtime API instead of compile-time?
> 2. If compile-time, can we express this in a #define so Chrome can change
their
> mind in their .gyp file (assuming there is a cost to making these values
bigger
> i.e. fewer font-cache hits)?

I doubt we want this to be runtime. This would actually mean quite a bit of
work, and I'm not sure why one would change it. It could be a define, though 3
really does seem like the right number. In theory someone could want 2 for the
imperceptible speed up if they control the colors used (better font cache use).
On the other hand, if they control the colors used, they can just use a limited
number of colors and get the same font cache hits anyway.

[reed1, 2012-08-27 16:43:39]

lgtm

[bungeman, 2012-08-28 15:26:00]

Committed revision r5280.