Some considerations

[Martijn Sipkema]

[...]
> I don't really see the problem.  In the current case there is an
application
> rendering to an offscreen buffer (its backbuffer) and there is some sort
of
> swapbuffers operation - either a copy or a pageflip.  I don't see what
would
> be different in a compositing situation.

It would no longer be possible to take advantage of per window framebuffer
configurations and zero-copy swaps as e.g. SGI hardware provides.

> In general, if there is a specific case that has an obvious fastpath
> implementation, we make sure we can take advantage of it.
>
> I'm not really convinced we need to start worrying about optimizing a
system
> which is still in its infancy, but an the other hand I agree we shouldn't
> architect it in such a way to preclude such optimizations.

The fundamental change such that windows are no longer opaque is not trivial
and use of hardware supporting a windowed framebuffer becomes difficult.
How would compositing work with a framebuffer containing windows with
varying visuals (framebuffer configurations)?

--ms