Enable 64-bit builds on Windows

Enable 64-bit builds on Windows

Encountered compile errors passing 64-bit size_t to
SkIntToScalar and needed to make adjustments to
gm/gradients.cpp and bench/PicturePlaybackBench.cpp.

Verified on my local Linux, Mac, and Windows machines.

As of this change, the skia_arch_width gyp define
actually forces a 32/64-bit build on Linux, Mac, and
Windows.
Committed: https://code.google.com/p/skia/source/detail?r=5195

[EricB, 2012-08-20 15:43:57]

I'm seeing a lot of truncation warnings due to (32-bit int) x = (64-bit size_t)
y.  This is something we should investigate as we start to take 64-bit builds
more seriously.

[epoger, 2012-08-20 15:51:14]

LGTM

[caryclark1, 2012-08-20 16:01:39]

https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp
File gm/gradients.cpp (right):

https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp#newcode172
gm/gradients.cpp:172: perspective.setPerspY(SkScalarDiv(SkIntToScalar((unsigned)
i+1),
Since fixed point is no longer supported, could this be
   perspective.setPerspY((i + 1) / 500.0f);
(or if need be)
   perspective.setPerspY((unsigned) (i + 1) / 500.0f);
?

[epoger, 2012-08-20 16:11:20]

https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp
File gm/gradients.cpp (right):

https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp#newcode172
gm/gradients.cpp:172: perspective.setPerspY(SkScalarDiv(SkIntToScalar((unsigned)
i+1),
On 2012/08/20 16:01:39, caryclark1 wrote:
> Since fixed point is no longer supported, could this be
>    perspective.setPerspY((i + 1) / 500.0f);
> (or if need be)
>    perspective.setPerspY((unsigned) (i + 1) / 500.0f);
> ?

I suppose that would work, but shouldn't we keep the SkScalar abstraction around
(at least where it already lives) in case we change our representations again in
the future?

[caryclark1, 2012-08-20 17:07:32]

On 2012/08/20 16:11:20, epoger wrote:
> https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp
> File gm/gradients.cpp (right):
> 
> https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp#newcode172
> gm/gradients.cpp:172:
perspective.setPerspY(SkScalarDiv(SkIntToScalar((unsigned)
> i+1),
> On 2012/08/20 16:01:39, caryclark1 wrote:
> > Since fixed point is no longer supported, could this be
> >    perspective.setPerspY((i + 1) / 500.0f);
> > (or if need be)
> >    perspective.setPerspY((unsigned) (i + 1) / 500.0f);
> > ?
> 
> I suppose that would work, but shouldn't we keep the SkScalar abstraction
around
> (at least where it already lives) in case we change our representations again
in
> the future?

While I agree that it would be good to keep the future open, if we don't enforce
disallowing inline muls and divs everywhere, it may not be worth doing it here
-- e.g., trading off readability of code for a future enhancement that may never
be enabled.

In the ancient days, I defined SkScalar as a class when building debug to ensure
that muls and divs were never used accidentally (operator overloading allowed
adds and subs to work, but it was a pain).  I don't know that this sort of
complication would be worth it now.

[EricB, 2012-08-20 18:49:10]

On 2012/08/20 17:07:32, caryclark1 wrote:
> On 2012/08/20 16:11:20, epoger wrote:
> > https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp
> > File gm/gradients.cpp (right):
> > 
> > https://codereview.appspot.com/6460112/diff/1/gm/gradients.cpp#newcode172
> > gm/gradients.cpp:172:
> perspective.setPerspY(SkScalarDiv(SkIntToScalar((unsigned)
> > i+1),
> > On 2012/08/20 16:01:39, caryclark1 wrote:
> > > Since fixed point is no longer supported, could this be
> > >    perspective.setPerspY((i + 1) / 500.0f);
> > > (or if need be)
> > >    perspective.setPerspY((unsigned) (i + 1) / 500.0f);
> > > ?
> > 
> > I suppose that would work, but shouldn't we keep the SkScalar abstraction
> around
> > (at least where it already lives) in case we change our representations
again
> in
> > the future?
> 
> While I agree that it would be good to keep the future open, if we don't
enforce
> disallowing inline muls and divs everywhere, it may not be worth doing it here
> -- e.g., trading off readability of code for a future enhancement that may
never
> be enabled.
> 
> In the ancient days, I defined SkScalar as a class when building debug to
ensure
> that muls and divs were never used accidentally (operator overloading allowed
> adds and subs to work, but it was a pain).  I don't know that this sort of
> complication would be worth it now.

Ping

[epoger, 2012-08-20 18:50:03]

LGTM the way it is

[caryclark1, 2012-08-20 19:25:12]

On 2012/08/20 18:50:03, epoger wrote:
> LGTM the way it is

uncle
lgtm