Bug 253560 - Tab switching is very slow (Qt 4.7 regression)
Summary: Tab switching is very slow (Qt 4.7 regression)
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.5-rc1
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Konversation Developers
Depends on:
Reported: 2010-10-08 02:40 UTC by Fabian B.
Modified: 2021-03-11 02:40 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Fabian B. 2010-10-08 02:40:43 UTC
Version:           1.3.1 (using KDE 4.5.1) 
OS:                Linux

if i try to change the root/query in the tabbar or channellist i click on it an wait 1-2sec. it the programm change it. I have most time 3 or more query open and its no fun to change. The same it is with the nick-change dropdown menu. it takes many seconds to change the nick. (in the interface, the /nick command take no time)
i have tries now Quassel IRC. there are no interface related slowdown. its Qt, not direct kde :s. but i have in no other "real" KDE-application this slowdowns.

Reproducible: Always

Steps to Reproduce:
Start konversation. open query woth some people. Chat a while und change often your tab

Actual Results:  
it is not possible to chat with konversation after a while because its that slow

Expected Results:  
it should be as fast as quassel is. because konversation is my favorite (:

tried with graphicsystem raster and native/X11. no real difference
Comment 1 Eike Hein 2010-10-08 03:21:39 UTC
I'm sorry for your bad experience, but your bug report contains no information that would allow us to figure out why the application is slow for you.

All I can tell you is that what you are seeing is not normal and that you should continue to try and eliminate environmental factors like graphics driver and library versions. Maybe try a fresh user account, too, or even a different Linux distribution (maybe via a live CD).

If you can determine any further information about the problem, such as whether the slowness seems related to any particular Konversation setting or occurs in a certain scenario, please reopen the bug report and post it.
Comment 2 Fabian B. 2010-10-08 04:27:04 UTC
ok i will try it in the next days with an opensuse. a new user do not help. Graphicdriver is maybe the problem. its an Radeon (and a radeon-gallium).
what i had noticed is tho longer konversation runs th slower is the tabchange. at the start open 2 server (freenode and animexx.de) on freenode 4 channel, on animexx 1.
i will test around a little (:
Comment 3 Fabian B. 2010-10-08 23:20:20 UTC
OK i think i have found the problem. i leave konversation open the day. now in some Channel are more than 1000lines of text and the switch to this channels takes 2-3 secs. in a query are 259 lines of text. the switch takes 1 sec.. other query and channel with less text dont have this problem. if i close konversation and restart konvi, it is fast again.
Comment 4 Eike Hein 2010-10-09 00:23:11 UTC
So it seems the problem is text rendering speed, which is most likely related to your graphics drivers in some way.

Did you try with --graphicssystem=raster? Do you have a wallpaper image set for the chat text views?
Comment 5 Fabian B. 2010-10-09 00:43:25 UTC
Jep normal my system runs with raster graphicsssystem. tried it with nativ/X11 too without a differents. background is normal white without image. Tested today with Kubuntu and Opensuse(live) and now with kubuntu+gallium-ati driver. but with the same result.
Comment 6 Inso 2010-10-31 19:15:48 UTC
Same problem here with :
Catalyst 10.10
KDE 4.5.2
Comment 7 shentino 2010-12-15 16:19:29 UTC
Same problem here on gentoo.

Git HEAD as of December 15, 2010
Comment 8 Modestas Vainius 2010-12-18 00:58:15 UTC
Same here:

Qt: 4.7.1
KDE Development Platform: 4.4.5 (KDE 4.4.5)
kde4-config: 1.0

konvi 1.3.1 and 1.3.1+git264+g6dfad44

vendor string:    The X.Org Foundation
vendor release number:    10902902
X.Org version:

ii  xserver-xorg-video-intel                             2:2.13.901-2

Kwin compositing (OpenGL) is on.
Comment 9 Eike Hein 2010-12-18 15:29:24 UTC
Modestas, does the problem go away when you raise every tab at least once?
Comment 10 Modestas Vainius 2010-12-18 15:41:04 UTC
Well, it is very slow when rising a tab after long time. It is somewhat (~2x) faster when rising the same tab soon after but delay (~1 sec) and subsequently unresponsiveness of konvi are still noticeable and rather uncomfortable.

My system is:

Sysinfo for 'mdxdesktop': Linux 2.6.36-trunk-amd64 running KDE Development Platform 4.4.5 (KDE 4.4.5), CPU: Intel(R)Corei3CPU540@3.07GHz at 3066 MHz (6133 bogomips), HD: 166/364GB, RAM: 3537/3709MB, 239 proc's, 10.16d up

P.S. This may be related to either Qt 4.7.1 or Xorg upgrade. I don't recall such problems (at least to such extent) in my previous setup. But I don't want to downgrade now. I will do some testing when I get a chance.
Comment 11 Eike Hein 2010-12-18 15:44:57 UTC
I was specifically referring to raising every tab at least once, because there have been reports of slowness that disappeared after doing so.
Comment 12 Modestas Vainius 2010-12-18 17:23:31 UTC
Then the short answer is no.
Comment 13 Noor Aliham Muhamad 2010-12-21 00:54:54 UTC
I also have slowness with Konversation. Changing from one tab to another takes a few seconds. Also when in the chat window consists of hash sign followed by text, which konversation will assume it as a join clickable channel text and you mouse over the text, konversation will hang for a few seconds.

I have three active servers with multiple channels on each server all the time. So I'm not sure if it is due to that cos I have not tested for it. But the annoyance is really unbearable.
Comment 14 Eike Hein 2010-12-21 00:57:23 UTC
No, it's not related to the amount of channels and networks - I'm in ~45 channels distributed over five connections, and switching tabs takes an unnoticable split second. Anything else is definitely irregular and not normal behavior.
Comment 15 shentino 2010-12-30 08:53:46 UTC
Updating to qt 4.7.1 slowed things down a ways.  Then again, I had to upgrade to that to fix a "vanishing cursor" bug.  No win situation eh?
Comment 16 Eike Hein 2010-12-30 09:00:50 UTC
The first report is a good month older than Qt 4.7.1, though ... Fabian, were you using Qt from git or 4.7.0?
Comment 17 shentino 2010-12-30 09:05:58 UTC
I'm on an atom 330 so it's particularly bad for me :<
Comment 18 Eike Hein 2010-12-30 09:10:31 UTC
I still can't reproduce it on any of my three systems. AMD, Intel, nVidia, ATI, x86, x64, PowerPC ... it's a pretty diverse mix, but they're all running Fedora. I've also tried an Arch virtual machine with no success. I'll have to try doing a native install of Debian since Modestas it seeing it there.
Comment 19 Modestas Vainius 2010-12-30 09:55:15 UTC
I upgraded straight from Qt 4.6.3 to Qt 4.7.1 (skipping versions in between). So the bug might have been in Qt 4.7.0 or its betas as well. Anyway, I'm downgrading back to 4.6.3 now. However, some time (a day or more) has to pass before I can tell for sure if konvi is slow or not. Wait for more news.
Comment 20 Fabian B. 2010-12-30 13:16:03 UTC
(In reply to comment #16)
> The first report is a good month older than Qt 4.7.1, though ... Fabian, were
> you using Qt from git or 4.7.0?

Qt: 4.7.0 (in Kubuntu 10.10) :)
Comment 21 Modestas Vainius 2010-12-30 21:59:35 UTC
Well, I can confidently say that the problem is gone after downgrade to Qt 4.6.3.
So this is Qt 4.7 related.
Comment 22 shentino 2010-12-30 22:03:49 UTC
Is 4.6.3 the latest version of Qt that doesn't cause Konv to slow down?
Comment 23 Modestas Vainius 2010-12-30 22:08:36 UTC
It appears to be. I have not tested and do not intend to test Qt 4.7 betas and RCs.
Comment 24 Eike Hein 2011-01-01 16:27:33 UTC
Thanks for taking the time to test this, Modestas :)
Comment 25 shentino 2011-01-01 17:38:51 UTC
I can't win can I?  The update included a fix for an annoying cursor vanishing bug. :P
Comment 26 Eike Hein 2011-01-01 17:48:26 UTC
And Qt 4.6 had a bug when it came out that caused a 100% CPU usage condition, and Qt 4.0-4.6 have a severe QString bug, both of which we had to put workarounds for into new versions ... yeah we're having fun with our toolkit ;)
Comment 27 shentino 2011-01-01 18:03:54 UTC
Has this issue been reported upstream to Qt?
Comment 28 Eike Hein 2011-01-01 18:11:39 UTC
Reporting a bug to Nokia is essentially useless unless you can provide sample code with a minimal testcase, and even then it usually takes a year or so for them to react, so we don't have enough data so far.
Comment 29 Modestas Vainius 2011-01-01 19:36:27 UTC
I can't win can I?  The update included a fix for an annoying cursor vanishing
bug. :P

You can fix that cursor bug by backporting a patch from 4.7.1, e.g. http://tinyurl.com/fix-disappearing-cursor
Comment 30 shentino 2011-01-03 06:04:11 UTC
Is there a good reason for KDE to have all its toolkit eggs in one basket with Nokia's Qt?

If bugs routinely take a year or so to fix methinks that might be a ding against them.
Comment 31 Modestas Vainius 2011-03-12 02:10:41 UTC
Just FYI, the bug is still there with Qt 4.7.2. As I no longer really have a choice but to use Qt 4.7, so I may look at this someday when the bug annoys the hell out of me (hopefully, somebody beats me to it :)).
Comment 32 Modestas Vainius 2011-07-28 19:33:47 UTC
Ignore what I said in comment #12. Raising all tabs at least once *cures* the problem until the next konversation restart. Therefore I made a habbit of walking through all tabs right after konversation startup.
Comment 33 shentino 2011-12-18 12:21:50 UTC
Any luck?
Comment 34 shentino 2013-06-30 23:17:26 UTC
Would like to confirm this is still a bug on the present v5-rc1
Comment 35 Henry Todd 2014-01-27 09:29:55 UTC
I can confirm that this issue (or something similar) still exists with Konversation Version 1.5-master #4303 (running on Arch with Qt 4.8.5-7). I found this bug report today after noticing that sometimes Konversation was pegging one of my cores at 100% and spinning up fans after running for a long time. In my case however I was not interacting with Konversation - it was just sitting minimised in the systray.

It appears to be happening at the same time as my wifi connection flakes out - causing Konversation to lose connection to my ZNC server and then get sent a bunch of buffer replays upon reconnection (for ~15 channels and a couple of queries).

I ran an strace (I can attach a log if it's of any use) and I see endless lines like these while Konversation has the core at 100%:

----------- 8< ----------------------------------------------
571   recvmsg(7, 0x7fffe2208310, 0)     = -1 EAGAIN (Resource temporarily unavailable)
571   poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
571   writev(7, [{"+\3\1\0", 4}, {NULL, 0}, {"", 0}], 3) = 4
571   poll([{fd=7, events=POLLIN}], 1, 4294967295) = 1 ([{fd=7, revents=POLLIN}])
571   recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1;Y\0\0\0\0\35\0\240\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
571   recvmsg(7, 0x7fffe2208170, 0)     = -1 EAGAIN (Resource temporarily unavailable)
571   recvmsg(7, 0x7fffe2208170, 0)     = -1 EAGAIN (Resource temporarily unavailable)
571   write(3, "\1\0\0\0\0\0\0\0", 8)   = 8
571   poll([{fd=7, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=7, revents=POLLOUT}])
571   writev(7, [{">\3\7\0*\0\300\4\36\0\300\4 \0\300\4\0\0\7\2\0\0\7\2c\3\27\0", 28}, {NULL, 0}, {"", 0}], 3) = 28
571   recvmsg(7, 0x7fffe2208970, 0)     = -1 EAGAIN (Resource temporarily unavailable)
571   poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=POLLIN}, {fd=13, events=POLLIN}], 10, 0) = 2 ([{fd=3, revents=POLLIN}, {fd=7, revents=POLLIN}])
571   read(3, "\2\0\0\0\0\0\0\0", 16)   = 8
571   recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"\16\0<Y\36\0\300\4\0\0>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
571   recvmsg(7, 0x7fffe2208990, 0)     = -1 EAGAIN (Resource temporarily unavailable)
----------- 8< ----------------------------------------------

I'm unsure if what I'm seeing is related to this bug or #303043, or perhaps something different altogether. However this was a few hours ago, so I can also say that so far the "raise all tabs" voodoo mentioned above seems to have stopped it. I'll report back if it reoccurs (without restarting Konversation).
Comment 36 Justin Zobel 2021-03-11 01:23:55 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.
Comment 37 shentino 2021-03-11 02:40:49 UTC
Qt4 itself is EOL at this point so I'm closing this bug