Re: gdtk_draw_text deprecated , what use instead of it ?

[Havoc Pennington <hp redhat com>]

On Tue, 2003-12-30 at 18:31, Paul Pogonyshev wrote:
> I would like to see any comments from GTK+ developers on if there's any
> hope of seeing gdk_draw_text() to be resurrected.

You're missing the fundamental point about pango vs. gdk_draw_text().
gdk_draw_text() uses an _entirely different_ backend, the old X core
fonts, vs. Pango which uses a modern system with Unicode, antialiasing,
a *different list of available fonts*, and so forth. So what's really
deprecated is the broken old backend.

We could introduce a pango_draw_text() with an API similar to
gdk_draw_text(), but it would have to create a PangoLayout internally so
there's no efficiency gain, other than hiding the inefficiency from the
programmer. An equivalent to gdk_text_width() would also create the same
PangoLayout, etc. Very slow very quickly.

The reason PangoLayout exists is that it is in fact impossible to render
text correctly without the context of a full paragraph, assuming the
text can be in any language. If you know your text is always just "a",
"b", "c" then yes you could avoid PangoLayout. However, if there were a
non-layout API people would use it in a lot of cases where it would be
broken, and the layout API should work fine for what you're doing.
PangoLayout is also a cache for attributes of the text you're rendering,
so getting its width isn't creating a separate layout from drawing.

Basically the reason text rendering is more complicated in GTK+ 2 is
that text rendering _is_ complicated, and GTK+ 1.2 was broken because it
failed to handle many cases.

Havoc