Other Renderables

Daniel van Vugt daniel.van.vugt at canonical.com
Mon Dec 15 09:45:29 UTC 2014


On 15/12/14 17:35, Daniel van Vugt wrote:
> Does anyone have a plan for how to represent Renderables (or
> SceneElement) that don't have a buffer()? I'm thinking about dynamically
> generated elements that don't have buffer streams and are not fixed
> resolution. Such elements are either pre-generated (once) or even
> produced entirely on the GPU as a shader program.
>
> The first example is the title bar in demo-shell. It's made of a single
> texture that is mip-mapped, repeated, reflected, scaled and filtered
> dynamically according to the window size (and eventually according to
> display DPI too).
>
> A second example is a software cursor or touchspots that you might want
> to generate at hi-DPI and then mipmap/scale according to which display
> it's on.
>
> The obvious answer (maybe) is that a Renderable (or SceneElement
> whatever) needs to provide its own draw function in the case that there
> is no buffer(). That might also nicely solve the problem of "is there
> anything on screen that can't be overlayed?" -- "yes because one or more
> visible renderables don't provide a buffer() but instead only provide a
> gl_render()".
>
> A second possible solution is to just define enum RenderType {buffer,
> titlebar, fixed_texture, otherthings} and leave it up to the
> Compositor/Renderer to implement all the types.

And a third option is what Compiz does; Just don't maintain a detailed 
scene graph at all. Using the basic list of surfaces and their meta-data 
generate the scene dynamically every frame.

>
> - Daniel
>



More information about the Mir-devel mailing list