I guess, still 'needs fixing', as the "is_a_surface" still has no context down within the mg::DisplayBuffer::post_renderables_if_optimizable function. Like, what should the display buffer do if this function returns false? "can hwc draw non-surfaces?" has an ambiguous answer.
In my estimation, mg::Renderable should just be a basic list of squares, the traditional information needed for blitting. A RenderableList should give a defined, specific picture that can be drawn.
I don't mind SceneElement gaining information that's specific to the scene, but Renderable should remain a simple list of squares.
Just for future planning, I think that some of this conflict is just because the name 'Renderable' is liked quite a lot. Perhaps we should rename the stuff down in the compositor BlitSquares, and then the Renderable/SceneElements can expand in whichever ways they need to, without dragging the platform display buffers (and the HWC implementation) along for the ride.
I guess, still 'needs fixing', as the "is_a_surface" still has no context down within the mg::DisplayBuff er::post_ renderables_ if_optimizable function. Like, what should the display buffer do if this function returns false? "can hwc draw non-surfaces?" has an ambiguous answer.
In my estimation, mg::Renderable should just be a basic list of squares, the traditional information needed for blitting. A RenderableList should give a defined, specific picture that can be drawn.
I don't mind SceneElement gaining information that's specific to the scene, but Renderable should remain a simple list of squares.
Just for future planning, I think that some of this conflict is just because the name 'Renderable' is liked quite a lot. Perhaps we should rename the stuff down in the compositor BlitSquares, and then the Renderable/ SceneElements can expand in whichever ways they need to, without dragging the platform display buffers (and the HWC implementation) along for the ride.