Re: canvas/pango/text
- From: Havoc Pennington <hp redhat com>
- To: Paul Davis <paul linuxaudiosystems com>
- Cc: gtk-list gnome org
- Subject: Re: canvas/pango/text
- Date: Tue, 4 Feb 2003 17:51:49 -0500
On Mon, Feb 03, 2003 at 02:11:54PM -0500, Paul Davis wrote:
> 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?
I think it's still similar on that level. The big change is just to
derive everything from the Shape object. Also, I don't think
libgnomecanvas2 really works right with GTK 2 (doesn't use the
built-in scrolling/backing-store). Someone might have fixed that last
thing though.
> >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?
If you just draw glyphs a la gdk_draw_string(), then i18n is broken
but it's probably fast enough. If you go through PangoLayout most
likely it's slower than you want. Not because of faults in
PangoLayout, just because the fully-i18n-correct algorithms are
inherently slower than just mapping 1 char to 1 glyph.
Most code can be rewritten somehow to allow for the extra time for
i18n, but it can be a lot of work.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]