Closed Bug 1079184 Opened 11 years ago Closed 8 years ago

Sort out the relationship between TextureSource and CompositingRenderTarget

Categories

(Core :: Graphics: Layers, defect)

x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: nical, Unassigned)

Details

Currently CompositingRenderTargets inherit from TextureSource, but some backends (like GL) actually don't implement TextureSource in CompositingRenderTarget (just assert that the methods are never called, while some others (like D3D11) do implement it. This is not a terrible problem but it's a bit awkward and adds to the list of things that work differently between backends, which sometimes produces bugs with a cross-backend API behaving differently depending on the underlying backend. I feel like CompositingRenderTarget should be a simple interface that TextureSource subclasses could implement or not, and have a safe cast "AsRenderTarget()" method in TextureSource that would return null unless overridden. The main question is, do we need to be able to keep RefPtr<CompositingRenderTarget> (in which case this hierarchy split doesn't work very well due to TextureSource already being ref counted. Anyway, while not very important, this should be trivial to fix one way or another, and remove some surprises in the code. Sorting this out should also make it easier to implement a way to render into a TextureHost (for example to implement a screen capture API on the compositor)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.