Compositor / Renderer

[Daniel van Vugt]

I'm not 100% sure how bypass would be represented still. Before I did 
bypass I was convinced "that's not composition". And by the time it was 
finished, it certainly became part of composition.

Presently the logic is very linear:

bool mc::DefaultDisplayBufferCompositor::composite()
{
     attempt to do fullscreen bypass if any surface fits
     else
     GLRender everything
}

That does lend itself to clear and simple division of responsibility. 
The two parts should be easy to move around.

- Daniel


On 20/03/14 23:45, Kevin Gunn wrote:
> 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 <mailto: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 <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>
>
>