gc funcs and ops at screen level

[Adam Jackson]

On 10/5/12 2:43 AM, Keith Packard wrote:
> Dave Airlie <airlied at gmail.com> writes:
>
>> It seems wierd that we have the GC carrying around a pointer to each
>> of these, when I don't see any evidence we can't just stash one set of
>> ops/funcs per screen.
>>
>> Did we every, do we currently to anyone knowledge modify gc ops or
>> funcs at anything less than a screen level?
>
> yes, we used to do this all the time in ValdiateGC where each GC was
> 'optimized' to point at funcs that were tuned for the current GC
> state. I eliminated that in fb, and most drivers seem to have followed
> suit in the years since.
>
> I intended that these should eventually live in the screen pointer;
> please go for it!

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.

- ajax