On Mon, 2004-07-12 at 12:29, Jost Boekemeier wrote:
> > 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.
If we need retained mode capabilities that are closely
tied to the rendering API, that should be done as part
of the Cairo project.
If the retained mode capabilities we need can be cleanly
layered on top of the rendering API, then we can layer
them on top and still expose cairo directly as an
immediate mode API.
> > 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.
I don't think you need such an addiition: the way I'd
envision it working is that you just use cairo's
current clipping facilities when doing cairo_show_surface()
from a retained mode surface to an immediate mode surface
and the retained mode surface lazily renders the appropriate
part.
[...]
> > 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.
The Cairo maintainers have expressed a willingness
to consider adding bits of retained mode behavior to
Cairo - whether display lists or retained mode surfaces -
*if* that proves necessary once people get some experience
writing apps with Cairo.
What cairo definitely isn't is an API for creating
manipulatable 2D scene graphs. And I don't think GDK's
drawing interfaces should be that either.
A canvas like GnomeCanvas may be an interesting thing
to add to GTK+, but I think the right interface for such
a canvas looks a lot like GnomeCanvas - a tree of GObjects
with properties that know how to draw themselves.
> 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.
I'm not even sure longhorn does incremental modification
of retained mode scene graphs for animation. I'm much less
sure that doing so is desirable or necessary.
> > 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).
If creating a 10000x10000 window crashes your X server,
get a better X server.
> > 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).
There is no reason server side objects need storage that is
proportional to the number of pixels in the object.
> > 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. :)
Sorry, I forgot to finish the sentence... it's a hack
related to an old and no-longer used bit of the theme
API. Soeren's recent changes to unset backgrounds
temporarily on map are a much better way of dealing
with avoiding an initial flash when mapping windows.
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part