Summary: | [chromium] threaded animations easily disturbed by texture uploads | ||
---|---|---|---|
Product: | WebKit | Reporter: | Eric Penner <epenner> |
Component: | CSS | Assignee: | Nat Duca <nduca> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | nduca, reveman, vangelis, vollick |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Other | ||
OS: | Android |
Description
Eric Penner
2012-03-09 19:02:32 PST
Assigning to myself and +reveman while he and I sort out how to make this more-gooder. 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? (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). |