Bug 97565 - system stalls for seconds with every kworldclock map image update
Summary: system stalls for seconds with every kworldclock map image update
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kworldclock
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified All
: NOR normal
Target Milestone: ---
Assignee: Matthias Hoelzer-Kluepfel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-21 01:02 UTC by Bartosz Fabianowski
Modified: 2010-04-17 15:48 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bartosz Fabianowski 2005-01-21 01:02:31 UTC
Version:            (using KDE KDE 3.3.2)
Installed from:    FreeBSD Ports
Compiler:          gcc version 3.4.2 [FreeBSD] 20040728 Configured with: FreeBSD/i386 system compiler    Thread model: posix
OS:                FreeBSD

Whenever the KDE World Clock decides to redraw the world map, it maxes out CPU usage on my system for seconds, effectively stalling the entire system. The visible symptoms are that the Xorg process jumps to almost 100% CPU usage, all screen updates are suspended and keyboard input is not processed. After a few seconds (when the world clock is done redrawing the map), the system recovers, the screen starts updating again and the keys typed come out of some buffer and are processed. Most annoyingly, the order of key presses is often mingled forcing me to delete everything typed during the stall.

The system is a Centrino 1.6GHz laptop with a 1920x1200 screen and the clock is running in full screen. It seems to be the very large screen resolution that triggers this behavior. At 1024x768, the world clock does not  produce such massive stalls.

At this screen resolution, the map image is updated every 45 seconds. So, there is a stall every 45 seconds. However, when the system is busy overall, the effect escalates. When I am compiling something, there does not seem to be enough CPU power left for the clock to finish redrawing within 45 seconds, leading to stall after stall and rendering the system completely unusable for minutes on end.

The problem has been present on this machine ever since it was first set up. It started at Xorg 6.7.0 / KDE 3.3.0 and is now at KDE 6.8.1 / KDE 3.3.2. No combination of Xorg and KDE has changed anything about the world clock's behavior. Overall system performance, by the way, is very good. When the clock is not open, I can run heavy compiles without any noticeable impact on the system's behavior. There is no other load that would lead to the kind of stalls that the world clock produces.

Although I am not familiar with the clock's code at all, my guess is that some very inefficient algorithm is used to redraw the map, maybe something that scales O(n^2). At 1920x1200 pixels, the inefficiency becomes very apparent.

For now, the simple solution is to not use the KDE World Clock. However, it would be much nicer of course if somebody had an idea how to fix the map drawing function to make it more efficient.
Comment 1 Ben King 2005-02-22 23:21:32 UTC
I get this as well. Every 10 minutes my whole system freezes completely, just as you say (even messing up the keyboad input). This actually causes a movies I'm watching to stop for several seconds. The strange thing is: I didn't even know I had kworldclock started, no there was no window of it or anything. It was just in pstree. 
Comment 2 Martin Zbořil 2009-02-04 17:41:18 UTC
reproduceable in KDE 4.2 stable from openSuSE factory build
Comment 3 Bartosz Fabianowski 2009-02-04 18:01:45 UTC
Confirmed on both FreeBSD and Linux, in the 3.x and 4.x series then...
Comment 4 Stefan Böhmann 2010-04-17 15:47:47 UTC
This is a bug again kworldclock from kdetoys, right? 

kworldclock isn't maintained anymore. A replacement could be the Marble WorldClock Plasmoid. 

If this bug is still valid for the Marble WorldClock Plasmoid please open a bug against it (Product: marble, Component: plasmoid).