Top-most windows

[Keith Packard]

On Thu, 2006-01-12 at 11:58 -0800, Deron Johnson wrote:
> The GL solution is a heavyweight solution which, from a systems
> engineering perspective has the highest total cost of implementation.
> 
> + It only addresses GL; it doesn't address other types of graphics
>   and imaging libraries that a compositing manager may wish to use.

I don't understand this -- right now, only GL has any trouble drawing
the compositing manager output to the root window.

> + It requires two changes to the GL API and associated driver
>   interface. Furthermore, The API will need to evolve over the
>   next couple of years as it moves from being an EXT extension
>   to an ARB extension to part of the GL core. Clients of this
>   interface will need to continually adapt to the syntax changes
>   which arise from this evolution. And the earlier incarnations
>   will need to still be supported for some time.

These changes already exist in GLX 1.3, so there's no actual change to
GL being proposed.

> + It will take orders of magnitude more time to implement than the
>   alternative.

We have an alternative available today which requires zero time to
implement; while it seems kludgy to you, we're already living in a land
of GL compositing manager kludges as we have no unified video memory
environment. One more kludge won't break the bank.

> + It doesn't have a definite completion milestone. It will take an
>   indefinite amount of time for drivers to be upgraded and even
>   then there will always be older devices that won't support it.

We have a working alternative available today which doesn't even need to
wait for an updated X server.
 
> + It addresses these problems for all conceivable graphics and imaging
>   libraries.

Only GL is broken today; all other X rendering systems have
IncludeInferiors drawing. That your DID-based video card has DID issues
is a separate problem which needs to be fixed independently of the
Composite extension. IncludeInferiors rendering is defined in the case
of matching visuals between parent and child.
 
> In short, the GL solution is like using a pile driver to drive in a nail.

No. The only changes needed is to figure out how to draw over the child
windows when painting to the root window. Whether we fix composite so
that Manual Update windows don't clip when drawing to the parent, or
whether we add IncludeInferiors drawing for the root window is a
separate solution.

Requiring an extension for this means that you still have the
client/server incompatibility issue to resolve, forcing your client to
either fall back to the RaiseWindow solution or causing it to fail when
the X server doesn't support your extension. Either case is bad for us;
falling back means you have two code paths in your application to test,
one of which will probably not work right unless you explicitly test it
in QA, forcing you to choose between bug reports and increased QA time.

The cost of even the smallest extension must be measured over the
perceived long term benefit to the window system as a whole. Right now,
I'm not getting the sense that this solution will stand up to the test
of time, nor will it make it cheaper for you to ship a product.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-arch/attachments/20060112/2a671003/attachment.pgp