Subject: Other Renderables

From: Daniel van Vugt <[email-masked]>
Date: Mon, 15 Dec 2014 17:35:40 +0800

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.

- Daniel

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 15 Dec 2014 17:45:29 +0800

> 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.

---

From: Alberto Aguirre <[email-masked]>
Date: Mon, 15 Dec 2014 10:50:16 -0600

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 <
[email-masked]> wrote:
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 16 Dec 2014 09:31:16 +0800

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:
> On Mon, Dec 15, 2014 at 3:45 AM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     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
>     [email-masked] <mailto:[email-masked]>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>