Re: Building multiple backends on on same system

On Mon, 2010-12-06 at 16:17 +0000, Benjamin Otte wrote:
> Alexander Larsson <alexl <at>> writes:
> > Support specifying multiple targets in --with-gdktarget, then build a
> > single supporting all of these, switching at runtime. At
> > one time i was thinking we could load the backends dynamically to avoid
> > linking to all the dependencies of all backends, but since cairo links
> > in all backends in the same library anyway this will not work.
> > 
> I suppose you're targetting something similar to Cairo? So that you can query 
> the backend of a GdkWindow or GdkVisual or GdkDisplay at runtime? And when 
> starting the application you pick a certain default backend?


> > We then have a gtk+-3.0.pc file that does not pull in any backend
> > libraries (like xlib) into the app. The we add e.g. gtk+-x11-3.0 that
> > contains the backend specific headers like gdkx.h, the backend libraries
> > and headers. This file would be installed only if gtk+ was built with X
> > support of course.
> > 
> or we'd do it like Cairo and uild all of them into But that's a 
> detail I don't particularly care about. The only important thing is that 
> libgtk knows what the default backend to is and has a way to use it.

This is exactly how i meant. Maybe i described it poorly. gtk+-x11-3.0
will only contain gdk/gdkx.h and the set of -L/usr/X11/inclue -lX11 type
of flags.

> > Then we take the current internal defines like GDK_WINDOWING_X11 and put
> > the supported ones in a public header, so that apps can build
> > conditional backend support. Additionally we now allow multiple of these
> > to be defined in the same build.
> > 
> > Then we add a GdkBackend type that each backend implements. This is a
> > singleton created at init to hang global stuff off. Its also useful for
> > backend specific code. For instance:
> > 
> > #ifdef GDK_WINDOWING_X11
> >   if (timestamp != GDK_CURRENT_TIME)
> >     gdk_x11_window_set_user_time (gdk_window, timestamp);
> > #endif
> > 
> > Will turn into:
> > 
> > #ifdef GDK_WINDOWING_X11
> >    if (GDK_IS_BACKEND_X11 (gdk_backend_get ()))
> >      {
> >       if (timestamp != GDK_CURRENT_TIME)
> > 	gdk_x11_window_set_user_time (gdk_window, timestamp);
> >      }
> > #endif
> > 
> I would make that part of the GdkDisplay, as that pretty much is our 
> current singleton. So you'd do something like:
> #ifdef GDK_WINDOWING_X11
>   if (GDK_IS_X11_DISPLAY (display))
>     {
>       if (timestamp != GDK_CURRENT_TIME)
>         gdk_x11_window_set_user_time (gdk_window, timestamp);
>     }
> #endif

You can of course check on the type of anything, like the display or a
window. However, sometimes there might be no display availible, like if
its not been opened yet.

> > Additionally, I think we should drop and just combine the two
> > into one. There are no users of gdk without gtk anyway, and gtk has
> > backend specific code in it anyway, so gdk is not a full abstraction.
> > This will get us one less library, plus it will make all gdk calls from
> > gtk+ intra-object calls which is a (minor) performance gain.
> > 
> I do like the split conceptually, because it forces us to define a sane 
> interface between GTK and the backends. But I guess as long as we keep 
> stuff in seperate directories and make sure to not let GTK use private APIs 
> (as it currently does in the configure event trickery ;)) we'll be fine and 
> it doesn't matter if we use noinst_LTLIBRIRES or lib_LTLIBRARIES for libgdk.

We already have some _libgtk_only gdk symbols... But, i don't mean to
drop the distinction in the implementation, just not force the overhead
of it on the user.

> > * Convert all backend object method calls to true vtable calls, rather
> > than have the linker pick the right one. (For instance,
> > gdk_device_ungrab() is right now duplicated in each backend, and relies
> > on the linker to pick the one from the backend you link with. Obviously
> > this will not work in a multi-backend scenario, instead we need a single
> > gdk_device_ungrab() call in the common code that does a vcall on the
> > GdkDevice class.)
> > 
> I somewhat disagree on this one. At least in the case of GdkWindow do we have 
> a sane abstraction in the form of GdkWindowImpl already that we can put into 
> the backend. So making all GdkWindow APIs vfuncs doesn't sound like that 
> awesome of an idea to me. For most the other types, we need to add more vfuncs 
> though.

Yes, obviously on the GdkWindow case we use the Impl (and the code in
the branch already does this). However, for the other types we use the
normal class.

> > * Convert GdkCursor to a GObject so we get a class vtable
> > 
> That should have been done ages ago. Will do that now.

Where are you commiting this? The gdk-backend branch?

> > * (Optionally) move code common to all backends (for instance,  
> >   typechecks, etc) from the backend code to the common code that does
> >   the vtable call.
> >
> I'd go the other way and move code into backends only when it can't stay in 
> the core implementation. Otherwise we'll end up with lots of duplications 
> again. And I just worked hard to get rid of that...

Obviously we should not add new code in multiple places. I was talking
about the exisiting code that was already duplicated and could (with a
bunch of work) be combined back into the new shared code. However, this
is optional in the sense that it could be done later.

> > * Add a GdkBackend type, derive from this in all backends
> > 
> See my comment above about using GdkDisplay for that.

This is not right at all. There can be zero or multiple display objects
in any single gtk+ app.

> > * Convert all global functions (both external and gdk internal ones) in
> >   the backend to vtable calls on the backend object.
> > 
> Do we have lots of those? I mean functions that differ between backends and 
> don't take some sort of GObject as an argument? Could we hang them off 
> GdkDisplay?

Yes, there are many. Let me enumerate some:

etc, etc

> Also, do you target this for 3.0? Because I don't think it's doable in an 
> API-stable way during 3.x?

What API changes do you envision? I expect this to be both API and ABI

 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an uncontrollable moralistic master criminal for the 21st century. She's 
a foxy green-skinned mermaid from the wrong side of the tracks. They fight 

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