Compositor / Renderer

Fri Mar 21 17:09:34 UTC 2014

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 <
daniel.van.vugt at canonical.com> wrote:

> 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>
>>
>>
>>
> --
> 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/20140321/f5b31656/attachment.html>