<div dir="ltr">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.<div><br></div>


<div>My $.02 on the Compositor naming problem.</div><div>"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?</div>

<div>Isn't there room for what the implementation does in comments? or some associated doc ?</div><div><br></div><div>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)</div>


<div><br></div><div>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"...)</div>

<div><br></div><div>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?</div>
<div><br></div>
<div>br,kg</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 20, 2014 at 12:57 AM, Daniel van Vugt <span dir="ltr"><<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK, that proposal does have problems too.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>

<br>
- Daniel</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 20/03/14 11:53, Daniel van Vugt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All,<br>
<br>
I've been trying to keep my hands out of the compositor/renderer stuff<br>
recently while alan_g and kdub move large parts around, but I keep<br>
thinking of a nicer design and wonder if anyone's thought about it...<br>
<br>
Presently we have:<br>
DefaultDisplayBufferCompositor implements bypass decision logic and then<br>
calls (delegates to) GLRenderer.<br>
That's two classes with problems:<br>
   (a) Naming things "Default"-anything doesn't tell you how the class<br>
is different to its parent and surroundings.<br>
   (b) Naming things "Renderer" is based on a verb so does not fit well<br>
with peoples mental models, leading to misunderstandings and disagreement.<br>
<br>
I suggest a nicer design would be:<br>
BypassCompositor class implements bypass decision logic (only).<br>
GLCompositor inherits from BypassCompositor and implements GL-specific<br>
rendering (replacing GLRenderer and DefaultDisplayBufferCompositor<u></u>).<br>
<br>
Admittedly "Compositor" has the verb naming problem too, but it reduces<br>
the number of classes which have that problem.<br>
<br>
I would normally propose such a change in code, but again, am trying to<br>
avoid stepping on other peoples' toes in that area.<br>
<br>
- Daniel<br>
<br>
</blockquote>
<br>
-- <br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/<u></u>mailman/listinfo/mir-devel</a><br>
</div></div></blockquote></div><br></div>