On 10/5/12 2:43 AM, Keith Packard wrote:
Dave Airlie <airl...@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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
