Helge Hafting ha scritto:
6) I said that already but there's a number of optimisation that are
gone now because you basically do a full screen update at each
operation.
Please, note that the updateFlags are still correctly produced by the
various
(quite obscure) code segments around. Except that they are ignored at the
final rendering time. Actually, I didn't like the fact that, in the
current trunk,
AFAICU,
the ViewMetricsInfo object is used, in the BufferView, as a kind of
"reminder"
of what needs to be refreshed. Then, in response to the same "request"
(should be buffer_.changed()), the textMetrics.draw()
method either draws the entire screen or just a paragraph depending on such
"reminder".
My next step would just be to rely on different signals, in the framework:
-) one for updating the entire screen as a result of view-specific
events, such
as changing the anchor (i.e. scrolling), the zoom factor, what you
see or hide,
etc... -- this process should theoretically not interest the buffer
anyway
-) one for updating a single paragraph as a result of changing its contents
(e.g. when you type characters) -- this should also trigger a redraw
from the
paragraph to the bottom if the height changes, of if neighbour paragraphs
are affected as well (e.g. hitting enter to split a par into two) -- this
process should probably start from the buffer itself, that should
trigger a
paragraph refresh of (all) the view(s) showing that buffer.
This would eliminate the slowness (re)introduced by the current patch.
I have had much trouble with performance. Still, I think that
correctness is more important than performance. And the scrolling
anomalies have been bad in some cases, especially short/medium
sized documents containing big objects like full-page images.
So correct scrolling beats fast but erratic scrolling. Still, I hope the
optimizations comes back after a while. :-)
Yes, this is the plan.
T.
