Bug 90422

Summary:	konqueror is very slow on certain large web pages
Product:	[Applications] konqueror	Reporter:	Erik Schnetter <schnetter>
Component:	khtml	Assignee:	Konqueror Developers <konq-bugs>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	gerd, Maik.Zumstrull
Priority:	NOR
Version:	3.2.2
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Erik Schnetter 2004-09-28 20:44:51 UTC

Version:           3.2.2 (using KDE 3.2.3,  (testing/unstable))
Compiler:          gcc version 3.3.3 (Debian 20040422)
OS:                Linux (i686) release 2.6.7-1-686

Certain large web pages, e.g. for the Debian bug report 273219 "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273219", make konqueror "slow".  When I access this page, konqueror starts by displaying a few lines and then seems to hang, while the remainder of the large page is loaded.  Later, whenever a part of the screen has to be redrawn or when I scroll the page, Konqueror takes about four seconds (!) to do the redraw.  I haven't seen this for other pages.  Apart from having many lines, this page also seems to have some rather long lines.
(This page contains what seems to be the full screen output of a complete gcc bootstrap.)

Comment 1 Leo Savernik 2005-02-14 00:21:00 UTC

confirming. khtml has severe painting issues with long text runs.

Comment 2 Leo Savernik 2005-02-27 20:42:35 UTC

CVS commit by savernik: 

Heavy optimisation on painting large text runs.

This leads to a more than ten-fold increase on a 6mb <pre> element.

Text selection is still slow in this case, but an order of magnitudes better
than before.

BUG: 90422


  M +5 -0      ChangeLog   1.389
  M +7 -1      rendering/font.cpp   1.34
  M +2 -1      rendering/render_text.cpp   1.267


--- kdelibs/khtml/ChangeLog  #1.388:1.389
@@ -1,2 +1,7 @@
+2005-02-27  Leo Savernik  <l.savernik@aon.at>
+
+        * rendering/font.cpp (drawText): Only pass text from inline text box to
+        QPainter::drawText, not the whole RenderText's text.
+
 2005-02-27  Harri Porten  <porten@kde.org>
 

--- kdelibs/khtml/rendering/font.cpp  #1.33:1.34
@@ -105,5 +105,11 @@ void Font::drawText( QPainter *p, int x,
     if ( !scFont && !letterSpacing && !wordSpacing && !toAdd && from==-1 ) {
         // simply draw it
-        p->drawText( x, y, qstr, pos, len, d );
+        // Due to some unfounded cause QPainter::drawText traverses the
+        // *whole* string when painting, not only the specified
+        // [pos, pos + len) segment. This makes painting *extremely* slow for
+        // long render texts (in the order of several megabytes).
+        // Hence, only hand over the piece of text of the actual inline text box
+        QConstString cstr = QConstString(str + pos, len);
+        p->drawText( x, y, cstr.string(), 0, len, d );
     } else {
         if (from < 0) from = 0;

--- kdelibs/khtml/rendering/render_text.cpp  #1.266:1.267
@@ -137,5 +137,5 @@ void InlineTextBox::paintSelection(const
     p->setPen(hc);
 
-    //kdDebug( 6040 ) << "textRun::painting(" << QConstString(text->str->s + m_start, m_len).string() << ") at(" << m_x+tx << "/" << m_y+ty << ")" << endl;
+    //kdDebug( 6040 ) << "textRun::painting(" << QConstString(text->str->s + m_start, m_len).string().left(30) << ") at(" << m_x+tx << "/" << m_y+ty << ")" << endl;
     f->drawText(p, m_x + tx, m_y + ty + m_baseline, text->str->s, text->str->l,
                 m_start, m_len, m_toAdd,
@@ -946,4 +946,5 @@ void RenderText::paint( PaintInfo& pI, i
                         s->paintShadow(pI.p, font, tx, ty, _style->textShadow());
 #endif
+// kdDebug(6040) << QConstString(str->s + s->m_start, s->m_len).string().left(40) << endl;
                     font->drawText(pI.p, s->m_x + tx, s->m_y + ty + s->m_baseline, str->s, str->l, s->m_start, s->m_len,
                                    s->m_toAdd, s->m_reversed ? QPainter::RTL : QPainter::LTR);

Comment 3 Tommi Tervo 2005-03-05 16:04:33 UTC

*** Bug 100825 has been marked as a duplicate of this bug. ***

Comment 4 Tommi Tervo 2005-03-09 14:16:32 UTC

*** Bug 101175 has been marked as a duplicate of this bug. ***