gc funcs and ops at screen level

[Dave Airlie]

>
> Sorry to be late to this, but no, please don't.  Draw ops being embedded in
> the Screen (and PictureScreen) was one of the biggest irritants with trying
> to write shatter, something I still do want to try to finish at some point.
>
> Funcs can live at the screen, that's fine, and even desirable, almost all of
> the func wrap layers only subclass ValidateGC anyway.  And, importantly,
> validating one GC can't possibly require validating a second one to do it.
>
> But ops really shouldn't.  Once you start drawing you may want to re-start
> it against a proxy set of drawables, and that means you need to get access
> to a fresh wrap chain.  It's a little tough to get a scratch screen.
>
> I've taken a crack at moving GetImage and GetSpans to the drawable instead
> of the screen, and with moving the GC funcs up to the Screen. Not finished
> yet, but:
>
> http://cgit.freedesktop.org/~ajax/xserver/log/?h=drawable-ops
> http://cgit.freedesktop.org/~ajax/xserver/log/?h=gc-rework
>
> Ideally to really fix that for shatter I need to modify GetImage to take
> destination pitch as an argument, but it's a start.

Please I don't think doing shatter that way is a good plan, I have a
plan that leads to there by taking the current code, adding the
impedance layer between protocol and rendering screens, then making
that impedance layer magically turn into shatter. When you do it like
that the problem you faced with proxy drawables and restarting
rendering just goes away, since you get a protocol request at the
impedance layer, and you already have a set of per-driver
drawables/gcs/pictures linked to the protocol versions, you don't have
to restart any operations, you just split the protocol operation into
multiple rendering requests to each GPU pixmap with a different clip.

It just means getting there a lot slower, and adding features along the way..

Dave.