Stay in floats as much as possible in SkTileGrid, particularly in insert.

Stay in floats as much as possible in SkTileGrid, particularly in insert.

SkTileGrid::insert() is about 15% of recording time before
this CL, which reduces it to ~10%.  Next steps are looking
into some of the TODOs I've left myself, and vectorizing
the math.

Most of the win here comes from converting integer
divisions into float multiplies.

BUG=skia:1021
Committed: https://skia.googlesource.com/skia/+/65be97d1a1eb5923b078bd1e7ec1e7da6e6427e2

[mtklein, 2014-10-07 18:26:16]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-10-07 18:27:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/615853007/240001

[commit-bot: I haz the power, 2014-10-07 18:27:09]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2014-10-08 00:27 UTC

[mtklein, 2014-10-07 18:29:04]

mtklein@google.com changed reviewers:
+ junov@chromium.org, robertphillips@google.com

[mtklein, 2014-10-07 18:29:05]

Mind taking a look to see if I've got things straight?

[robertphillips, 2014-10-07 18:45:42]

lgtm but I defer to Justin on this one.

[commit-bot: I haz the power, 2014-10-07 18:46:44]

Committed patchset #13 (id:240001) as 65be97d1a1eb5923b078bd1e7ec1e7da6e6427e2

[mtklein, 2014-10-07 18:47:53]

On 2014/10/07 18:46:44, I haz the power (commit-bot) wrote:
> Committed patchset #13 (id:240001) as 65be97d1a1eb5923b078bd1e7ec1e7da6e6427e2

Justin, if you've got any comments on this (and there's no rush), I will be
happy to address them post-facto.

[Justin Novosad, 2014-10-09 20:19:17]

On 2014/10/07 18:47:53, mtklein wrote:
> On 2014/10/07 18:46:44, I haz the power (commit-bot) wrote:
> > Committed patchset #13 (id:240001) as
65be97d1a1eb5923b078bd1e7ec1e7da6e6427e2
> 
> Justin, if you've got any comments on this (and there's no rush), I will be
> happy to address them post-facto.

The code you changed is very sensitive. I think this change is okay, but to be
sure you'd have to test the interactions with the Chromium Compositor to verify
compositor tiles that are supposed to be grid-aligned enter the "if (tilesHit ==
1)" branch in search()

[mtklein, 2014-10-10 15:28:51]

> The code you changed is very sensitive. I think this change is okay, but to be
> sure you'd have to test the interactions with the Chromium Compositor to
verify
> compositor tiles that are supposed to be grid-aligned enter the "if (tilesHit
==
> 1)" branch in search()

Yeah, I was somewhat startled to see that we're regularly not hitting that fast
path, 
even before this CL.  Depending on the window size, seems my slow merges
outnumber my
fast paths by about 5 to 1.  But when we do hit the slow path, they seem to
always be
2 or 4 tiles, which a good sign that we're very close to querying 1 tile but got
off
by a little somewhere.

I tested this out at a few time points: ToT, ToT just before my CL, and M38: all
have
a lousy fast path hit rate, with M38 the worst.  I haven't been able to sync
back
before M38.

[Justin Novosad, 2014-10-14 19:02:26]

On 2014/10/10 15:28:51, mtklein wrote:
> > The code you changed is very sensitive. I think this change is okay, but to
be
> > sure you'd have to test the interactions with the Chromium Compositor to
> verify
> > compositor tiles that are supposed to be grid-aligned enter the "if
(tilesHit
> ==
> > 1)" branch in search()
> 
> Yeah, I was somewhat startled to see that we're regularly not hitting that
fast
> path, 
> even before this CL.  Depending on the window size, seems my slow merges
> outnumber my
> fast paths by about 5 to 1.  But when we do hit the slow path, they seem to
> always be
> 2 or 4 tiles, which a good sign that we're very close to querying 1 tile but
got
> off
> by a little somewhere.
> 
> I tested this out at a few time points: ToT, ToT just before my CL, and M38:
all
> have
> a lousy fast path hit rate, with M38 the worst.  I haven't been able to sync
> back
> before M38.

As long as this patch doe not affect that hit rate, it confirms that it's doing
the right thing.

It does not surprise me that the hit rate is not perfect.  The compositors
easily strays from its default tile size, in particular for skinny rects and
areas that are less that 2x2 tiles.  5-to-1 is worse than I thought though. 
Perhaps something changed on the compositor side that diverged the margin
arithmetic (so we'd only get 1:1 hits only on 1st row and/or first column).

Still, queries that hit 2 or 4 tiles are not that bad.