Am Dienstag 20 November 2007 06:19:00 schrieb Keith Packard:
> On Tue, 2007-11-20 at 06:01 +0100, Dennis Kasprzyk wrote:
> > Hi,
> >
> > I thought a while about the current XComposite functionality and found
> > some points that could be improved.
> >
> > ARGB windows currently have to be drawn with premultiplied alpha. This
> > leads to dark (black) areas of the window, if no composite manager is
> > used. Most of the ARGB windows would look better in a non composited
> > environment if non premultiplied alpha could be used. The composite
> > extension could provide 2 argb visuals (one for premultiplied alpha and
> > one for non premultiplied alpha) to inform the composite manager how to
> > draw the window correctly. An application developer could then choose the
> > best visual for his application.
>
> The Composite extension doesn't actually enforce any interpretation of
> the extra bits in the pixel. It's only a convention that we use
> premultiplied alpha. Premultiplied alpha is also a lot easier to compute
> as it doesn't suffer from divide-by-zero issues with transparent pixels.
>
I know that Premultiplied alpha is easier to compute, but a lot of 
applications need to have a composite manager detection and a special 
rendering path to provide premultiplied alpha. We also don't provide any 
system that would indicate that a window is not using premultiplied alpha. 
With such a system composite managers could simply ignore the alpha channel if 
they have problems with non premultiplied alpha. Non premultiplied alpha 
shouldn't be a problem for gl based composite managers, but I don't know how 
the situation will look like with xrender.
> > Another problem is the XShape extension. XShape currently also clippes
> > drawing operations to the redirected pixmap. If this could be disabled,
> > an ARGB application could use XShape to have a shape when no composite
> > manager is running, but also inform the composite manager (with a window
> > hint) to ignore the XShape informations to paint the whole window pixmap.
> > With something like this an application could be correctly shaped when no
> > composite manager is running, but provide nice antialiased edges (and
> > maybe shadows) if a composite manager is running.
>
> We've already started seeing conventions that indicate when a
> compositing manager is running; having applications not shape their
> windows in this case would be more efficient than having the computed
> shape be ignored.
>
A lot of application will still use XShape for their input shape, so that 
ignoring of the output shape in the server would simply make the handling in 
the application easier.
> > All current ideas to implement window previews in a taskbar rely on some
> > kind of communication of the taskbar with the composite manager. My idea
> > is to provide a more flexible system directly in the composite extension
> > that could also work without a running composite manager.
>
> Automatic redirection does precisely this already.
Didn't know this.

Dennis

_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg