[RFC PATCH] CreateRootWindow: Set root windows' drawable.x/y to -pScreen->x/y.

[Keith Packard]

On Thu, 10 Jun 2010 19:50:29 -0700, Jamey Sharp <jamey at minilop.net> wrote:

> I guess I'd need to run the test suite on a Xinerama server, and
> probably need to ensure that windows that XTS creates span two
> screens. Or something? I'm not sure how to even hit these cases,
> especially in XTS.

Yeah. It will be easier to arrange if you've got a tiny screen on each
card...

> In my opinion it would be better to arrange that GC ops never need to
> unwrap ValidateGC than to continue with the current double-unwrapping
> mess.

With a more structured graphics operation layering architecture, each
layer could manipulate their presence in the chain without needing to do
that in the middle of a call sequence.

> I think it's easy enough to ensure that every ValidateGC call
> inside a GC op is on a scratch GC, although setting up the scratch GC
> efficiently might be harder. I have part of a patch written that does
> this, just copying all elements of the real GC into the scratch GC.

No, as you can see, many of the layers just need to see the operation as
it passes along, potentially modifying some of the parameters. Creating
a scratch GC for that purpose doesn't seem sensible. Besides, a scratch
GC created there will have the whole rendering stack to drill through,
it won't be operating on top of the underlying layer at all.

> The current scheme is crazy. We call ValidateGC because we want the
> ops updated for whatever is suitable for our hardware--but in the
> cases where double-unwrapping matters, AFAICT we're guaranteed to get
> an mi version of all ops. That's surely not desirable, and I'm not
> even convinced it's correct!

I don't understand this at all.

> One reason I'd like to move ValidateGC in particular to the ScreenRec
> is that several CreateGC wrappers exist solely to set up a ValidateGC
> wrapper, and those always use the same implementation of ValidateGC
> regardless of any parameters in the GC. If you can set the ValidateGC
> wrapper on the screen in the first place, the currently piles of code
> just look silly.

Frankly, I wouldn't mind asserting that each rendering layer never
change the functions that implement operations within that layer. I
think I've managed that in the layers I've written, like kaa (-> exa ->
uxa) and fb. Wrapping any other layers in suitable run-time switches
should be quite easy. The whole notion of pre-computing the appropriate
rendering function just doesn't make a lot of sense given the overhead
of running a single protocol request through our current rendering
stack.

Once you have this invariant property, you can bundle all of the
operations into a single structure and place a linked list of those in
the screen rec. You don't 'unwrap', you just pass the pointer along with
the operation so that the wrapping functions just follow that chain as
they call down the stack.

> The other reason is I'm hoping to kill the PanoramiXRes structure and
> have a single GC/Drawable/Colormap/etc. object allocated for each
> protocol-visible XID. I don't know exactly what that would look like
> (I can sketch pieces if anyone's curious), but I think it's easier to
> get there with as little screen-dependent data in each object as
> possible.

Yup, the GC should just contain the protocol data from the application,
and if we have multiple video cards, then they can each place private
data on the same GC in separate storage.

> I guess GCOps are worth keeping inside the GC, assuming
> somebody cares about hardware acceleration for those ops, but I can't
> see any reason for GCFuncs to live there.

I disagree -- run-time selection of the appropriate function is less
error-prone and easier to develop, with little or no performance impact.

> I can send along my patch to move DestroyGC to ScreenRec if you'd like
> to base a callback-chain patch on that.

I'll be busy working on 1.9 through august at this point, but I
encourage you to keep poking at these ideas in the meantime.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100610/de8679ae/attachment.pgp>