Re: GTK+ canvas?

On Sat, 2006-09-09 at 23:15 +0200, Soeren Sandmann wrote:
> H
> Another thing that is worth considering is whether composite is really
> all that great. A lot of the features of composite could be
> implemented on the client side without any (or much simpler) X server
> changes.
> Instead of creating a toplevel window, application could simply create
> a pixmap, then notify the window manager whenever that pixmap was
> ready to be published. The benefits here are
> - no X extension with unclear semantics needed
> - applications are explicitly aware that they are drawing to an
>   offscreen area which means they can do things like scrolling without
>   worrying about intermediate steps.
> To do tear-free compositing, the X server may need to provide a
> copy-on-write copy mechanism for pixmaps, but that is both simpler and
> semantically much more well-defined than Composite/Damage.

This is slightly similar to the offscreen windows work I did for gtk+.
It uses a single pixmap and manually handles event subsetting and
clipping. This uses a toplevel window to get the events of course, and
the pixmap solution must have something similar so that X sends events.
Maybe an input-only window?

There are some problems with this though. By not using real windows you
loose a lot of X functionallity. For things like Xv, OpenGL, XIM,
XEmbed, etc you really need a real window, and it has to be put in a
normal window hierarchy.

Also, the Composite/Damage way lets any existing X application be
smooth, not only new apps.

But its a very interesting idea.

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a witless devious sorceror who hangs with the wrong crowd. She's a 
high-kicking snooty bounty hunter from beyond the grave. They fight crime! 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]