nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] Port of variable-length chunks to 2.8.2


From: Benno Schulenberg
Subject: Re: [Nano-devel] Port of variable-length chunks to 2.8.2
Date: Sun, 07 May 2017 17:48:31 +0200

On Fri, May 5, 2017, at 23:20, David Ramsey wrote:
> On Fri, May 5, 2017 at 2:33 PM, Benno Schulenberg
> <address@hidden> wrote:
> > I will look at the patch set next week.
> 
> Thank you.  Although the recent git changes break it a bit; I can send
> an updated version if need be.

No need -- I've managed to do a rebase.

> > But first something that has bothered me for at least two months.
> > Whenever update_line() is called in softwrap mode, the subsequent call
> > to update_softwrapped_line() figures out /every time/ on which row to
> > start drawing this line, involving a strlenpt() call on each visible
> > preceding line.
> 
> Good point.  I'll look into it soon.
> 
> On a similar note, this patch set slows things down further, because
> scanning the line to figure out where to break it takes longer.

Yes, that is the main reason why I am reluctant to even look
at the patch set.  Softwrap is already slow, and this will only
make it slower.  If we can first significantly speed up the current
implementation, then we'll have some room to let it get slower
again.

I've looked at the insides of an .odt file recently.  The XML files
it contains each consist of one extremely long line.  When opening
a content.xml of ten kilobytes, it takes nearly forty seconds before
the text is finally displayed.  But this is almost entirely because
of syntax coloring: when using -Ynone, it opens in half a second.
So, there is room for improvement also in the painting code.

> scanning from a chunk after the first one involves starting from the
> beginning of the line and parsing it from there to the starting column
> of that chunk.  This is also wasteful, but given the discrepancy between
> columns and indexes, I can't think of a better way that doesn't involve
> caching information about every line,

Wouldn't it be enough to cache things per screen row?  Whenever
edittop or firstcolumn changes, or data is inserted or deleted,
first recompute this "cache" and then you can redraw any row
without needing to do any more parsing.

Benno

-- 
http://www.fastmail.com - Choose from over 50 domains or use your own




reply via email to

[Prev in Thread] Current Thread [Next in Thread]