Currently cc::LayerTreeHost clients pass resources to cc via the TextureMailbox class. This class can hold cpu or gpu sharable resources, and we pass it into the cc::LayerTreeResourceProvider which turns it into a TransferableResource to bounce it through to the viz service/display compositor.
Meanwhile viz::Surface clients pass resources to viz via the TransferableResource class. This class can also hold cpu or gpu sharable resources, and they are forwarded through to the viz service/display compositor as is.
There's a ton of similarity between the TextureMailbox and TransferableResource, and we should be able to use just one of these. This would provide symmetry between the cc clients and the surface clients.
We have some initial thoughts around surface clients using some ClientResourceProvider or some factory code to generate TransferableResource. Then cc clients would use the same thing to generate them, and pass them into cc.
cc's ResourceProvider would need to receive TransferableResources instead of TextureMailboxes. It could treat these more independently, forwarding them along but not assigning them ResourceIds of its own (you can't lock for read/write these inside cc then - we don't). This simplifies the ResourceProvider from having currently multiple forms of RemotableResources with an internal vs external vs delegated enum. External+delegated resources would combine into a separate thing entirely, and only internal resources would be assigned ResourceIds and lockable.
The effects on Pepper/Canvas/WebGL should just be the format that they generate changing, without any larger consequences to their code.
The majority of the change would, I think, be TextureLayer{Impl} changing its storage type to TransferrableResource, ResourceProvider growing a separate storage for transferable things, and the ability to specify a foreign TransferableResource to transport to parent.
Open questions:
1. It would be possible for TextureLayer to skip the cc ResourceProvider entirely then. But if it did, how would we hook up the ReturnedResources callback to the CompositorFrameSinkClient (ie LayerTreeHostImpl) to the TextureLayer for its TransferableResource.
2. Otherwise, TextureLayer could tell ResourceProvider about the TransferableResource and ResourceProvider would hear about it being returned. How would ResourceProvider tell that the returned ResourceId was for the TransferableResource as the ids are a different namespace and could collide with its own local ids.
Possible solution to these:
- TextureLayer passes TransferableResource to ResourceProvider and gets back a new local ResourceId.
- ResourceProvider stores a separate map of these ids to the original TransferableResource+ReleaseCallback.
- TextureLayer uses the local ResourceId in its quads.
- When the local ResourceId is returned to ResourceProvider it doesn't find it in |resources_| so it looks for it in |transferable_resources_|, finds it, and calls the ReleaseCallback back to the TextureLayer and its client.
Comment 1 by danakj@chromium.org
, Sep 27 2017Components: Internals>Compositing
Labels: -Pri-3 Pri-2