[compiz] core improvements

[David Reveman]

On Fri, 2007-09-07 at 17:11 -0400, Kristian Høgsberg wrote: 
> On 9/7/07, David Reveman <davidr at novell.com> wrote:
> ...
> > - Object model
> >
> > We need to easily be able to create new types of objects that plugins
> > can keep track of and add options to without breaking the API or even
> > the ABI.
> >
> > The initial part of this is already in head. The object system I've
> > added is very simple but still sufficient. It allows us to add new core
> > objects without having to update any plugins.
> >
> > Next step is to add an interface that will allow plugins to add their
> > own type of objects. This is a simple addition to the current object
> > system and you can expect it to land in head shortly.
> 
> I browsed the patch, and it look mostly good, but I wondered why you
> decided to go for a 'type' integer instead of the more custom 'class'
> pointer (or objectInfo pointer).  Then you could just do
> 
> char *
> compObjectName (CompObject *object)
> {
>  return (*nameObject->ObjectInfo) (object);
> }
> 
> and the CompObjectInfo structs can be static variables in the relevant
> files (screenObject info in screen.c etc) and the functions they point
> to can be static too.

Yes, I think we want that eventually. However, I currently use the type
integer as a dispatch table index in a lot of places (like the
initObject VTable functions) and some of the current objectInfo
functions need to be called without an instance of the object (e.g.
forEachObject).

The dispatch index can be avoided once we make all wrap-able functions
part of the object type. This is basically just the next step towards
more standard polymorphism.

I don't want to enforce a specific data type for keeping track of
objects. The forEachObject function solves that but it can simple be
moved into the object type vtable instead. Same thing for the findObject
function.

I'll try to come up with a step by step plan for how we accomplish this
and send it to the list sometime soon...

> 
> > TODO
> >
> > - Matching interface
> >
> > The matching interface should be updated to work with all kinds of
> > objects and not only window objects. This should be easy to get done as
> > I had something like this in mind when I first implemented the matching
> > system.
> >
> >
> > - Replace the option system
> >
> > This sounds like more work than what it is. All I want to do is rename
> > existing options to properties and add methods and signals. A property
> > will be pretty much exactly the same thing as an option is today except
> > that there's not going to be an action property. A method will be
> > similar to what an action option is today but it will include a
> > signature and the initiate/terminate bs ripped out.
> >
> > What options provide today is really just a IPC mechanism. D-BUS got a
> > very good model for this and I'd like to adjust compiz so it matches
> > that model as much as possible.
> 
> Sounds cool.
> 
> > - Output plugin support
> >
> > The actual rendering should be separated from the core. Most of the
> > current rendering code will be moved into a GL output plugin. Multiple
> > output plugins can be active at the same time and they shouldn't
> > necessarily have to be drawing to the screen. E.g. the screenshot plugin
> > will be an output plugin that render to a file instead of the screen. An
> > xrender output plugin could easily be created. However, some of the
> > existing plugins will rely on the GL output plugin, e.g. blur and video
> > plugins.
> 
> Interesting.  Where do you see this going?  What's the motivation for
> supporting other output methods?

There's a few things that we like to accomplish.

Some people have asked for xrender output support. These changes would
allow that to be implemented even though some of the more impressive
plugins are not going to work without GL. This might not make a lot of
sense for the regular desktop machine but for some remote composited X
situations (I'll talk about this at XDS) it can make a lot of sense.

It allows me to integrate the remote composited X experiments I've been
playing with properly.

Would make it very easy to support AGL, WGL if desired. It even be
possible to support Direct3D.

It would also provide a well defined way for screen capturing,
printing..

-David