Re: Compositor / Renderer

2014-03-21 Thread Kevin DuBois
ace/override our GLRenderer/GLCompositor? >> >> br,kg >> >> >> >> On Thu, Mar 20, 2014 at 12:57 AM, Daniel van Vugt >> mailto:daniel.van.v...@canonical.com>> >> >> wrote: >> >> OK, that proposal does have problems

Re: Compositor / Renderer

2014-03-20 Thread Daniel van Vugt
niel van Vugt mailto:daniel.van.v...@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" cla

Re: Compositor / Renderer

2014-03-20 Thread Kevin Gunn
r 20, 2014 at 12:57 AM, Daniel van Vugt < daniel.van.v...@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 o

Re: Compositor / Renderer

2014-03-19 Thread Daniel van Vugt
#x27;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 t

Compositor / Renderer

2014-03-19 Thread Daniel van Vugt
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 bypas