splitting drawable and screens

[Dave Airlie]

On Fri, Oct 5, 2012 at 12:53 PM, Keith Packard <keithp at keithp.com> wrote:
> Dave Airlie <airlied at gmail.com> writes:
>
>> I considered this, but really drawables are generally a protocol
>> object, in a lot of cases a Window which really has no interesting
>> properties to a GPU.
>
> Yeah, getting to the point where the only GPU visible objects are
> pixmaps would be great; that's the surface we're drawing to, after
> all. It seems like making that migration within the current API might
> actually be fairly straightforward? Hack up the Picture code so that all
> coordinates are screen-relative and just start passing the window
> pixmap, then do the same for GC rendering?

Yeah I've actually implemenrted most of that in an impedance layer,
but I was going
to leave that until shatter/xinerama replacement, since its actually a
bit of a pain in the ass
to validate, its like composite wrapper on steroids.

>> So since ajax has convinced me for GCs and Pictures that I really want
>> per-GPU versions, I was think of adding a pScreen to Picture and to a
>> few interfaces like GetImage need changes, but much reduced.
>
> Are you thinking that the existing GC and Picture structs become the GPU
> versions and that we create new protocol structs then? Otherwise, we'll
> run into a constant stream of confusion over which "kind" of struct each
> API requires, right?
>
No I want to retain the GC and Picture structs as-is, duplicating them
won't help anyone, it just makes a mess worse, if something really
needs to know it can check pGC->pScreen->isGPU, also since some
pictures aren't associated with screens or drawables at all its even
messier to start duplicating them.

Maybe I should just all in and try and submit the full-on impedance
layer it just struck me it might be easier to start with something
that just pushes drawables as far down as possible and only translates
to GPU pixmaps at the drawing operation, i.e. in fb or
uxa/exa/sna/snafb.

Dave.