Re: About gtk/cairo integration.

On Sun, 2004-07-11 at 08:02, Jost Boekemeier wrote:
> Hi,
> there seems to be a consensus that the integration of cairo should
> expose cairo_t to the users.

Not exposing cairo_t to the user means not using Cairo except 
as an implementation detail... I'd really like to avoid maintaining
our own rendering API.

> The problem with this is that once you expose cairo_t, you don't have
> the chance to allow retained mode rendering in future versions of
> gtk/gdk: In cairo the tesselation of shapes into low-level trapezoids
> occurs early; because of this cairo surfaces cannot be used to hold a
> "szene graph" much larger than the physical screen, they consume too
> much memory (same problem that we have with huge gtkviewport childs
> today).

As far as I know, the point where tesselation occurs in Cairo is
basically an implementation choice. A surface that retained a scene
graph could be added without any fundamental changes in the Cairo API.

Not sure what you are referring to with GtkViewPort children; 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.

> Some gtk widgets (at least gtkviewport in 2.2.4) already draw directly
> to their window outside the widget_paint() callback.  Although this may
> be a bug at the moment, I think a future version of gtk should allow
> retained mode rendering.

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

Or are you referring to the expose/paint split with painting done
in both? Note that this split has nothing to do with the proposed
new paint() virtual function in my proposal, it's just the way
that the GtkViewport code ended up.


Attachment: signature.asc
Description: This is a digitally signed message part

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