In 4.90.90 and 4.90.91, changing the KDE colour scheme causes KDevelop's window to become unresponsive and stop redrawing. After about 30 seconds it unfreezes, with the new colors mostly used, but the text in tabs retains the original color which can be unreadable if changing dark->light or vice versa. The editor component retains the original colors, but this also occurs in Kate/KWrite and seems reasonable. Reproducible: Always Steps to Reproduce: 1. Start KDevelop 4.90.90+ 2. Change KDE colorscheme (in System Settings). Dark->light or the reverse is most noticeable. 3. Try poking KDevelop. Wait until it unfreezes. Look at it. Actual Results: KDevelop freezes for 30s, not all UI elements use new colorscheme. Expected Results: KDevelop changes colorscheme of all UI elements, remains responsive to input and window resizing. Compiled and run on ArchLinux x86_64, using gcc 5.3.0, with KF 15.08.0 and Qt 5.5.1. Intel graphics.
I've seen that as well.
Observations: - When no editor tabs open: Color switch is almost instant - With editor tabs open: Switch is indeed super slow, takes several seconds. Printing a few stack traces during the freeze revealed: #0 0x00007fe84d3b9c05 in QFontEngineFT::stringToCMap (this=0x61e00010c880, str=0x60b000511b88, len=5, glyphs=0x7ffc9a3ecac0, nglyphs=0x7ffc9a3eca88, flags=...) at ../gui/text/qfontengine_f t.cpp:1497 #1 0x00007fe864022cda in QFontEngineMulti::stringToCMap (this=0x61100158d480, str=0x60b000511b88, len=5, glyphs=0x7ffc9a3ecac0, nglyphs=0x7ffc9a3eca88, flags=...) at text/qfontengine.cpp:1 796 #2 0x00007fe8640440a0 in QTextEngine::shapeText (this=this@entry=0x610000121340, item=item@entry=0) at text/qtextengine.cpp:1006 #3 0x00007fe864044a7f in QTextEngine::shape (this=0x610000121340, item=item@entry=0) at text/qtextengine.cpp:1494 #4 0x00007fe8640584c5 in QTextLine::layout_helper (this=this@entry=0x7ffc9a3ece30, maxGlyphs=maxGlyphs@entry=2147483647) at text/qtextlayout.cpp:1766 #5 0x00007fe864058f99 in QTextLine::setLineWidth (this=this@entry=0x7ffc9a3ece30, width=<optimized out>) at text/qtextlayout.cpp:1531 #6 0x00007fe8678e6641 in KateRenderer::layoutLine (this=0x607000acafc0, lineLayout=..., maxwidth=944, cacheLayout=<optimized out>) at ../../src/render/katerenderer.cpp:1028 #7 0x00007fe8678ec8b1 in KateLayoutCache::line (this=this@entry=0x60600069b5a0, realLine=realLine@entry=35, virtualLine=virtualLine@entry=10) at ../../src/render/katelayoutcache.cpp:334 #8 0x00007fe8678ed281 in KateLayoutCache::updateViewCache (this=0x60600069b5a0, startPos=..., newViewLineCount=<optimized out>, newViewLineCount@entry=46, viewLinesScrolled=viewLinesScroll ed@entry=0) at ../../src/render/katelayoutcache.cpp:282 #9 0x00007fe86793a67f in KateViewInternal::doUpdateView (this=0x61600085e380, changed=<optimized out>, viewLinesScrolled=0) at ../../src/view/kateviewinternal.cpp:575 Feels like Kate is busy re-layouting the views? I'm still wondering why it's so slow, though (in my case I just had 4 tabs open)
I can reproduce this lag with Kate itself, so reassigning there. I'll also have a look at that now. Perf already shows that some excessive repainting is obviously at fault here: 16.54% 0.34% kate libKF5TextEditor.so.5.19.0 [.] KateRenderer::paintTextLine
Git commit 8c6a18964e0c0684d5ec068e686ed41aeb0fd657 by Milian Wolff. Committed on 30/01/2016 at 16:03. Pushed by mwolff into branch 'master'. Only update the palette once for the change event belonging to qApp. This fixes the massive freeze that occurs when the global color palette is changed. Note that the qApp event filter includes change events to many objects, but we only want to update once. M +2 -3 src/utils/kateglobal.cpp http://commits.kde.org/ktexteditor/8c6a18964e0c0684d5ec068e686ed41aeb0fd657
Reported https://bugs.kde.org/show_bug.cgi?id=358776 for the unreadable text issue.
*** Bug 348705 has been marked as a duplicate of this bug. ***
*** Bug 345553 has been marked as a duplicate of this bug. ***