Other Renderables

Alberto Aguirre alberto.aguirre at canonical.com
Mon Dec 15 16:50:16 UTC 2014

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> 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
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20141215/3ad77ef0/attachment.html>

More information about the Mir-devel mailing list