Subject: Compositor / Renderer

From: Daniel van Vugt <[email-masked]>
Date: Thu, 20 Mar 2014 11:53:02 +0800

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

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 20 Mar 2014 13:57:21 +0800

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

---

From: Kevin Gunn <[email-masked]>
Date: Thu, 20 Mar 2014 10:45:37 -0500

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 <
[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: Fri, 21 Mar 2014 09:27:25 +0800

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.
>
> "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?
> 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
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     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
>
>
>
>         rendering (replacing GLRenderer and
>         DefaultDisplayBufferCompositor__).
>
>     [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>
>
>

---

From: Kevin DuBois <[email-masked]>
Date: Fri, 21 Mar 2014 10:09:34 -0700

The interfaces in DisplayBuffer for android overlay support are flexible
enough to handle bypass, although they are not being used yet. The approach
has added flexibility in that we can arrange for other optimisations that
the mesa platform can have (eg, we can bypass with a hardware cursor)
without having to burden the DefaultDisplayBufferCompositor with the
optimization responsibilities.

The mesa platform should look over the list of surfaces and pick decide to
bypass if there's just one fullscreen surface. The objection I had when
this code landed was that its platform-specific code in a
platform-independent class, and we're getting to the point where moving
bypass functionality is possible. Although its moderately reasonable to
think that bypass would be something that is platform independent, the
android drivers have the responsibility to decide if they can bypass or
not. [1]

My plan here is to hook up the android overlay stuff and then transition
mesa and android to have the all the hardware optimizations done in the
platform libraries.

Cheers,
Kevin

[1] At a deeper level, there are hardware reasons for this. Eg, sometimes
an overlay is picked instead of a 'strict bypass' (like mesa can do), the
mobile display processors can play tricks, or the mmu's aren't flexible
enough to accept a framebuffer from any old gpu region

On Thu, Mar 20, 2014 at 6:27 PM, Daniel van Vugt <
[email-masked]> wrote:

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