Le 08/12/2016 à 23:18, Tommaso Cucinotta a écrit :
likely with this sequel [1], so the innermost LyX code seems:
lyx::frontend::GuiFontMetrics::breakAt,lyx::Row::Element::breakAt,
lyx::Row::shortenIfNeeded,lyx::TextMetrics::breakRow,lyx::TextMetrics::redoParagraph,
breakAt is the main method for which caching is added in my patch.
Now, I'm just moving the cursor and sometimes selecting with Shift down,
so do we actually need to redoParagraph() ?
This is an excellent question :) The problem is that this update code is
very cery fragile. I have tried in the past to streamline
BufferView::processUpdateFlags and BufferView::draw without much
success. There are always cases where metrics are lost for some reason.
You can read development/PAINTING_ANALYSIS for some of my thoughts on
the subject.
One thing I have been working towards is separating computation of
metrics and inset positions, from drawing itself. This would have the
obvious advantage to allow painting to happen at redraw events (or
whatever they are called), like any normal application does.
However, I realize now that my assumption that painting is more
expensive than metrics is not correct, especially now that we use
QTextLayout to do the glyph combination for us. It might be that we
should be at a lower level and leverage harfbuzz (or whatever thing I do
not know) to this line breaking and cursor positioning job. I do not
know what is the extra amount of work that is done by QTextLayout and
that we do not really need. Note though that with my patch we directly
draw the cached QTextLayout object.
And of course, the second work is to reduce the amount of metrics
computation and of painting that happens. This is a pretty difficult
job, especially since the code is peppered with random buffer.changed()
calls (which force a redraw and/or metrics computation) which have been
added for some forgotten reason, probably that it was easier than just
thinking about what we were doing.
JMarc
