Bug 89474 – [chromium] Use CCRenderPassTextureAllocator in LayerRendererChromium

• Component: New Bugs
• Status: RESOLVED INVALID

[Dana Jansens]

[chromium] Use CCRenderPassTextureAllocator in LayerRendererChromium

[Dana Jansens]

Created attachment 148343 [details]
Patch

[Dana Jansens]

This is what it looks like when hooking up the RenderPassTextureAllocator

[Dana Jansens]

Comment on attachment 148343 [details]
Patch

misclick ews :< the button is so big!

[WebKit Review Bot]

Comment on attachment 148343 [details]
Patch

Attachment 148343 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/13003243

[Dana Jansens]

Created attachment 148666 [details]
Patch

[Adrienne Walker]

Comment on attachment 148666 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=148666&action=review

> Source/WebCore/platform/graphics/chromium/cc/CCRenderPassTextureAllocator.cpp:125
> +void CCRenderPassTextureAllocator::decideAllocationsForFrame(const CCRenderPassList& renderPassesInDrawOrder, const IntSize& deviceViewportSize, size_t memoryLimitBytes)

How does this function interact with removing cached frames and damage?

(1) Considering some surfaces "in use" when they're not actually going to get drawn will cause us to overestimate our high water mark of texture usage and toss out more textures than we actually need to. For example, assume you have a super deep dependency subtree of render passes, but the one at the top has no damage.  The removing cached passes function occurs after this and would remove all but the top.  However, the only textures that you'd need to save would be the top one and all of its direct dependencies.  This may be way less than the amount of in use textures.

(2) Without considering damage, are you possibly considering saving textures that we need to completely redraw? (I suppose we could consider doing partial surface updates.)

(3) Without considering damage, are you possibly considering saving textures that aren't going to get drawn, because we've saved some ancestor texture that depends on it?

PS Would it make sense to just have render passes know explicitly about their dependent render passes, rather than having to paw through the quad list?

[Dana Jansens]

(In reply to comment #6)
> (From update of attachment 148666 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=148666&action=review
> 
> > Source/WebCore/platform/graphics/chromium/cc/CCRenderPassTextureAllocator.cpp:125
> > +void CCRenderPassTextureAllocator::decideAllocationsForFrame(const CCRenderPassList& renderPassesInDrawOrder, const IntSize& deviceViewportSize, size_t memoryLimitBytes)
> 
> How does this function interact with removing cached frames and damage?

There's no notion of damage in the RenderPass list right now so it is ignoring the whole idea. I'm planning to add the contentsDamaged() flag in there somewhere so it can drop textures from the previous frame that are damaged immediately and they don't cost budget.

> (1) Considering some surfaces "in use" when they're not actually going to get drawn will cause us to overestimate our high water mark of texture usage and toss out more textures than we actually need to. For example, assume you have a super deep dependency subtree of render passes, but the one at the top has no damage.  The removing cached passes function occurs after this and would remove all but the top.  However, the only textures that you'd need to save would be the top one and all of its direct dependencies.  This may be way less than the amount of in use textures.

Yes. I think we would like to save all the textures if we can, as it allows us to recover optimally from any damage, but they should not count as being needed, and should be dropped more easily.

> (2) Without considering damage, are you possibly considering saving textures that we need to completely redraw? (I suppose we could consider doing partial surface updates.)

I am thinking about this, and perhaps reusing textures more aggressively for different surfaces to avoid texture delete/create.

> (3) Without considering damage, are you possibly considering saving textures that aren't going to get drawn, because we've saved some ancestor texture that depends on it?

Not /because/ of it, but I think we should save as many textures, overall, as fit within our budget.

> PS Would it make sense to just have render passes know explicitly about their dependent render passes, rather than having to paw through the quad list?

Given the size of the quad lists, I'm not sure..