The units used to setup XPS should be SkScalars.

[bungeman, 2012-01-04 22:54:49]

The sight of bare doubles, even in GM code, is a blight upon the purity which is
skia.

[epoger, 2012-01-04 23:44:26]

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp
File gm/gmmain.cpp (right):

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp#newcode327
gm/gmmain.cpp:327: static const SkScalar inchesPerMeter =
SkScalarDiv(SkIntToScalar(10000),
I'm not sure I find this to be an improvement--I think it was clearer before. 
Did it yield bad results?  Or is this a style issue?

[reed1, 2012-01-05 13:26:46]

I agree that I don't see any functional improvement. Skia does have the notion
of when it can use floats/doubles at all

#SK_SCALAR_CAN_USE_FLOAT

and so we *could* protect the code with that, but if you're going to use
floats/doubles at all, I think its fine to use them in the clearest way, which
may be the original version of this code.

[bungeman, 2012-01-05 15:26:05]

My reasons for having made this CL in the first place.

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp
File gm/gmmain.cpp (right):

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp#newcode327
gm/gmmain.cpp:327: static const SkScalar inchesPerMeter =
SkScalarDiv(SkIntToScalar(10000),
On 2012/01/04 23:44:27, epoger wrote:
> I'm not sure I find this to be an improvement--I think it was clearer before. 
> Did it yield bad results?  Or is this a style issue?

GM currently has no reference to floats or doubles at all, and I'd hate to have
them in here just for this (purity of the turf and all that). I will admit,
however, that this code is in a "#ifdef SK_SUPPORT_XPS" block, and any platform
which supports xps is going to be ok with floats, at the very least.

However, the more functional reason is that in the end I'm trying to calculate
the SkVectors pixelsPerMeter and unitsPerMeter which will be comprised of
SkScalars. As a result, I figured it would be best to do all of the math in
SkScalars since that is what is wanted in the end.

This version is also a line shorter and the 10000 is visually over the 254 for
the division. And think how good this version would look with operator
overloading and implicit conversions. And ponies.

[reed1, 2012-01-05 15:53:26]

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp
File gm/gmmain.cpp (right):

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp#newcode329
gm/gmmain.cpp:329: static const SkScalar upm = SkScalarMul(SkIntToScalar(72),
inchesPerMeter);
equivalent to

 upm = 72 * inchesPerMeter;

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp#newcode331
gm/gmmain.cpp:331: static const SkScalar ppm = SkScalarMul(SkIntToScalar(200),
inchesPerMeter);
equivalent to

ppm = 200 * inchesPerMeter;

[bungeman, 2012-01-05 15:59:17]

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp
File gm/gmmain.cpp (right):

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp#newcode329
gm/gmmain.cpp:329: static const SkScalar upm = SkScalarMul(SkIntToScalar(72),
inchesPerMeter);
On 2012/01/05 15:53:26, reed1 wrote:
> equivalent to
> 
>  upm = 72 * inchesPerMeter;
> 

Done.

http://codereview.appspot.com/5509050/diff/2001/gm/gmmain.cpp#newcode331
gm/gmmain.cpp:331: static const SkScalar ppm = SkScalarMul(SkIntToScalar(200),
inchesPerMeter);
On 2012/01/05 15:53:26, reed1 wrote:
> equivalent to
> 
> ppm = 200 * inchesPerMeter;

Done.

[epoger, 2012-01-05 16:14:35]

LGTM

I'm fine with either the old way or the new way...

[bungeman, 2012-01-05 16:57:03]

Committed revision 2968.