Put geometry on device, allow device to request linear masks.

Put geometry on device, allow device to request linear masks.

[bungeman, 2012-09-12 19:11:08]

The initial Patch Set 1 is a first stab at seeing what needs to change on device
for the device to own its own properties (gamma, geometry) and for a device to
be able to request linear masks.

[bungeman, 2012-09-14 21:58:05]

So this still needs quite a bit of work, but I think the general idea is there.
The GPU gamma correction matches the software side, but isn't doing sRGB or
optimizing linear yet. The shader certainly needs some optimization. If there is
anything evil in here, let me know while I'm cleaning this up.

[reed1, 2012-09-15 02:06:57]

https://codereview.appspot.com/6499101/diff/3001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.appspot.com/6499101/diff/3001/include/core/SkDevice.h#newc...
include/core/SkDevice.h:27: class SkGpuRenderTarget;
If we're gonna have optional stuff, can we roll it all into a single struct
(which can be null)? Similar to SkImage::Info in SkImage.h?

https://codereview.appspot.com/6499101/diff/3001/include/core/SkPixelGeometry.h
File include/core/SkPixelGeometry.h (right):

https://codereview.appspot.com/6499101/diff/3001/include/core/SkPixelGeometry...
include/core/SkPixelGeometry.h:3: 
Are there layouts here that we don't know how to support? I'm not a fan of
future-defining enums...

[bungeman, 2012-10-30 20:10:23]

The changes for requesting linear masks and having the gpu do the work have
moved to https://codereview.appspot.com/6818058/ . This change is now more
focused, smaller, and easier to review. I imagine that the points most up for
debate are (1) how to specify the geometry and gamma to the device and (2) how
to pass this information through to the creation of the SkScalarContext. I will
be taking a look at various alternatives which have already been suggested.

[bungeman, 2012-12-04 18:29:43]

There was a desire expressed for an 'SkDeviceInfo' object to be passed through
the layers instead of passing pixel geometries and gamma separately. The trouble
is that SkDevice is more or less already it's own 'info' object. As a result,
the easiest way to do this is to simply pass an SkDevice pointer through the
stack. When SkSurface replaces SkDevice as the primary means of specifying a
destination, an SkImage::Info (with the gamma and pixel geometry added to it)
can be used instead.

[reed1, 2012-12-07 21:06:34]

can we do some nitty cleanup in Sk[Sub]PixelGeometry.h

enums {};

fields;

Possibly reorder enum values to separate known/unknown and value bits?

typedef uint32_t SkSubPixelFormat;

enum SkSubPixelOrientation {
    kUnknown_SkSubPixelOrientation      = 0x0,
    kKnown_SkSubPixelOrientation        = 0x2,

    kHorizontal_SkSubPixelOrientation   = 0x2,
    kVertical_SkSubPixelOrientation     = 0x3,
};

enum SkSubPixelLayout {
    kUnknown_SkSubPixelLayout   = 0x0,
    kKnown_SkSubPixelLayout     = 0x8,

    kRGB_SkSubPixelLayout       = 0x8,
    kBGR_SkSubPixelLayout       = 0x6,
};

Not sure this would be better, just a thought.

https://codereview.appspot.com/6499101/diff/46001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.appspot.com/6499101/diff/46001/include/core/SkDevice.h#new...
include/core/SkDevice.h:46: */
Lets keep device(bitmap) and add a new one with zero default arguments.

[reed1, 2012-12-07 21:07:46]

Not sure we should introduce device.h to scalercontext.h. Perhaps there we pass
2 parameters (geo + gamma). I'm fine with device param to autoglyphcache etc.

[bungeman, 2012-12-10 21:44:47]

A lot of this is naming, and I'm not sure exactly what the names should be. Here
is another way to organize this.

https://codereview.appspot.com/6499101/diff/46001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.appspot.com/6499101/diff/46001/include/core/SkDevice.h#new...
include/core/SkDevice.h:46: */
On 2012/12/07 21:06:35, reed1 wrote:
> Lets keep device(bitmap) and add a new one with zero default arguments.

Done.

[reed1, 2012-12-11 22:02:29]

SkPixelProperties instead of Image? Matches SkPixelGeometry and doesn't intrude
on my sacred SkImage* domain.

Any chance we could merge Those into a single header?

https://codereview.appspot.com/6499101/diff/53001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.appspot.com/6499101/diff/53001/include/core/SkDevice.h#new...
include/core/SkDevice.h:96: /** Return the image properties of the device. */
const & instead of copy?

[bungeman, 2013-01-18 16:58:44]

This (Patch set 15) kind of throws being more generic out the window and makes
things rather device specific.

https://codereview.appspot.com/6499101/diff/53001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.appspot.com/6499101/diff/53001/include/core/SkDevice.h#new...
include/core/SkDevice.h:96: /** Return the image properties of the device. */
On 2012/12/11 22:02:30, reed1 wrote:
> const & instead of copy?

Done.

[reed1, 2013-01-22 17:39:40]

I like the name (DeviceProperties)

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDevice.h#new...
include/core/SkDevice.h:60: SkDevice(SkBitmap::Config config, int width, int
height, bool isOpaque = false,
Death to too many default parameters!

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDevice.h#new...
include/core/SkDevice.h:434: /** Parameters the device should be applying which
are leaking out for performance reasons. */
// What is meant by leaky?

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDeviceProper...
File include/core/SkDeviceProperties.h (right):

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDeviceProper...
include/core/SkDeviceProperties.h:88: 
If we commonly use the defaults, lets have a separate MakeDefault() so the
caller can see that that is what is happening.

foo = SkDeviceProperties::Make()

That line isn't very clear what is going on (to me at least). MakeDefault() or
MakeOffscreen() or MakeLinear()?

[bungeman, 2013-01-22 18:48:14]

Reduced default parameters, clarified leaky, and MadeDefault().

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDevice.h#new...
include/core/SkDevice.h:60: SkDevice(SkBitmap::Config config, int width, int
height, bool isOpaque = false,
On 2013/01/22 17:39:41, reed1 wrote:
> Death to too many default parameters!

Copy-pasta'ed instead!

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDevice.h#new...
include/core/SkDevice.h:434: /** Parameters the device should be applying which
are leaking out for performance reasons. */
On 2013/01/22 17:39:41, reed1 wrote:
> // What is meant by leaky?

I've updated the comment to be a bit more clear. Leaky properties are those
settings on device which in an ideal world the device would take care of itself.
For example, in an ideal world knowing the subpixel geometry is horizontal rgb
means everything would be drawn from outlines and the device would subpixel
render and smooth everything drawn to it and have three channel alpha. This
means none of the properties would be leaky and this field would contain the
identity values of 'unknown' for geometry and '1.0' for gamma. In our non-ideal
world, there are properties which leak out of the device and SkDraw tries to
apply them instead when it can.

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDeviceProper...
File include/core/SkDeviceProperties.h (right):

https://codereview.appspot.com/6499101/diff/65001/include/core/SkDeviceProper...
include/core/SkDeviceProperties.h:88: 
On 2013/01/22 17:39:41, reed1 wrote:
> If we commonly use the defaults, lets have a separate MakeDefault() so the
> caller can see that that is what is happening.
> 
> foo = SkDeviceProperties::Make()
> 
> That line isn't very clear what is going on (to me at least). MakeDefault() or
> MakeOffscreen() or MakeLinear()?

Done.

[reed1, 2013-01-22 18:51:40]

lgtm

[bungeman, 2013-01-22 20:27:38]

Committed revision 7317.

Fixes for VC++ and Android in revisions 7319 and 7322.