Re: Possible Pango 1.4 ideas
- From: Joaquín Cuenca Abela <cuenca pacaterie u-psud fr>
- To: Damon Chaplin <damon karuna uklinux net>
- Cc: Havoc Pennington <hp redhat com>, Owen Taylor <otaylor redhat com>, gtk-i18n-list gnome org
- Subject: Re: Possible Pango 1.4 ideas
- Date: 22 Jan 2003 23:08:56 +0100
On Tue, 2003-01-21 at 03:23, Damon Chaplin wrote:
> On Mon, 2003-01-20 at 02:59, Havoc Pennington wrote:
> > On Sun, Jan 19, 2003 at 09:35:42PM -0500, Owen Taylor wrote:
> > > It looks like most of these items (except for Kerning) involve
> > > PangoLayout. I think one of the most basic things that will have
> > > to be dealt with is how to implement them and not turn PangoLayout
> > > from barely-maintainable to unmaintainable.
> >
> > Performance and memory usage also seems like an issue to me. We're
> > already sort of suboptimal here.
>
> I don't intend my layout code to be the default - most apps will
> continue to use the basic PangoLayout code. Only those apps that want
> more sophisticated text layout would switch on my code. (I don't want
to
> affect the reliability of current apps.)
>
> Fortunately the TeX algorithm is very nice, and fast. If it succeeds
in
> the first pass (without hyphenating), which it usually does if given a
> decent layout width, it is only about 10% slower than the current
code.
> It does use quite a bit of memory temporarily while it does the
layout,
> but I haven't optimized that yet.
>
>
> > You and Owen have probably looked at it more, but as someone who
used
> > to spent a lot of time with Quark and Pagemaker, those apps
certainly
> > seemed to have substantially more complex text handling than
> > PangoLayout does right now; even AbiWord does, doesn't it? I'm kind
of
> > skeptical that PangoLayout can handle their needs without becoming
> > noticeably higher-overhead and much harder to maintain (if only in
> > terms of sheer additional code size).
> >
> > But then, I realize that maintaining PangoSuperDuperLayout alongside
> > PangoLayout isn't really attractive either.
>
> I don't think Quark has that many more features. (My feature-list
> basically came from reading a book on Quark.) Besides, if we don't put
> it in Pango, then every app that wants decent text layout has to do it
> themselves, which is too hard for developers really.
Ok, but the point that Havoc raised is a valid one. The current layout
code looks[*] like really suboptimal performace wise. Did you got some
figures about the performance of PangoLayout (both, memory and time
wise)?
Btw, Damon, if you're planning to do a DTP, would you be interested in
sharing some code with AbiWord? a DTP and a wordprocessor don't have
exactly the same requeriments, what we should be close enough to be able
to share some code here and there.
If you're interested, did you have any thoughts on what data structure
do you want to use for your app? a gap buffer (I hope not...)? a
btree? a piece table?
If you choose the last one, I've worked on a little redesign of the
current abiword piece table (check
http://e98cuenc.free.fr/wordprocessor/piecetable.html). I'm still
optimizing it, but I think that it can yield good performance results.
Cheers,
[*] ie., I've not measured it, just seen GtkTextView in action... but I
don't how representative is GtkTextView
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]