Bug 253560

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.

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 (:

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.

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?

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.

Same problem here with :
Archlinux
Catalyst 10.10
KDE 4.5.2

Same problem here on gentoo.

Git HEAD as of December 15, 2010

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: 1.9.2.902

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

Kwin compositing (OpenGL) is on.

Modestas, does the problem go away when you raise every tab at least once?

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.

I was specifically referring to raising every tab at least once, because there have been reports of slowness that disappeared after doing so.

Then the short answer is no.

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.

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.

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?

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?

I'm on an atom 330 so it's particularly bad for me :<

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.

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.

(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) :)

Well, I can confidently say that the problem is gone after downgrade to Qt 4.6.3.
So this is Qt 4.7 related.

Is 4.6.3 the latest version of Qt that doesn't cause Konv to slow down?

It appears to be. I have not tested and do not intend to test Qt 4.7 betas and RCs.

Thanks for taking the time to test this, Modestas :)

I can't win can I?  The update included a fix for an annoying cursor vanishing bug. :P

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 ;)

Has this issue been reported upstream to Qt?

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.

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

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.

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 :)).

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.

Any luck?

Would like to confirm this is still a bug on the present v5-rc1

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).

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.

Qt4 itself is EOL at this point so I'm closing this bug