Helge Hafting wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Helge Hafting wrote:
Arrange one paragraph with 25 lines.
Type a string og W's in the next paragraph. The W's comes out with
great speed until this second paragraph needs to linewrap. The wrap
takes a "long" time, and then things continue at great speed. The
linewrap
is noticeable, and lyx -dbg prints this at that point:
I know that but this behaves the same as in 1.4 and 1.5: When a
paragraph dimension is changed we update the full screen. Are you
sure that 1.6 is slower in that respect?
The current and the previous paragraph is 27 lines, and here we see
27 {10}'s, and they appear twice too.
The fact that 27 lines appears does not necessarily mean that they
are drawn on screen. Actually only those line that are within the
work area are drawn but I am going to check that this is really the
case.
Yep, I verified that and I've added an additional field to indicate
the drawing status '-dbg painting'. {xyz} now means:
x: 1 if the row painting is really done, 0 if the painter has been
disabled (so called 'null-painter') because the row is off-screen.
y: 1 if a full redraw has been asked.
z: 1 if the row has really changed.
You will notice that sometimes y == 1 (full redraw) and z == 0 (the
row has not changed), this means that we could avoid this row
painting. This is kind of optimization that will be possible in the
future but we are still not fully ready for that.
So something as simple as
if (y==1 && z==0) return;
is not going to work yet, or you'd done it already.
Right. But we are not very far.
Abdel.
