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 ?? ()
Created attachment 26966 [details] Page source of Google News, making Katepart slow
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 :)
OK, I missed the fact that it was only one line. Thanks for your time, though.
*** Bug 170322 has been marked as a duplicate of this bug. ***
Bug 170322 however does not occur with a one-line file, but a file with several lines with line length of about 700
*** Bug 177773 has been marked as a duplicate of this bug. ***
*** Bug 180850 has been marked as a duplicate of this bug. ***
*** Bug 189787 has been marked as a duplicate of this bug. ***
*** Bug 191467 has been marked as a duplicate of this bug. ***
*** Bug 195971 has been marked as a duplicate of this bug. ***
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.)
*** Bug 200049 has been marked as a duplicate of this bug. ***
*** Bug 200707 has been marked as a duplicate of this bug. ***
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.
(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)
(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?
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.
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.
Too bad, as I said GEdit deals with this :( Is there a Qt testcase and a Qt bug tracker number?
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).
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.
*** Bug 222437 has been marked as a duplicate of this bug. ***
*** Bug 210464 has been marked as a duplicate of this bug. ***
I created a bug report upstream: http://bugreports.qt.nokia.com/browse/QTBUG-8389
merging bug as the other one has more votes *** This bug has been marked as a duplicate of bug 225228 ***