Korganizer: Terrible delay in mouse action on calendar

[dotancohen]

Binary package hint: kdebase-kde4

When the user runs the scrollwheel or clicks on the calander, the main window takes a full second to respond, and the calendar view takes another second to update itself. For instance, the user clicks on a specific date. After one second delay the date's details appear in the main window, and one second later the calendar changes to show the new date selected. I have not seen these delays using the official KDE 4.1 builds, only from the Ubuntu repos.

Kontact v1.3

Note that this is in a Dual-core, 2GHz system that I use to triage bugs for KDE and KDEPIM. I have not experienced this delay in any configuration other than the default 8.10a3 build.

[Rigo Wenning (rigo-w3)]

2008-09-05 Confirmation from me on KDE 4.1.1 with latest packages from ~ppa. (Kontact 1.3 having Korganizer 4.1.1) It is almost impossible to schedule a meeting while being on the phone. I also noticed delays while typing emails. Letters take several milliseconds to appear, which is most probably related to spell-checking. There is no way to stop spell-checking in KDE 4.1.1 system settings in Kubuntu. (I want kcontrol back instead of this tool stripped down to meaninglessness) So I can't test without spell-checking.

This is a very annoying bug and hinders upgrade for the moment. There is no issue using kontact 1.2.9 on KDE 3.5.9

[Gandalf (gandalf-lechner)]

With the same setup, I experience some delay in calendar, but nothing as drastic as described here.

Regarding spell checking, there is the menu "options" in the window containing your new message, it includes the entry automatic spell checking.

[Rouven Sacha (rouvensacha)]

Can confirm. Thought it was a kolab issue, cause we run all of our contacts, tasks and calendars on a kolab 2.2 server. Especially the KMail component is slow.

[Richard Birnie (rbirnie-deactivatedaccount)]

Thanks for reporting this bug. Obviously several people are observing this behaviour. These reports all come from the prior to these reports all come from prior to the release of KDE4.1.2. Does the problem still exist in KDE4.1.2 for you?

I just tried the actions described in dotancohen's screenshot and the reaction is pretty instant on my system which runs current intrepid with KDE4.1.2

[Rigo Wenning (rigo-w3)]

I have KDE 4.1.2 on intrepid on one machine and hardy with 4.1.2 on my laptop. If I run kontact locally, one may overlook the performance issues described. But I usually have all my email processing and calendering working on my laptop just by ssh -ing into it and thus export the X to the big desktop display.
While kontact 1.2.9 in KDE 3.5.9 show immediate reaction even in the remote scenario, kontact 1.3 is even unable to show the letters while I type them and has a lag of about 7-10 letters towards the end of a phrase, let alone if one uses backspace. On the (100Mb/s) switch I can see very heavy network traffic while typing.
To isolate more, I used kontact:
1.2.9 in a KDE 4.1.2 session on the Desktop: works fine
1.3 in a KDE 3.5.9 session on the Desktop is just as slow
I tried to start kontact on the Desktop via an ssh from laptop into Desktop and I have the same issue as above.

And NO, 4.1.2 does not fix anything as this has IMHO nothing to do with KDE, it is a problem of KDEPim and some changed information exchange behavior or a different use of buses or something like this. I only know that 1.2.9 was highly efficient while 1.3 is more or less unusable in the remote scenario and still somewhat slow in the local scenario. I tried any type of mixture of KDE 3.5/4.1.2 with kontact 1.2.9/1.3.

It is very interesting to see actually, that while typing in the subject line, there are no delays, but typing in the message body creates those terrible delays of letters showing up. I think this is a regression from some older code that has been used. It may come from some wxWidget stuff because I faced the same issue with Amaya at some point in time. The GTK version work while the wx-Version was not usable in a remote scenario.

It is also interesting to see that the scrolling with the mouse wheel from one week to another in korganizer works faster in the month view than in the week view.

Ok, now one can tell me that one can't expect such applications to work over a 100Mb/s network. But it worked before, not having it working now is a regression either of KDEPim or the generic way KDE transports image information from the application to the screen.

Note also that I use nvidia cards on both machines... I have no other application having that issue of slowness. Konqui and dolphin and other stuff just works fine over ssh.

[Rigo Wenning (rigo-w3)]

Just did additional tests. I I run the calendar I have locally on the desktop it is as slow. Mousewheel action is just slow. One tic with the mouse wheel takes about 2 seconds of reaction. If one has to quickly scroll to some date 3 month ahead to discuss fixing appointments, the time one arrives there, the teleconf is over.
Again, all that works perfectly with kontact 1.2.9. It may also be that it is tied to a new storage format (akonadi anyone?). Is there a way to get a kontact 1.10.1 compiled for KDE 3.5.9 so that I could test it?

Additionally, I have looked at the version numbers: It is Kontact 1.10.1 which comes with KDE 4.1.2. So this is the version I've tested, not the 1.3 as described above.

[Roderick B. Greening (roderick-greening)]

I do not see any issues here. Intel vid card on an Acer 9410 laptop.

I wonder if this is a driver issue with compositing/plugin issue? Are you using any of the desktop effects and can you disable them and re-test and provide your harware specs?

[Richard Birnie (rbirnie-deactivatedaccount)]

Just to clarify on the version numbers.

Kontact in KDE 4.1.2 is 1.3:
kontact --version
Qt: 4.4.3
KDE: 4.1.2 (KDE 4.1.2)
Kontact: 1.3

The Kmail component is 1.10.2:
kmail --version
Qt: 4.4.3
KDE: 4.1.2 (KDE 4.1.2)
KMail: 1.10.1

The reason I asked about the change from KDE4.1.1 to 4.1.2 is that kdepim is released as part of the core KDE release so any changes in kdepim from upstream that might affect this issue would have been incorporated in kubuntu with the 4.1.2 release but we've ruled that out now.

[Rigo Wenning (rigo-w3)]

I just discovered the following and trying it out:
 http://linux.derkeiler.com/Mailing-Lists/KDE/2008-10/msg00132.html
 I have discovered that this slowness is produced because I changed the
 timezone but did not move all the existing events to the new timezone. The
 calendar file therefore had more than one timezone. Changing this restored the
 application's vigour.

 On Wednesday 15 October 2008 10:03:17 Peter Lewis wrote:

Calendar has become very slow. It takes about 15 seconds to change from one
 week to another.
 Has anyone else experienced a slow calendar.
 Is there any details that I should provide to help

 I am running KDE 4.1.1 (KDE 4.1.0 (4.1 >= 20080722)) "release 26.5" in SuSE
 11.0.
================================================
I remember that KDE 4 asked me once during one of my regular timezone shifts. But I can't find the menu again. Settings>date & time just says "Could not start control module for date and time format"

Hope that helps

But still this does not explain the weired delays while writing email. From my network monitoring, I would say there is too much chatter going on or there is a wrong default that goes into timeout.

[Richard Birnie (rbirnie-deactivatedaccount)]

Rigo,

thanks for the input. That certainly moves us forward quite a bit. I think we can say the slow Calendar problem has been diagnosed. One could argue that Kontact ought to migrate all the existing events automatically but for now lets try to get to the root of the typing problem. I'm not sure what would cause this. It sounds like some kind of problem with keyboard input which suggests the X system but I can't think why it would be unique to kmail.

You said earlier that Konqueror and dolphin behave themselves. What about Kate or Kwrite? I'm jut trying to think of applications where you do a decent amount of typing. Are you using Konqueror to post this thread?

[dotancohen (dotancohen)]

I do not have a test system set up at the moment, but when I filed the bug Kate was working fine. Also, the calendar was imported from a single std.ics file that I manually copied from ~/.kde/share/apps/korganizer on KDE 3 and put in the appropriate place in KDE 4. Therefore I do not think that there should have been a conflict of timezones. The std.ics file does not include timezone information for events.

[Rigo Wenning (rigo-w3)]

Ok, I tried kate and kwrite from 3.5 and they were instantaneous over ssh. Kate and Kwrite are both slower in their KDE4 version. But not to the point like in email. I had no spellchecking enabled. I type this message into the bugtracking using Konqi 4.1.2 with spellchecking enabled and it works really well. No delays at all.
I also yesterday played a bit with the desktop effects as I'm using nvidia cards known to have issues and I'm also using twinview. Twinview has acceleration on both screens. That's why I use it instead of xinerama. Enabling "sharpen" and "explosion" crashed my entire system. If I just use the default effects (including compiz) it just works fine. I have translucency and all box/flip/cover switches enabled.
But i have the impression that automatic spell check works differently. The new spell checking already underlines even if the word typed has only three letters. In KDE 3.5 it only tests once the word is finished and the first space is introduced thereafter. It is also very surprising that editing the subject box has nearly no delays while writing the message body has the problem.
I will now try to use Kontact1.3/KMail 1.10 with an external editor enabled.

Now the big question is: Have all who experience this delay nvidia graphics cards?

[Rigo Wenning (rigo-w3)]

Just realized scrolling a larger email, that smooth scrolling is still enabled in KMail despite the fact that I tried to disable it everywhere. This may also be an issue with Korganizer. One could imagine that the display tries to smooth-scroll typing and calendar ending in a nightmare...

[Richard Birnie (rbirnie-deactivatedaccount)]

I admit I'm at a loss to explain this. It's odd why it should be restricted to kdepim.

"Now the big question is: Have all who experience this delay nvidia graphics cards?"

This is a question that was going through my mind as well. I don't see this bug, neither does Roderick Greening. We have both have intel graphics so it is still a possibility. dotancohen's comment suggests there may still be issues with the calendar as well. One way to check would be if someone can attach a calendar file that shows the issues described then I can try it on my machine.

thanks

[dotancohen (dotancohen)]

I'm the OP and I have an ATI MobilityRadeon x1400 card. I am not sure if I was using the FOSS or proprietary drivers at the time of testing.

[Richard Birnie (rbirnie-deactivatedaccount)]

This came to me directly from Rigo

"I still think it has to do with some smooth scrolling that runs
berserk. The screen behavior is like this. It starts slowly and
accelerates. My nose was dropped on this again when I scrolled this
long email and it tried to smoothly scroll. Smooth scrolling is all
about rendering delays, isn't it?"

Based on this suggestion I resorted to Google. It seems as if this is already known upstream. Take your pick from these three:
http://bugs.kde.org/show_bug.cgi?id=76082
http://bugs.kde.org/show_bug.cgi?id=168132
http://bugs.kde.org/show_bug.cgi?id=163626
The crux of the problem seems to be that Smooth scrolling behaviour can be enabled/disabled in Konqueror but that the setting doesn't apply to any other application using the khtmlpart. Such as kmail and akregator (and probably calendar). As far as I can tell there is no way of configuring this behaviour globally, which is a design flaw in itself. I suppose it is still possible that differences between machines are caused by differences between the different hardware and different drivers to support this behaviour but that's purely speculation on my part.

The third link has a suggested work around at the end. I tried it and it made no difference. If anyone else wants to try it and report back that would be appreciated. In the short term the best we can do is probably for the people affected by this bug to add a comment to the kde report and hope we can persuade them to do something about it. 76082 seems to be where most of the activity is. I'm going to confirm this bug now based on the upstream reports and link it so we can track the activity.

Thanks for following through everybody

[Rigo Wenning (rigo-w3)]

Inbetween my Desktop computer crashed completely (hardware). I have tried the "SmoothScrolling=Disabled" workaround from http://bugs.kde.org/show_bug.cgi?id=163626
I can't test the remote scenario anymore for the above reasons, but the performance on my laptop is already better. The remaining suspicious issue locally is that moving with the arrow keys is delayed. Again, this only happens in Kontact/KMail, not in Konqueror. Going left/right, one often misses the word to be changed, so moving again until hitting the right word. In a normal scenario this is hardly an issue, but for power users like me, this is really very annoying. (e.g. scribing real time verbatim)
But I can only give confirmation once I have a new desktop to try the remote scenario (login via ssh and export X)

[dotancohen (dotancohen)]

@Richard:
I do not think that this issue is related to the smooth scrolling issue in KDE. I am familiar with the smooth scrolling issue, and that has been a problem since before the problems in KOrganizer started. This is a different issue.

[Alan Porter (alan.porter)]

I can confirm the extremely slow performance using the calendar. I usually have about 10 "resources" (calendars: one for personal, one for work, one for kids, etc) open. When I turn one on or off, it takes a full 5 seconds to redraw the screen. It takes 4.5 seconds to go from one month to the next. 2.4 GHz P4, ATI graphics, no fancy effects. During the delay, the CPU is 100%. This stuff used to run lightning fast on Hardy.

[Rigo Wenning (rigo-w3)]

I've tested now with mandriva freshly installed on my new desktop. I still have the same issue: Even on the 3Ghz double core desktop, there are some delays. Over the wire this becomes even more visible. So even starting Kontact on mandriva and exporting display to Kubuntu has the same issues as the other way around. So this looks like an upstream bug. Kontact 3.5.9 is just lightning fast with instantaneous reaction on scrolling calendar, even over an exported and crypted Xsession. I assume passing from 3.5.9 to 4.1.2 came with major changes to the code. But the issue happened there.

[dotancohen (dotancohen)]

This appears to be the proper upstream bug:
https://bugs.kde.org/show_bug.cgi?id=170993

[norimu (baruckobima332)]

The slow typing problem in kmail is still present in KDE 4.1.3. Disabling automatic spell checking in the composer window menu doesn't solve it. Is there a workaround?
I have an older savage graphics chip and desktop effects off.

[dotancohen (dotancohen)]

Please stop crossposting with the slow typing in Kmail problem. It has been established that it is a separate issue. Feel free to file a new bug on it and mention the new bug here.

As for the OP, there is still no solution to the problem of the delay in the calendar. The proposal earlier in the thread to change / check timezones does not solve the problem.

[dotancohen (dotancohen)]

Fixed upstream.

[Jonathan Thomas (echidnaman)]

Fix released to Jaunty.