Re: writing a text widget with pango

[Havoc Pennington <hp redhat com>]

Peter Zelezny <pzel dodo com au> writes: 
> The only reason I went to line-by-line, was so that I could chop the top
> few lines off, if the scrollbar was in that position. I guess I could render
> the whole Layout a few pixels off the top of the window? Either that, or
> do my own CENTER/RIGHT calculations (which are simple enough).

Yes, what I'd do is just draw the layout at negative coordinates, it
will be clipped to the window, works great.
 
> I thought keeping PangoLayouts around was the fastest way to go.

It probably is, but the memory footprint is most likely unacceptable.
As long as you have only tens of layouts onscreen at once, it should
be fine to create them on-demand. Or at least just keep a limited-size
cache.
 
> > One thing we're considering for GTK 2.2 is to put back a simple
> > draw-string API like gdk_draw_string and gdk_text_width(), for use by
> > terminal widgets and that sort of thing. Would probably make porting
> > XChat a lot easier. But of course using this API means you don't have
> > i18n quite working.
> >
> > Havoc
>
> Well it would be better if I could render utf-8 directly (through pango).

That's what I mean, a Pango API with pango_font_get_char_width() and
pango_font_draw_string() or whatever. The problem is that you don't
go through pango_shape(), instead you always draw one glyph for one
character and always draw the glyphs in the same order as the
characters. Which is wrong in some scripts/languages.

(One big reason Pango is slower than gdk_draw_text(), and also harder
to use, is that it breaks these two assumptions about char/glyph
ordering being the same, and char/glyph mapping being one-to-one, in
order to get i18n correct. The idea of providing an API that maintains
those two assumptions is to make it easier to port to Pango when you
can't realistically fix an entire app to work properly.)

Havoc