Improve gpu path subdiv with perspective, remove tolerance scale, fix comment

[bsalomon, 2011-09-07 15:39:32]

Tom and I convinced ourselves that it isn't correct to scale the tolerance when
using OSSAA so I removed the code.

The change to the tolerance computation makes perspective curve subdivision less
bad if the origin falls somewhere near the bounds of device coords.

I won't check in the change to SampleHairCurves.cpp.

http://codereview.appspot.com/4993041/diff/1/gpu/src/GrPathRenderer.h
File gpu/src/GrPathRenderer.h (left):

http://codereview.appspot.com/4993041/diff/1/gpu/src/GrPathRenderer.h#oldcode39
gpu/src/GrPathRenderer.h:39: * implementation to install your own. The most
recently added is the
This comment was just wrong.

[bsalomon, 2011-09-07 17:56:46]

hello

[reed1, 2011-09-07 18:01:34]

http://codereview.appspot.com/4993041/diff/6001/src/core/SkMatrix.cpp
File src/core/SkMatrix.cpp (right):

http://codereview.appspot.com/4993041/diff/6001/src/core/SkMatrix.cpp#newcode...
src/core/SkMatrix.cpp:1717: stretch = SkFixedDiv(stretch,
SkFractToFixed(fMat[kMPersp2]));
SkFractDiv is better, as it won't throw away bits from the denominator

[bsalomon, 2011-09-07 18:20:30]

http://codereview.appspot.com/4993041/diff/6001/src/core/SkMatrix.cpp
File src/core/SkMatrix.cpp (right):

http://codereview.appspot.com/4993041/diff/6001/src/core/SkMatrix.cpp#newcode...
src/core/SkMatrix.cpp:1717: stretch = SkFixedDiv(stretch,
SkFractToFixed(fMat[kMPersp2]));
On 2011/09/07 18:01:34, reed1 wrote:
> SkFractDiv is better, as it won't throw away bits from the denominator

Done.

[reed1, 2011-09-07 18:20:56]

LGTM

[TomH, 2011-09-07 18:31:24]

LGTM. Curiosity compels questions:

http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrDefaultPathRenderer...
File gpu/src/GrDefaultPathRenderer.cpp (right):

http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrDefaultPathRenderer...
gpu/src/GrDefaultPathRenderer.cpp:378: tol =
GrPathUtils::scaleToleranceToSrc(tol, viewM);
Yay.

http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrPathUtils.cpp
File gpu/src/GrPathUtils.cpp (right):

http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrPathUtils.cpp#newco...
gpu/src/GrPathUtils.cpp:23: srcTol /= 5;
Changed from /10 to /5 - is this arbitrary?

http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrPathUtils.h
File gpu/src/GrPathUtils.h (right):

http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrPathUtils.h#newcode21
gpu/src/GrPathUtils.h:21: namespace GrPathUtils {
Why desingletonize?

[bsalomon, 2011-09-07 18:39:23]

On 2011/09/07 18:31:24, TomH wrote:
>
http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrPathUtils.cpp#newco...
> gpu/src/GrPathUtils.cpp:23: srcTol /= 5;
> Changed from /10 to /5 - is this arbitrary?
Very :) We'd really have to consider the path bounds projected into dst space
and compute the largest zoom factor in that domain.

>
http://codereview.appspot.com/4993041/diff/6001/gpu/src/GrPathUtils.h#newcode21
> gpu/src/GrPathUtils.h:21: namespace GrPathUtils {
> Why desingletonize?
Just converted from class-being-used-as-a-namespace to an actual namespace.