round cubic pt coords to SkFDot6, rather than just (int) casting. This gives a

round cubic pt coords to SkFDot6, rather than just (int) casting. This gives a
more accurate value, and fixes a bug (cr131181) where, due to the cast, we
produce a non-monotonic line-segment from the cubic, which triggered an assert.

[caryclark1, 2012-06-15 20:40:53]

lgtm

[reed1, 2012-06-15 20:46:20]

I will defer committing until we can make a plan to update chrome's DRT results
(~260 images change on linux)

I am now running some benchmarks, to see what the perf cost is

[epoger, 2012-06-15 20:49:38]

On 2012/06/15 20:46:20, reed1 wrote:
> I will defer committing until we can make a plan to update chrome's DRT
results
> (~260 images change on linux)

Given that we still don't have a good plan for that, is there an alternate fix
to http://crbug.com/131181 ('page crash') that won't change graphical results?

And given http://code.google.com/p/chromium/issues/detail?id=131181#c9 , does
this change even really fix that bug?

> 
> I am now running some benchmarks, to see what the perf cost is

[reed1, 2012-06-15 21:00:56]

Bench results: small round-rects (which use cubics) draw ~1% slower. 

There is definitely work we can do to speed up our round2int (which is called),
maybe we can cut this deficit in half. who knows.

[reed1, 2012-06-15 21:02:05]

Its possible there are other changes/hacks to avoid the assert, but I'm not sure
they won't also affect images.

At the moment, we don't know if there is any real downside to the current code,
other than the assert (debug only). I will investigate this.

[reed1, 2012-06-15 21:03:41]

correction: the slowdown might be as high as 3%

bench -repeat 200 -match rrects