Other Renderables

[Daniel van Vugt]

That option (and the first one) also raises an additional question:

Who and when do these non-buffer renderables get inserted? I think it's 
usually by the shell, and I think it's on surface creation/modification 
(e.g. state/type changes modify titlebar appearance). So my presently 
proposed managed-surface branch will eventually solve that (with more work).


On 16/12/14 00:50, Alberto Aguirre wrote:
> I think RenderType is what I would gravitate for (not sure if titlebar
> would be a type though}, described by the scene, rendered by the
> compositor, i.e. a scene graph :)
>
>
>
> On Mon, Dec 15, 2014 at 3:45 AM, Daniel van Vugt
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> wrote:
>
>     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
>
>
>     --
>     Mir-devel mailing list
>     Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>