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

Keith Packard keithp at keithp.com
Thu Jun 10 18:59:41 PDT 2010


On Thu, 10 Jun 2010 15:37:40 -0700, Jamey Sharp <jamey at minilop.net> wrote:
> A window's DrawableRec's x and y fields contain the offsets to be
> applied to protocol-visible window-relative coordinates in order to make
> those coordinates screen-relative instead. When Xinerama is active,
> coordinates relative to the root window need to be adjusted for each
> screen by the position of that screen in the logical root coordinate
> space, so (-pScreen->x) and (-pScreen->y) are the natural values for
> the root drawable's x and y offsets.
> 
> Other windows still have root-relative drawable coordinates, as if the
> root window's coordinates were (0,0). See CreateWindow.
> 
> This eliminates special cases throughout the Xinerama layer that needed
> to adjust coordinates as specified by clients if they were used relative
> to a root window.
> 
> Signed-off-by: Jamey Sharp <jamey at minilop.net>
> ---
> I'm not proposing this for 1.9--in fact I've only compile-tested it and
> it's probably wrong somehow. But I'd like to get feedback on whether a
> patch like this one is a good idea and what it breaks.

As you might imagine, there are a million corner cases with tile origins
that could be broken here. Certainly the basic idea of making
drawable.x/drawable.y correct for tiling has a lot of merit.

Fortunately, the test suite should be able to catch errors of that
nature, so making sure that works would be a good first step.

> If this approach is good, I have or can write patches to move ValidateGC
> and DestroyGC from GCFuncs to ScreenRec, and eliminate the other five
> GCFuncs. The patches I have along those lines so far kill 730 lines of
> code, on top of the 800 removed here, and promise more to come.

One of the benefits of having the GC funcs in a shared structure is that
you can unwrap all of the ops and funcs with two pointer exchanges,
which makes calling down to the next layer fairly inexpensive. Instead
of pulling more funcs into the screen rec, I'd love to see a more formal
render layering architecture that moved all of the rendering functions
into a single exposed structure that could be unwrapped and re-wrapped
easily. Merging the GCops, GC funcs and render funcs together.

Then there are a few functions, like CloseScreen, which need to be
replaced with a callback instead of wrapping. It would be cool if we
identified two classes of functions, wrapped drawing functions and
callback state change functions.

No, I don't know if this would work either :-)

-- 
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/3443cfba/attachment.pgp>


More information about the xorg-devel mailing list