Compositor / Renderer

Daniel van Vugt daniel.van.vugt at canonical.com
Thu Mar 20 05:57:21 UTC 2014


OK, that proposal does have problems too.

But still I'd like to discuss the possibility that "Renderer" classes 
should not exist. They should (somehow) be part of a hierarchy of 
"Compositor" classes.

- Daniel


On 20/03/14 11:53, Daniel van Vugt wrote:
> All,
>
> I've been trying to keep my hands out of the compositor/renderer stuff
> recently while alan_g and kdub move large parts around, but I keep
> thinking of a nicer design and wonder if anyone's thought about it...
>
> Presently we have:
> DefaultDisplayBufferCompositor implements bypass decision logic and then
> calls (delegates to) GLRenderer.
> That's two classes with problems:
>    (a) Naming things "Default"-anything doesn't tell you how the class
> is different to its parent and surroundings.
>    (b) Naming things "Renderer" is based on a verb so does not fit well
> with peoples mental models, leading to misunderstandings and disagreement.
>
> I suggest a nicer design would be:
> BypassCompositor class implements bypass decision logic (only).
> GLCompositor inherits from BypassCompositor and implements GL-specific
> rendering (replacing GLRenderer and DefaultDisplayBufferCompositor).
>
> Admittedly "Compositor" has the verb naming problem too, but it reduces
> the number of classes which have that problem.
>
> I would normally propose such a change in code, but again, am trying to
> avoid stepping on other peoples' toes in that area.
>
> - Daniel
>



More information about the Mir-devel mailing list