Compositor / Renderer

[Kevin Gunn]

hey Daniel - i'm glad you brought this up, we've had plenty of Compositor &
GLRenderer discussions lately...worthy of hopefully a relatively _quick_
airing of ideas & resolution.

My $.02 on the Compositor naming problem.
"Default" I don't mind, at least in my mind that means to me its something
I can rip out and replace if I want. Unless of course, we don't really want
to encourage that...then I would agree, give it a name that simply better
specifies how its implemented. So what's the intention there?
Isn't there room for what the implementation does in comments? or some
associated doc ?

Wrt naming it "BypassCompositor"....is that really a good idea? I mean
let's say you go back in and add dirty region tracking & rendering, it'd be
more than just "bypass" so would you rename to DirtyRegionCompositor ?
(btw, this is on my list of things we should do eventually)

Wrt GLRenderer vs GLCompositor....I can see that. GLRenderer might be a bit
abstract, whereas when I see GLCompositor I would think "oh, here's where
layers of apps get composed"....and the model would fit to have the HWC
attempt/alternate route. (note: most vendor implementations of HWC actually
contain a "gl compositor"...)

Wrt splitting out BypassCompositor logic from the GLCompositor/GLRenderer,
that does make sense to me, especially in the instance where someone might
want to put in their own compositor. And this is the point where I wanted
to gather a little more thot. I know GLRenderer/GLCompositor can be made to
be a "convenience" api, which can be really simple, easy for us to
maintain...but can end up being rather fixed function in terms of gl,
shouldn't we consider that down the road some compositors (or shells above
them) might want to have some ability to "program" the gl renderer for
"some effects" strive to keep this interface tinker-toyish. Or do we say if
someone wants more they replace/override our GLRenderer/GLCompositor?

br,kg



On Thu, Mar 20, 2014 at 12:57 AM, Daniel van Vugt <
daniel.van.vugt at canonical.com> wrote:

> 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
>>
>>
> --
> 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/20140320/425d8ee8/attachment.html>