Re: About gtk/cairo integration.

[Jost Boekemeier <jost2345 yahoo de>]

> Not exposing cairo_t to the user means not using
> Cairo except as an implementation detail... 

Yes, if we wrap the library, we need to create our own
documentation.  But this would not be difficult, a
simple shell script could do it.

The only additional call that our wrapper must support
above cairo the cairo API would be: 

 GdkDrawingContext *getDrawingContext(bool retained);

The DrawingContext would wrap cairo_t and either draw
immediately or lazy.
 

> As far as I know, the point where tesselation occurs
> in Cairo is basically an implementation choice. 

I think cairo doesn't have the necessary information
anymore--one could add a cairo_set_viewport(x,y,w,h),
though.

For example if gtk creates a 10000x10000 surface, it
is obvious for us that only a small set of objects
need to be drawn.  But this is something that cairo
doesn't know, the user could as well scale down the
drawing and blend it onto another surface.  So in the
general case cairo _must_ create the huge surface on
the server-side and then apply the appropriate
transformations.


> A surface that retained a scene
> graph could be added without any fundamental changes
> in the Cairo API.

Maybe.  But afaik cairo is only a drawing API for
direct drawing.  If one wants more, for example
animations or retained rendering, I think this must be
done on a level above cairo.

Btw: Hardware animations are also desirable, but this
must be a separate X11 extension which operates on the
state created by cairo over a time line.


> Not sure what you are referring to with GtkViewPort
> children

Gtk currently supports server-side scrolling ("guffaw
scrolling").  Unfortunately this is only half
implemented: A 10000x10000 child will create a X
window of that size.  This is a real problem for some
apps, for example the gnome PDF viewer might crash the
X server when you zoom to 800% (or so).

> you
> probably don't want to have a viewport with a
> million GtkWidget
> descendants but that has nothing to do with
> rendering, just
> with per-GtkWidget overhead.

The problem are the server-side objects (cairo_surface
or X windows) that are created too early.

I think server-objects should never be larger than the
physical screen (or 4 times larger, if you want
server-side scrolling).


> You are referring to the call in the realize()
> method? That's a
> hack 

Yes, but a convenient hack -- convenient for the
programmer at least. :)


Jost
 


	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de