Bug 80746 – [chromium] threaded animations easily disturbed by texture uploads

• Status: RESOLVED
• Resolution: WONTFIX
• Component: CSS

[Eric Penner]

We start threaded animations after we upload all textures on the compositor thread. But the actual upload to GPU takes place later in the GPU process. These uploads can be slow on some platforms, so it would be nice to wait until this is truly done before starting the animation (so animation will be smooth).

[Nat Duca]

Assigning to myself and +reveman while he and I sort out how to make this more-gooder.

[Nat Duca]

I think this will help:
https://bugs.webkit.org/show_bug.cgi?id=81004

Eric, do we have line-of-sight to a technique to getting texture upload cost as part of the tex call rather than the draw call on pvr?

[Eric Penner]

(In reply to comment #2)
> I think this will help:
> https://bugs.webkit.org/show_bug.cgi?id=81004
> 
> Eric, do we have line-of-sight to a technique to getting texture upload cost as part of the tex call rather than the draw call on pvr?

I want to experiment more to totally confirm this, but if we use texSubImage2d rather than texImage2d it causes the cost to paid upfront rather than on the first draw call (it's still very expensive though). Further, if we recycle textures *and* use texSubImage2D then the cost is reduced significantly. I don't want to say this with 100% certainty yet, because the cost could have just moved somewhere else again :) but I'll be able to confirm it soon.

However, this issue with animation is more related to the fact that our command buffer tex*Image calls are always relatively inexpensive, which results in us starting the animations before the heavy GPU cost is paid (the real tex*Image calls, or drawArrays calls depending on how we upload it).