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: David Ramsey
Subject: Re: [Nano-devel] Port of variable-length chunks to 2.8.2
Date: Sun, 7 May 2017 16:12:31 -0500

On Sun, May 7, 2017 at 10:48 AM, Benno Schulenberg
<address@hidden> wrote:
> No need -- I've managed to do a rebase.

Good to know.

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

Agreed.  At the moment, this is more of a proof of concept to verify
that it can work.  It can certainly be improved performance-wise.

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

That's also good to know, although you understand the painting code
better than I do.

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

I thought of that, but the problem there is implementation.  Text gets
added or deleted in various functions all over the code, some via
linestruct operations, some via ad hoc operations.  Putting hooks
everywhere those things happen will be much more complex.  There will
probably have to be add_text() and remove_text() wrappers used all over
the code instead of what there is now.

And caching only what's onscreen will have to be done before things are
displayed, or we'll end up with the same problem that Mark Majeres'
patch set had when it cached as part of display_string(): as soon as you
do so much as scroll down past the bottom line of the screen, things
will malfunction because the new line hasn't been displayed yet.



reply via email to

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