[cairo] Porting GTK+ to use Cairo

[Owen Taylor]

On Tue, 2004-05-11 at 13:00, Jost Boekemeier wrote:
> Hi,
> 
> has someone experience porting a toolkit to use Cairo?

So, your project is to write a GTK+ backend that renders using Cairo?

The obvious problem here is that Cairo is just a rendering library; it
doesn't do window management, it doesn't do events. GTK+ needs to be
on top of a windowing system.

You could do something like the linux-fb backend where the windowing
system is implemented entirely inside the GDK layer, of course.  Or you
could implement your own windowing server.

[ ...subject goes pretty much offtopic for cairo ML at this point... ]

> * We could associate every container widget with a cairo surface. But
> this may not work very well at the moment: cairo does not optimize at
> all, so the picture that eventually gets send to the server will be
> quite large.
> 
> So I think currently it is best to forget about transparency etc.,
> render everything myself and use Cairo only to draw the visible surface
> of the widget hierarchy, yes?

Container widgets themselves have no representation at the GDK layer.
You probably want to look instead at GDK level objects like windows.
The simplest thing to do is to have a permanent buffer per GdkWindow - 
this makes window management a lot easier to implement.

> * If I understand Cairo correctly it renders all paths into trapezoids
> and sends them to the server. This low-level protocol makes sense, but
> doesn't it generate too much traffic? I fear that in the end we may get
> rid of the latency but we may still not be able to run a client via a
> e.g. 9600 baud connection because what we send is not much better than
> compressed delta images (VNC).

Trying to run a widget toolkit over a 9600 baud connection is going to
be iffy at the best of times. Especially since a 9600 baud connection 
typically has correspondingly large latencies. If you are constrained
to that small a network connection, a client/server architecture  with 
app code running on the client (which is the server in X terminology) is
likely going to work better. 

I don't think using trapezoids is going to be much worse than using
paths, though. Almost everything that GTK+ draws that isn't text or
an image is a rectangle, which is only one trapezoid anyways. 

> Maybe someone has benchmark results that compare VNC with cairo?

They aren't really comparable things. Apples and elephants.

> * There are other issues (text rendering, object embedding), but I guess
> I can ignore them for the moment.
> 
> * Not cairo related, but what do you think is the best way to route
> events to the widgets and to associate a cursor with each widget?  I
> think I need a "event grid" on the server-side, i.e. a grid composed of
> input-only windows.  Or are there cheaper structures available on the
> server side that provide such a functionality? But maybe this "event
> grid" is nonsense, see below.

Widgets are invisible to you (unlesss you are planning a rewrite
of GTK+ rather than a port of GTK+). You have to conform
to the GTK+ event model; you don't get a lot of flexibility here.

You do get to decide whether GdkWindows are server side objects
or client side only. My general guess these days is that we'd do better
with only toplevel windows represented on the server side, and
if I was reimplementing GTK+ on X, I'd probably do that.

> * gtk related: Why do most gtk widgets ask for pointer motion events?  I
> can understand why someone wants button[x] motion events but why does
> the menu or menuitem for example want motion events when no button is
> pressed?  I think the only reason is that X has no "pointer moved less
> than delta pixels, send tooltip event" so one has to implement this on
> the client-side.  Or are there other reasons?

For menus, it has to do with the exact algorithms GTK+ uses for deciding
when to pop down subwindows. 

Note that if you only put toplevel windows on the server, you need to
send all the motion events all the time. (And since latency is generally
your enemy, not bandwidth, this doesn't hurt much.)

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040511/7230e038/attachment.pgp