Re: writing a text widget with pango

[Peter Zelezny <pzel dodo com au>]

On 22 May 2002 15:48:00 -0400
Havoc Pennington <hp redhat com> wrote:

> > Rendering it line-by-line ignores the alignment setting
> > (PANGO_ALIGN_CENTER/PANGO_ALIGN_RIGHT). Is this intentional?
>
> Yes. The layout lays out the lines. Note that a layout is intended to
> be a paragraph, and a line in this context is a line created by line
> wrapping. (Though you can put \n in PangoLayout to allow multiple
> paragraphs in a layout, and that works fine, it doesn't scale to very
> many paragraphs. \n is a paragraph delimiter rather than a line
> delimiter in this context.)

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).


> TextView scrolling is pixel-based rather than line-based (a change
> from the Tk widget it's based on, which was line-based). But the way
> it works is that there's an enormously complicated BTree data
> structure, and one of the things it does is that it maps from pixel
> positions to paragraphs. I'm pretty sure you want to do something
> simpler than what TextView does.
>
> You could probably just get away with a list of one node per
> paragraph, where each node caches the pixel height of the paragraph,
> or number of lines in it.

That's kind of what I do, except I also keep the Layouts alive for each
paragraph. Line-based is fine. A pixel offset can then be added by simply
using the decimal part of the adjustment->value * line_height, that "feels"
smooth enough (xchat 1.8 does this).


> You most likely _don't_ want to keep a
> PangoLayout around for each paragraph, just calculate them as-needed
> for the paragraphs that are actually on the screen.
>
> Then you could move to incremental layout fairly easily, essentially
> incremental means you always compute the onscreen sizes immediately,
> assuming all other sizes are 0, in an idle handler you replace some 0
> sizes with the actual sizes and update the scrolling accordingly.
>
> > 4) Is pango_layout_line_get_pixel_extents cheap or should I cache
> > it?
>
> It's medium. I'd only cache it if you get it to show up in a profile
> once you have things working well. You probably don't want to keep
> PangoLayout objects around, so creating those will overshadow the cost
> of the pixel extents computation.

I thought keeping PangoLayouts around was the fastest way to go. If I just
create one each time I need to render a paragraph, wouldn't I lose alot of
the information Layouts could (do?) store internally, like wrap calculations
with the current fontdescription etc? That is, when I redraw after a scroll,
not a resize.

Looking at the PangoLayout struct, I realize this is probably too big to
keep around for each paragraph.


> > 5) In this new GTK2.0/double-buffer world, is it quicker to set your
> >    GdkWindow background color, or use a 'None' backing pixmap?
>
> Neither is faster I don't think, you'd normally want to avoid None
> just because it creates weird visual effects.

Right, especially when deiconifying.


> 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).

Thanks for the help.

-- 
Peter Zelezny.