Fix assert in GPU path rendering found by fuzzer.

Fix assert in GPU path rendering found by fuzzer.

Without this check, running the fuzzer in GPU mode asserts with:

../../include/gpu/GrTypes.h:115: failed assertion "n >= 0"

R=bsalomon@google.com

[Stephen White, 2015-02-24 17:59:40]

Brian: PTAL. Thanks!

[bsalomon, 2015-02-24 18:20:58]

bsalomon@google.com changed reviewers:
+ egdaniel@google.com

[bsalomon, 2015-02-24 18:20:58]

Greg, is this related to the bug you're looking at?

[egdaniel, 2015-02-24 18:26:07]

yeah this is the same issue. The only real difference between this solution and
mine, is I have at return max_points_per_curve where as this solution returns 1.
What do you guys think should be the ideal return value in this case?

[bsalomon, 2015-02-24 18:51:36]

On 2015/02/24 18:26:07, egdaniel wrote:
> yeah this is the same issue. The only real difference between this solution
and
> mine, is I have at return max_points_per_curve where as this solution returns
1.
> What do you guys think should be the ideal return value in this case?

returning the max seems more appropriate to me.

[Stephen White, 2015-02-24 18:51:36]

On 2015/02/24 18:26:07, egdaniel wrote:
> yeah this is the same issue. The only real difference between this solution
and
> mine, is I have at return max_points_per_curve where as this solution returns
1.
> What do you guys think should be the ideal return value in this case?

This was turned up by the fuzzer, so I'm not sure what the correct answer is (no
visual result).

Do we care what we draw if the points are infinitely far apart?

[egdaniel, 2015-02-24 19:00:04]

The bug that popped up for me was drawing a conic circle that was radius on the
order of 10^11 I think. So realistically even if some of the circle made it into
the view we really wouldn't see anything but a straight edge. However if we just
use 1 here we would end up just seeing an inscribed diamond (i think) so we
would see edges drastically far off from where they should be on circle. Yet, it
is a lot slower drawing so many points. I defer to Brian for final decision, but
I would lean ever so slightly to max_points

[Stephen White, 2015-02-24 19:01:40]

On 2015/02/24 19:00:04, egdaniel wrote:
> The bug that popped up for me was drawing a conic circle that was radius on
the
> order of 10^11 I think. So realistically even if some of the circle made it
into
> the view we really wouldn't see anything but a straight edge. However if we
just
> use 1 here we would end up just seeing an inscribed diamond (i think) so we
> would see edges drastically far off from where they should be on circle. Yet,
it
> is a lot slower drawing so many points. I defer to Brian for final decision,
but
> I would lean ever so slightly to max_points

Done.

[bsalomon, 2015-02-24 19:18:14]

On 2015/02/24 19:01:40, Stephen White wrote:
> On 2015/02/24 19:00:04, egdaniel wrote:
> > The bug that popped up for me was drawing a conic circle that was radius on
> the
> > order of 10^11 I think. So realistically even if some of the circle made it
> into
> > the view we really wouldn't see anything but a straight edge. However if we
> just
> > use 1 here we would end up just seeing an inscribed diamond (i think) so we
> > would see edges drastically far off from where they should be on circle.
Yet,
> it
> > is a lot slower drawing so many points. I defer to Brian for final decision,
> but
> > I would lean ever so slightly to max_points
> 
> Done.

Greg, I thought your fix also dealt with cases where SkScalarCeilToInt() would
overflow. Should we land that fix instead?

[egdaniel, 2015-02-24 19:29:24]

Ah yes forgot about that. Yeah it checked that the value we call CeilToInt on is
less than max int. We can land mine instead (also improves the DistanceToLine
function to reduce chance of getting inf in first place).

[Stephen White, 2015-02-24 19:30:01]

On 2015/02/24 19:29:24, egdaniel wrote:
> Ah yes forgot about that. Yeah it checked that the value we call CeilToInt on
is
> less than max int. We can land mine instead (also improves the DistanceToLine
> function to reduce chance of getting inf in first place).

SGTM

[Stephen White, 2015-03-20 13:44:08]

On 2015/02/24 19:30:01, Stephen White wrote:
> On 2015/02/24 19:29:24, egdaniel wrote:
> > Ah yes forgot about that. Yeah it checked that the value we call CeilToInt
on
> is
> > less than max int. We can land mine instead (also improves the
DistanceToLine
> > function to reduce chance of getting inf in first place).
> 
> SGTM

This assert was fixed elsewhere; closing.