cc: Upload cheap tiles synchronously

cc: Upload cheap tiles synchronously

When we have determined that a tile is cheap to rasterize and have
performed the rasterization on the impl thread, upload the tile texture
synchronously instead of passing it though the asynchronous upload
queue. This further reduces the latency of cheap tile updates.

BUG=161828
BUG=173802

[Sami, 2013-02-04 18:32:37]

Like I mentioned in crbug.com/173802, I think this might need a throttling
mechanism to avoid doing too many synchronous uploads per frame.

[nduca, 2013-02-04 23:21:11]

+reveman

[reveman, 2013-02-04 23:37:51]

looks good. there's already some inconsistencies in the usage of the term
"upload" in the tile manager. as you're adding another use of this term, do you
mind changing the existing use of "set pixels" to "upload" as part of this
patch? (just in the tile manager, not the resource provider)

[epenner, 2013-02-04 23:40:11]

On 2013/02/04 23:21:11, nduca wrote:
> +reveman

I haven't looked in depth at the code but the idea seems good. I do think we
need an extra off-switch for this, to insure it doesn't occur while we are
scrolling or during pinch zoom. Currently 'smoothness mode' represents that
pretty well.

[reveman, 2013-02-05 02:24:03]

Have we considered posting these raster tasks to the impl thread message loop
instead of performing them immediately? 

I'm bit worried about doing too much work on the impl thread without returning
to the message loop as that would prevent us from being notified about other
raster tasks completing and delaying those uploads. Or maybe the intention is to
never allow threaded raster at the same time as immediate?

[nduca, 2013-02-05 06:32:17]

I think its important to do it immediately. The cycling of the message loop is a
substantial portion of what we're trying to avoid. We can prevent holding the
loop too long by timing the task and not doign more than N ms of work. For, say,
6ms.

[Sami, 2013-02-05 15:44:12]

On 2013/02/04 23:37:51, David Reveman wrote:
> looks good. there's already some inconsistencies in the usage of the term
> "upload" in the tile manager. as you're adding another use of this term, do
you
> mind changing the existing use of "set pixels" to "upload" as part of this
> patch? (just in the tile manager, not the resource provider)

Yeah, I found that a bit confusing too. This latest patch should make the terms
consistent.

FYI, I've added the limit of 6 cheap rasters or 6 ms spent rasterizing per frame
in https://codereview.chromium.org/12194015/ which is also inherited by this
patch. I'll see how to integrate the smoothness mode next.

[nduca, 2013-02-05 19:51:03]

Lets leave smoothness mode as a followup so we can evaluate the merits of this
patch on its own and really understand the implications of that part on the
overall performance.

[reveman, 2013-02-05 22:30:03]

lgtm. thanks for fixing the setpixels/upload inconsistency.

[reveman, 2013-02-05 22:34:26]

also when in NEW_CONTENT_TAKES_PRIORITY mode, everything visible on pending tree
should be synchronous as we can't draw until tree is activated. that's a follow
up though.

[nduca, 2013-02-05 23:58:35]

Lets file a crbug for the followup.

[reveman, 2013-02-06 00:32:30]

On 2013/02/05 23:58:35, nduca wrote:
> Lets file a crbug for the followup.

crbug.com/174507

[Tom Hudson, 2013-02-06 13:24:35]

On 2013/02/05 06:32:17, nduca wrote:
> I think its important to do it immediately. The cycling of the message loop is
a
> substantial portion of what we're trying to avoid. We can prevent holding the
> loop too long by timing the task and not doign more than N ms of work. For,
say,
> 6ms.

What's keeping us from speeding up the message loop, then?

[nduca, 2013-02-06 13:50:56]

Whats hard about webpage rendering? I mean, its just a bunch of squares and
text... :)

[reveman, 2013-03-15 21:51:56]

we don't need this anymore, right?

[Sami, 2013-03-18 10:24:31]

Right, closing.