Tommaso Cucinotta wrote:
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,
Ideally, you don't update the entire screen on scrolling.
If the scroll is less than a screenfull, just let the windowing
system move the part that stays visible. And then you draw
only the exposed part. A nice speedup, especially when working
across the network.
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,
Ideally, paint only the single line containing the cursor, when the rest of
the paragraph stays unchanged. More important: Don't do a redraw to
the bottom, just move the stuff down and redraw the paragraph only.
So correct scrolling beats fast but erratic scrolling. Still, I hope the
optimizations comes back after a while. :-)
Yes, this is the plan.
Good to hear!
Helge Hafting
