Am Montag, 5. Juni 2006 15:38 schrieb Martin Konopka:
> When dynamic word wrap is turned on in Kate, text input gets extremely slow
> when the paragraph gets longer


I can confirm that. In KDE 3.5.3 dynamic word wrap causes kate's rendering and 
text input to degrade severely. I've noticed it using the LaTeX-highlighter 
as LaTeX-documents can get quite long dynamically wrapped paragraphs.

I investigated the issue and found the culprit to be within

void KateRenderer::paintTextLine(QPainter& paint, const KateLineRange* range, 
in


Here, only for the first visual line the painting of individual characters is 
coalesced (therefore, it's fast if dynamic word wrap is switched off as there 
is only one visible line).

For all other visual lines, QPainter::drawText (located at // Here's where the 
money is...) is called individually for *every single* character, thus 
killing performance.

I don't know what's causing this, but it may give you devs some hint.

SVN commit 549739 by savernik:

- Fixed slow repaints of dynamically wrapped lines.
- Also optimised calculation of KateTextLine::cursorX.

Reviewed by Dominik Haumann.

BUG: 128690


 M  +3 -2      katerenderer.cpp  
 M  +3 -2      katetextline.cpp  


--- branches/KDE/3.5/kdelibs/kate/part/katerenderer.cpp #549738:549739
@@ -425,7 +425,8 @@
     while (curCol - startcol < len)
     {
       // make sure curPos is updated correctly.
-      Q_ASSERT(curPos == textLine->cursorX(curCol, m_tabWidth));
+      // ### if uncommented, causes an O(n^2) behaviour
+      //Q_ASSERT(curPos == textLine->cursorX(curCol, m_tabWidth));
 
       QChar curChar = textLine->string()[curCol];
       // Decide if this character is a tab - we treat the spacing differently
@@ -497,7 +498,7 @@
           || (superRanges.count() && superRanges.currentBoundary() && *(superRanges.currentBoundary()) == KateTextCursor(line, nextCol))
 
           // it is the end of the line OR
-          || (curCol >= len - 1)
+          || (curCol - startcol >= len - 1)
 
           // the rest of the line is trailing whitespace OR
           || (curCol + 1 >= trailingWhitespaceColumn)
--- branches/KDE/3.5/kdelibs/kate/part/katetextline.cpp #549738:549739
@@ -209,9 +209,10 @@
 {
   uint x = 0;
 
-  for ( uint z = 0; z < kMin (pos, m_text.length()); z++)
+  const uint n = kMin (pos, m_text.length());
+  for ( uint z = 0; z < n; z++)
   {
-    if (m_text[z] == QChar('\t'))
+    if (m_text.unicode()[z] == QChar('\t'))
       x += tabChars - (x % tabChars);
     else
       x++;

This is btw a dupe of bug #64569

SVN commit 549908 by kling:

Further optimization of KateTextLine::cursorX()
callgrind reports "inclusive cost" down from 25% to 0.3% when scrolling through planetkde.org HTML.

CCBUG: 128690


 M  +3 -1      katetextline.cpp  


--- branches/KDE/3.5/kdelibs/kate/part/katetextline.cpp #549907:549908
@@ -210,9 +210,11 @@
   uint x = 0;
 
   const uint n = kMin (pos, m_text.length());
+  const QChar *unicode = m_text.unicode();
+  const QChar tab('\t');
   for ( uint z = 0; z < n; z++)
   {
-    if (m_text.unicode()[z] == QChar('\t'))
+    if (unicode[z] == tab)
       x += tabChars - (x % tabChars);
     else
       x++;

SVN commit 550220 by kling:

Don't memset() from the current item to end-of-line when setting highlight attributes.
End-of-item will do just fine, and now we get 31kB worth of memset() instead of 260MB
when inserting one character in the osnews.com HTML source.

CCBUG: 128690


 M  +1 -1      katehighlight.cpp  


--- branches/KDE/3.5/kdelibs/kate/part/katehighlight.cpp #550219:550220
@@ -1522,7 +1522,7 @@
         // even set attributes ;)
         memset ( textLine->attributes()+offset
                , item->onlyConsume ? context->attr : item->attr
-               , len-offset);
+               , offset2-offset);
 
         offset = offset2;
         lastChar = text[offset-1];

Am Samstag, 10. Juni 2006 11:26 schrieb Dominik Haumann:
> This is btw a dupe of bug #64569


I don't think so. bug 64569 is about slow syntax hl irrespective of wrapping, 
this one about slow painting of dynamically wrapped lines (hl'd or not).

Ok, you are right, the symptoms are quite the same, though :)

just for info: fix already in trunk, in slightly different version ;)

This bug is still present in 

kile 
Version 2.0.81
Using KDE 4.2.2 (KDE 4.2.2)

If I keep dynamic word wrap enabled, cursor movement, editing and anything related is unbearably slow. If I disable dynamic word wrap everything is normal again. Notice that there are two places where I can enable or disable seemingly two different notions of "dynamic word wrapping": in the main menu (view) or in the configuration, under the editor settings. The latter has no effect, only the former works and makes things slow. 

Resorting to static word wrap for now, but it has drawbacks.