Closed
Bug 1079184
Opened 11 years ago
Closed 8 years ago
Sort out the relationship between TextureSource and CompositingRenderTarget
Categories
(Core :: Graphics: Layers, defect)
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)
Reporter | ||
Updated•8 years ago
|
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.
Description
•