Re: canvas/pango/text

[Paul Davis <paul linuxaudiosystems com>]

>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