Re: [scintilla] Pango support on GTK+ 2.x
- From: Owen Taylor <otaylor redhat com>
- To: Neil Hodgson <nhodgson bigpond net au>
- Cc: Havoc Pennington <hp redhat com>, Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>, Scintilla Interest <scintilla-interest lyra org>, GTK Devel <gtk-devel-list gnome org>
- Subject: Re: [scintilla] Pango support on GTK+ 2.x
- Date: 10 Mar 2003 16:50:03 -0500
On Mon, 2003-03-10 at 16:20, Neil Hodgson wrote:
> Owen Taylor:
>
> > - I'm not sure it will be faster currently, but I'd definitely
> > suggest using one layout per line and setting color attributes
> > on ranges.
>
> That turned out to be slightly (~5%) slower. Possibly it was the extra
> allocation and setup of a font description and colour attribute for each
> run.
I'm not completely surprised that it's a little slower ... but that
can, to some extent, be optimized in Pango, and by not hiding
information from Pango/GDK
- The rendering will be better
- GDK can (in the future anyways) be smarter about how it's drawing
colors - reusing GC's as appropriate, etc.
> > - Is the problem layout speed or rendering speed? I'd guess that
> > scintilla can assume constant-height-lines, but perhaps
> > it still needs to go over the entire file to deal with
> > line widths. (or if there is wrapping involved)
>
> Layout speed appears the big problem. Scintilla performs two runs over
> text to be displayed, the first to measure the text and the second to render
> the text. The measurement is required to perform wrapping as you say. The
> results of the measurement are placed in a 'line layout' cache so most
> editing can use the previously calculated positions. My tests here have
> mostly been with maximum caching turned on but without wrapping. The
> measurement is lazy and normally only occurs when a line needs to be
> measured for display. Wrapping often requires measuring the whole file.
> There is certainly a cost to performing the layout twice and I could attempt
> to defer position calculations under some conditions to render time.
For GtkTextView, we went with the philosophy:
If we can't do one screenful of layout fast enough for rendering,
we aren't going to be able do the entire buffer fast enough
to set up the scrollbars in a useful amount of time.
And it's seemed to work pretty well.
The only things that are cached are:
- The size (width x height) of each paragraph in the buffer.
- A single PangoLayout (and associated information) for the
last paragraph laid out. This helps for things like moving
a cursor around a paragraph where the same paragraph is
accessed repeatedly.
It's not really clear to me how you can defer measuring lines
until a line is displayed, even if you base your scrollbar
on lines rather than pixels. How do you handle the horizontal
scrollbar?
> > - It takes GtkTextView around 1.5s to lay out a 11,000 line
> > source file on 1 ghz machine.
>
> My result was a 190K, 6000 line source code file taking about 8 seconds
> to completely lay out on a 600MHz Athlon running RedHat 8.0 with its default
> GTK+, X and font system.
Please do try Pango CVS, it really has quite different performance
characteristics, it's really hard to speak meaningfully about older
versions at this point.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]