Bug 169549 - Poor performance with long lines
Summary: Poor performance with long lines
Status: RESOLVED DUPLICATE of bug 225228
Alias: None
Product: kate
Classification: Applications
Component: part (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 170322 177773 180850 189787 191467 195971 200049 200707 210464 222437 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-08-21 21:34 UTC by Bram Schoenmakers
Modified: 2010-03-23 13:59 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Page source of Google News, making Katepart slow (202.62 KB, text/plain)
2008-08-21 21:36 UTC, Bram Schoenmakers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bram Schoenmakers 2008-08-21 21:34:48 UTC
Version:            (using KDE 4.1.0)
Compiler:          gcc 4.1.2 
OS:                Linux
Installed from:    Compiled From Sources

When the attached HTML file is opened, it takes a long time to render the document. On a another PC it appeared immediately though, but KWrite gets very busy when I try to find a word in it. For example: hit Ctrl+F and enter the characters f l and a. After pressing a CPU usage will rise and after a while it becomes calm again with 'fla' highlighted somewhere.

Here's a backtrace while KWrite was processing my search:

#0  0xb6b5da1b in stringToGlyphs (item=0xbff53628, itemGlyphs=0x8fbc688,
    fontEngine=0x8a37670)
    at /home/bram/KDE/qt-copy/src/gui/text/qtextengine.cpp:817
#1  0xb6b608cc in QTextEngine::shapeTextWithHarfbuzz (this=0x8ae0f70,
    item=1173) at /home/bram/KDE/qt-copy/src/gui/text/qtextengine.cpp:1155
#2  0xb6b615c1 in QTextEngine::shapeText (this=0x8ae0f70, item=1173)
    at /home/bram/KDE/qt-copy/src/gui/text/qtextengine.cpp:876
#3  0xb6b61abf in QTextEngine::shape (this=0x8ae0f70, item=1173)
    at /home/bram/KDE/qt-copy/src/gui/text/qtextengine.cpp:1366
#4  0xb6b6cb1a in QTextLine::layout_helper (this=0xbff539b4,
    maxGlyphs=2147483647)
    at /home/bram/KDE/qt-copy/src/gui/text/qtextlayout.cpp:1591
#5  0xb6b6d9f4 in QTextLine::setLineWidth (this=0xbff539b4, width=1191)
    at /home/bram/KDE/qt-copy/src/gui/text/qtextlayout.cpp:1466
#6  0xb4f7ff4d in KateRenderer::layoutLine (this=0x8996380,
    lineLayout=@0xbff53a84, maxwidth=1191, cacheLayout=false)
    at /home/bram/KDE/kde41/kdelibs/kate/render/katerenderer.cpp:801
#7  0xb4f88052 in KateLayoutCache::line (this=0x89ed0e8, realLine=181,
    virtualLine=-1)
    at /home/bram/KDE/kde41/kdelibs/kate/render/katelayoutcache.cpp:276
#8  0xb4f883eb in KateLayoutCache::viewLine (this=0x89ed0e8,
    realCursor=@0x89ed3ec)
    at /home/bram/KDE/kde41/kdelibs/kate/render/katelayoutcache.cpp:360
#9  0xb4f8892d in KateLayoutCache::textLayout (this=0x89ed0e8,
    realCursor=@0x89ed3ec)
    at /home/bram/KDE/kde41/kdelibs/kate/render/katelayoutcache.cpp:311
#10 0xb4fd7d28 in KateViewInternal::updateCursor (this=0x89ed398,
    newCursor=@0xbff53c08, force=false, center=true, calledExternally=false)
    at /home/bram/KDE/kde41/kdelibs/kate/view/kateviewinternal.cpp:1808
#11 0xb4fc5268 in KateView::setCursorPositionInternal (this=0x8996b00,
    position=@0x8dc7478, tabwidth=1, calledExternally=false)
    at /home/bram/KDE/kde41/kdelibs/kate/view/kateview.cpp:1000
#12 0xb4ff336c in KateSearchBar::selectRange (view=0x8996b00, range=@0x8f7d3d0)
    at /home/bram/KDE/kde41/kdelibs/kate/utils/katesearchbar.cpp:244
#13 0xb4ff66da in KateSearchBar::onIncPatternChanged (this=0x8bf0580,
    pattern=@0xbff53e6c, invokedByUserAction=true)
    at /home/bram/KDE/kde41/kdelibs/kate/utils/katesearchbar.cpp:406
#14 0xb4ff71e7 in KateSearchBar::qt_metacall (this=0x8bf0580,
    _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0xbff53e1c)
    at /home/bram/KDE/kde41/BUILD/kdelibs/kate/katesearchbar.moc:136
#15 0xb7408213 in QMetaObject::activate (sender=0x8f086e8,
    from_signal_index=27, to_signal_index=27, argv=0xbff53e1c)
    at /home/bram/KDE/qt-copy/src/corelib/kernel/qobject.cpp:3010
#16 0xb740878d in QMetaObject::activate (sender=0x8f086e8, m=0xb71fc8c8,
    local_signal_index=0, argv=0xbff53e1c)
    at /home/bram/KDE/qt-copy/src/corelib/kernel/qobject.cpp:3080
#17 0xb6d64860 in QLineEdit::textChanged (this=0x8f086e8, _t1=@0xbff53e6c)
    at .moc/debug-shared/moc_qlineedit.cpp:208
#18 0xb6d6b963 in QLineEditPrivate::finishChange (this=0x8f93fe8,
    validateFromState=2, update=false, edited=true)
    at /home/bram/KDE/qt-copy/src/gui/widgets/qlineedit.cpp:2848
#19 0xb6d6d307 in QLineEdit::insert (this=0x8f086e8, newText=@0xbff53f1c)
    at /home/bram/KDE/qt-copy/src/gui/widgets/qlineedit.cpp:1329
#20 0xb6d716b9 in QLineEdit::keyPressEvent (this=0x8f086e8, event=0xbff54614)
    at /home/bram/KDE/qt-copy/src/gui/widgets/qlineedit.cpp:2070
#21 0xb6989e79 in QWidget::event (this=0x8f086e8, event=0xbff54614)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qwidget.cpp:6962
#22 0xb6d6d131 in QLineEdit::event (this=0x8f086e8, e=0xbff54614)
    at /home/bram/KDE/qt-copy/src/gui/widgets/qlineedit.cpp:1602
#23 0xb6920175 in QApplicationPrivate::notify_helper (this=0x884c9b8,
    receiver=0x8f086e8, e=0xbff54614)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qapplication.cpp:3772
#24 0xb69207d1 in QApplication::notify (this=0xbff55084, receiver=0x8f086e8,
    e=0xbff54614)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qapplication.cpp:3420
#25 0xb7905ffc in KApplication::notify (this=0xbff55084, receiver=0x8f086e8,
    event=0xbff54614)
    at /home/bram/KDE/kde41/kdelibs/kdeui/kernel/kapplication.cpp:311
#26 0xb73f1991 in QCoreApplication::notifyInternal (this=0xbff55084,
    receiver=0x8f086e8, event=0xbff54614)
    at /home/bram/KDE/qt-copy/src/corelib/kernel/qcoreapplication.cpp:587
#27 0xb692dce5 in QCoreApplication::sendSpontaneousEvent (receiver=0x8f086e8,
    event=0xbff54614)
    at ../../include/QtCore/../../../../qt-copy/src/corelib/kernel/qcoreapplication.h:218
#28 0xb6997fac in qt_sendSpontaneousEvent (receiver=0x8f086e8,
    event=0xbff54614)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qapplication_x11.cpp:4680
#29 0xb69d625f in QKeyMapper::sendKeyEvent (keyWidget=0x8f086e8, grab=false,
    type=QEvent::KeyPress, code=65, modifiers=@0xbff54924, text=@0xbff548f0,
    autorepeat=false, count=1, nativeScanCode=38, nativeVirtualKey=97,
    nativeModifiers=0)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qkeymapper_x11.cpp:1656
#30 0xb69d7562 in QKeyMapperPrivate::translateKeyEvent (this=0x8868510,
    keyWidget=0x8f086e8, event=0xbff54d80, grab=false)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qkeymapper_x11.cpp:1627
#31 0xb69a7692 in QApplication::x11ProcessEvent (this=0xbff55084,
    event=0xbff54d80)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qapplication_x11.cpp:3148
#32 0xb69d9a7d in x11EventSourceDispatch (s=0x884f918, callback=0,
    user_data=0x0)
    at /home/bram/KDE/qt-copy/src/gui/kernel/qguieventdispatcher_glib.cpp:148
#33 0x47140ccd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#34 0x47143ee3 in ?? () from /usr/lib/libglib-2.0.so.0
#35 0x0884e490 in ?? ()
#36 0x00000000 in ?? ()
Comment 1 Bram Schoenmakers 2008-08-21 21:36:38 UTC
Created attachment 26966 [details]
Page source of Google News, making Katepart slow
Comment 2 Christoph Cullmann 2008-08-22 07:48:09 UTC
No chance to fix, this is a 1xxxxx long line, there is no way to handle that fast, for bidi text rendering all must be layouted of one line, no speedup possible, perhaps google should at least put in some newlines somewhere :)
Comment 3 Bram Schoenmakers 2008-08-22 17:52:13 UTC
OK, I missed the fact that it was only one line. Thanks for your time, though.
Comment 4 Andreas Pakulat 2008-09-03 23:36:07 UTC
*** Bug 170322 has been marked as a duplicate of this bug. ***
Comment 5 Stefan Radermacher 2008-09-03 23:49:57 UTC
Bug 170322 however does not occur with a one-line file, but a file with several lines with line length of about 700
Comment 6 Andreas Pakulat 2008-12-14 18:21:13 UTC
*** Bug 177773 has been marked as a duplicate of this bug. ***
Comment 7 Andreas Pakulat 2009-01-15 19:51:52 UTC
*** Bug 180850 has been marked as a duplicate of this bug. ***
Comment 8 Dario Andres 2009-05-01 01:11:40 UTC
*** Bug 189787 has been marked as a duplicate of this bug. ***
Comment 9 Dario Andres 2009-05-03 14:41:06 UTC
*** Bug 191467 has been marked as a duplicate of this bug. ***
Comment 10 Andreas Pakulat 2009-06-11 08:31:21 UTC
*** Bug 195971 has been marked as a duplicate of this bug. ***
Comment 11 Matt Hubert 2009-06-11 08:48:59 UTC
This happens on lines of even 300 characters. I admit that 10^5 characters is excessive, but 300 characters is definitely a bug. Any reasonable block of text will have at least that many. (For comparison, this comment is ~200.)
Comment 12 Andreas Pakulat 2009-07-13 17:44:48 UTC
*** Bug 200049 has been marked as a duplicate of this bug. ***
Comment 13 Dominik Haumann 2009-07-19 00:34:51 UTC
*** Bug 200707 has been marked as a duplicate of this bug. ***
Comment 14 João Eiras 2009-07-19 02:06:54 UTC
Resolving as wontfix is not a solution for this severe performance problem.
There is so much content online that fits lots of content in single lines, for instance
http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js

So, people cannot rely on kate/kwrite/konq to text files because it might randomly freeze.
Comment 15 Andreas Pakulat 2009-07-19 03:08:25 UTC
(In reply to comment #14)
> Resolving as wontfix is not a solution for this severe performance problem.

Well, we didn't have the 'upstream' resolution yet back then (I think), else this would be an that. Reason is (as far as I understood kate devs) that kate doesn't provide much room for improvements, the slowness thus mostly comes from our base libraries (i.e. font-rendering with freetype, Qt's rendering, X11, graphics driver).

> There is so much content online that fits lots of content in single lines, for
> instance
> http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js
> 
> So, people cannot rely on kate/kwrite/konq to text files because it might
> randomly freeze.

I suggest to try running kate with -graphicssystem raster if you have Qt4.5 or later. That improves rendering speed quite a bit apparently (without it KDevelop is hardly useable on 1 year old laptops due to the extensive highlighting)
Comment 16 Matt Hubert 2009-07-19 03:47:12 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Resolving as wontfix is not a solution for this severe performance problem.
> 
> Well, we didn't have the 'upstream' resolution yet back then (I think), else
> this would be an that. Reason is (as far as I understood kate devs) that kate
> doesn't provide much room for improvements, the slowness thus mostly comes from
> our base libraries (i.e. font-rendering with freetype, Qt's rendering, X11,
> graphics driver).

It must be a Qt thing though, because this doesn't happen with Gnome.

> > There is so much content online that fits lots of content in single lines, for
> > instance
> > http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js
> > 
> > So, people cannot rely on kate/kwrite/konq to text files because it might
> > randomly freeze.
> 
> I suggest to try running kate with -graphicssystem raster if you have Qt4.5 or
> later. That improves rendering speed quite a bit apparently (without it
> KDevelop is hardly useable on 1 year old laptops due to the extensive
> highlighting)

Wow! That is amazing. -graphicssystem raster really makes a big difference. I was using Kile (which just embeds Kate) and it basically removed the lag. Perhaps that should be a default or something?
Comment 17 Dominik Haumann 2009-07-19 10:26:13 UTC
Just to make this clear again: What Christoph said in comment #2 is actually the real problem. If you have a really long line, in bidirectional languages there can be embedded text from left to right and right to left. Drawing a line means we (Qt) *have* to layout the complete line. If the line is very long, this takes time - and quite a lot it seems. Fixing this is mostly a Qt issue iiuc.
Comment 18 Stefan Radermacher 2009-07-19 10:33:10 UTC
Pure Qt apps like Qt-Creator seem to work fine with long lines.

If the bidi support is really the case of this slowdown, maybe it should be disabled by default so that the minority of users who need it can activate it.
Comment 19 Anne-Marie Mahfouf 2009-07-19 11:12:48 UTC
Too bad, as I said GEdit deals with this :(

Is there a Qt testcase and a Qt bug tracker number?
Comment 20 ietc 2009-08-26 08:02:58 UTC
Should this really be UPSTREAM rather than WONTFIX then?  The latter probably gives the wrong impression when this is a rather aggravating bug.

By the way, -graphicssystem opengl works for me, too, and even better than raster (for systems that support opengl, of course).
Comment 21 ietc 2009-08-26 08:24:38 UTC
Come to think of it, I think Konsole exhibits the same behavior.  Difference is, I can only use -graphicssystem raster (which does improve performance) not opengl (which causes a strange issue where everything black -- including the menu and dialog texts -- to be transparent).

Is this also related to the bidirectional language rendering?  Maybe there is a bug already open for Konsole, too.
Comment 22 Milian Wolff 2010-01-13 00:20:05 UTC
*** Bug 222437 has been marked as a duplicate of this bug. ***
Comment 23 Milian Wolff 2010-01-13 00:58:23 UTC
*** Bug 210464 has been marked as a duplicate of this bug. ***
Comment 24 Milian Wolff 2010-02-21 13:37:41 UTC
I created a bug report upstream:

http://bugreports.qt.nokia.com/browse/QTBUG-8389
Comment 25 Milian Wolff 2010-03-23 13:59:18 UTC
merging bug as the other one has more votes

*** This bug has been marked as a duplicate of bug 225228 ***