>Assuming you mean for the "antialiased" canvas? The whole AA canvas is >kind of hosed in libgnomecanvas 2, in fact a lot of people decided it >was a plain old bad idea and created a "foocanvas" module in CVS which >is sort of a revert of the canvas back to its pre-AA-mode days, then >nuking the canvas's dedicated scrolling and backing store in favor of >using GTK 2's built-in stuff. Gnumeric, Nautilus, etc. are now using >foocanvas.
oh my. what a disaster. the non-AA canvas is more or less useless from my point of view. i need the primitives offered by libart, plus my own canvas items that are specifically designed to do client-side rendering, not gdk-level draw operations. >Someone sort of half-rewrote all the AA stuff in libgnomecanvas 2 to >be based on some sort of generic GnomeCanvasShape and it is kind of >buggy as not much is using it. If you're relying on it what you may >want to do is take libgnomecanvas 1 and forward port to GTK 2, or at >least be prepared to do some fixage on libgnomecanvas 2. i'm using GtkCanvas (the backport of libgnomecanvas1 to GTK). i was planning on using Gnome::Canvas when we move to using gtkmm2. are the basics of canvas items still the same? ie. the whole "update/render" cycle? do they still get a nice little RGBA buffer to render themselves to? >However, on the plus side, yes client side text is much more >feasible/good these days. The ft2 Pango backend can render to a >client-side buffer. do you think its efficient? do you think it was engineered with the idea of doing things like rendering a few hundred small pieces of text all over the RGBA buffer? --p _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
