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 hack 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. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part