Bug 198770 - analog clock rendering errors
Summary: analog clock rendering errors
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-clock (show other bugs)
Version: unspecified
Platform: Ubuntu Unspecified
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
: 231571 240580 241446 (view as bug list)
Depends on:
Reported: 2009-07-03 13:18 UTC by Miguel Tadeu
Modified: 2011-01-10 19:51 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:

analog clock problem (30.56 KB, image/png)
2009-07-03 13:19 UTC, Miguel Tadeu
Screenshot from KDE SC 4.4 RC3 (196.93 KB, image/png)
2010-02-06 12:53 UTC, Manuel Mommertz
fresh build of 4.4.1 (18.18 KB, image/png)
2010-03-03 11:27 UTC, Manuel Mommertz
Analog clock, Glaze theme, Win XP, KDE 4.4.1 (53.03 KB, image/png)
2010-06-01 16:32 UTC, Eric Francis
it just happend again (108.70 KB, image/png)
2010-07-29 22:27 UTC, Manuel Mommertz
for the records: still there (88.03 KB, image/png)
2010-07-30 12:15 UTC, Manuel Mommertz

Note You need to log in before you can comment on or make changes to this bug.
Description Miguel Tadeu 2009-07-03 13:18:40 UTC
Version:            (using KDE 4.2.90)
Installed from:    Ubuntu Packages

a while after booting, the analog clock loses the background(all black) and the clock hands. I'll leave a screen shot
Comment 1 Miguel Tadeu 2009-07-03 13:19:14 UTC
Created attachment 35016 [details]
analog clock problem
Comment 2 Miguel Tadeu 2009-07-03 13:19:47 UTC
this still happens on kde4.3 RC1
Comment 3 Dario Andres 2009-07-15 23:13:54 UTC
- Does this happen with any other Plasma Theme?
- After how many time this start to happen ?
There was a bug causing some pixmaps/backgrounds to start dissapearing after some time, but that should be fixed for 4.3rc1.

Comment 4 Dario Andres 2009-08-17 20:48:08 UTC
Marking as NEEDSINFO
Comment 5 Maciej Mrozowski 2010-01-26 04:49:37 UTC
Still happens occasionally with 4.4rc2.
It may be tied to plasma cache not being up2date, especially after theme updates.
It may be related to bug 205257.
Comment 6 Dario Andres 2010-01-27 01:28:11 UTC
Comment 7 Manuel Mommertz 2010-02-06 12:53:28 UTC
Created attachment 40565 [details]
Screenshot from KDE SC 4.4 RC3

I am affected by this bug in 4.4 RC3. It's the first time I see this kind of bug. (But I have seen painting bugs like complete dissapering of the clock before)
Comment 8 Anne-Marie Mahfouf 2010-03-01 13:11:07 UTC
Manuel, Maciej, can you check in KDE 4.4.1 if the problem is still present please? Thanks in advance!
Comment 9 Maciej Mrozowski 2010-03-01 23:31:12 UTC
This bugs is pretty hard to reproduce (usually happens here between KDE SC updates, especially when corresponding to analog clock SVG's are changed).
Comment 10 Manuel Mommertz 2010-03-03 11:23:41 UTC
I've just logged in to my shine fresh build of kde 4.4.1 aaaand... bug still there :(
Comment 11 Manuel Mommertz 2010-03-03 11:27:24 UTC
Created attachment 41279 [details]
fresh build of 4.4.1
Comment 12 Anne-Marie Mahfouf 2010-03-03 12:54:47 UTC
Manuel: what about a new user with default desktop? is this a cache problem then? I'd really like to reproduce this.
Comment 13 Manuel Mommertz 2010-03-03 13:28:28 UTC
Just reproduced with a new user:
- created user
- logged in
- placed clock on desktop
- added activity
- placed another clock and changed size (to be shure it doesn't use the same cached pixmap)
- add activity switcher to panel

- restarted computer
- logged in
- clock on the active activity is fine
- changed activity
- clock on the now active activity shows the bug

(just relogin without restart didn't show the bug)
Comment 14 Marco Martin 2010-05-13 21:30:07 UTC
*** Bug 231571 has been marked as a duplicate of this bug. ***
Comment 15 Eric Francis 2010-06-01 16:25:27 UTC
I've seen this same thing happen too.  If the analog clock is on the first activity loaded on login then it renders correctly.  If it is on any other activity then when you switch to the activity with the clock, then everything renders out-of-place; the hands appear to render between the clock's circular boundary and the widget's square boundry, or outside of the widget area entirely entirely.

The clock remains in that state until something causes the clock to redraw itself, e.g. when you bring up the clock settings and hit OK.
Comment 16 Eric Francis 2010-06-01 16:29:41 UTC
As I can tell, this problem is inherent to Plasma; I've seen it in both WinXP (KDE versions up to and including 4.4.1) and Linux (Ubuntu and PCLinuxOS, yet to confirm KDE version 4.4.3)
Comment 17 Eric Francis 2010-06-01 16:32:33 UTC
Created attachment 47562 [details]
Analog clock, Glaze theme, Win XP, KDE 4.4.1

I've also seen this happen irrespective of the plasma theme.
Comment 18 Alexey Chernov 2010-06-01 16:33:32 UTC
I can confirm for 4.4.3 on Linux
Comment 19 Maciej Mrozowski 2010-06-01 17:02:40 UTC
I wonder whether it's related to bug 205257.
If so, then it's unlikely to be fixed for <=4.4 (and supposedly fixed in 4.5 already).
Comment 20 Manuel Mommertz 2010-06-02 12:49:04 UTC
Still present in 4.4.81
Comment 21 Beat Wolf 2010-06-03 13:40:48 UTC
*** Bug 240580 has been marked as a duplicate of this bug. ***
Comment 22 Beat Wolf 2010-06-11 17:40:42 UTC
*** Bug 241446 has been marked as a duplicate of this bug. ***
Comment 23 Unknown 2010-06-28 10:29:09 UTC
Those who say it's related to new versions of KDE are probably right. After an upgrade to RC 1, clock went wrong but after the first plasma crash it's ok.

So if you haven't upgraded to RC 1 yet, do a backup of your ~/.kde4 folder and I think after the upgrade restoring the old folder this bug could easily be tracked down.
Comment 24 Maciej Mrozowski 2010-07-08 13:50:59 UTC
KDE needs to wipe out its /var/tmp/ dir on startup, that's it. It will workaround broken cache invalidation mechanisms.
Comment 25 Michael Büker 2010-07-29 02:09:15 UTC
I can confirm for a fresh install of KDE 4.4.2 on Kubuntu 10.04.
It happens to me when I load the Widget Dashboard, on which I have placed the Analog clock.
Comment 26 gorn 2010-07-29 13:48:23 UTC
Please turn the Status to Confirmed otherwise this but is never going to be taken in account.
Comment 27 Aaron J. Seigo 2010-07-29 21:52:01 UTC
"Please turn the Status to Confirmed otherwise this but is never going to be
taken in account."

we close un-confirmed bugs all the time. it doesn't actually measurably increase fix priority, it just lets us know how much investigation will be required on our part when fixing it. we prioritize based on severity + devel cost.
Comment 28 gorn 2010-07-29 21:55:34 UTC
Segio: Thanks for clarification, I did not know the exact procedure.

Still it is clear, that this bug is "confirmed enough".
Comment 29 Maciej Mrozowski 2010-07-29 22:08:38 UTC
I cannot reproduce anymore with 4.5 svn branch (it happened usually just after rebuilding and reinstalling KDE) and evene when it happened, restarting plasma-desktop this time actually fixed this issue so as of now my opinion is that bug is fixed for 4.5.

Of course people using 4.4 will complain and report bugs but they're unlikely to get it fixed imho as code changes (pixmap and/or svg cache I suppose) between 4.4 and 4.5 are (usually) too big.
Comment 30 Aaron J. Seigo 2010-07-29 22:15:15 UTC
yes; it's already marked as "New" though, which is a step after "Unconfirmed" :)

in any case, given comment #29, can we get a confirmation of that from someone else who is/was affected by this bug? one more conf, and we can call it closed for now.
Comment 31 Manuel Mommertz 2010-07-29 22:18:29 UTC
I still get this from time to time. It now affects the clock even when I only have one (in the past I need to have two of them to get it on one). My plasma is from 4.5 branche and updated the last time on the 26th of july. I think I got it only once since then but it's still there.
Comment 32 Manuel Mommertz 2010-07-29 22:27:36 UTC
Created attachment 49655 [details]
it just happend again

Rebuilding 4.5 branche now to be sure it was not fixed in the last three days.
Comment 33 Manuel Mommertz 2010-07-30 12:15:34 UTC
Created attachment 49669 [details]
for the records: still there
Comment 34 Alexey Chernov 2010-08-16 22:37:53 UTC
Reproducible the same way in 4.5.0 release.
Comment 35 Alexey Chernov 2010-08-16 22:54:03 UTC
Sorry, please, ignore comment #34, I've cleared /var/tmp/ and the bug isn't reproducible anymore (tried 3 times for now). If it finally appears again I'll write it here.
Comment 36 FiNeX 2010-08-17 00:40:46 UTC
Thanks Alexey.
Comment 37 Michael Büker 2010-08-17 00:53:11 UTC
Ahem, excuse me – I'd like a second opinion here. The bug's survived bumps before.
Comment 38 Bartosz Brachaczek 2010-08-17 07:10:42 UTC
I have noticed this bug twice since I upgraded to 4.5.0, so it's definitely not fixed yet.
Comment 39 Manuel Mommertz 2010-08-17 11:32:54 UTC
Please don't close this bug just by one person that can't trigger this bug. As posted above this bug is still present. It is not that often anymore but it still happens.
Just to be sure I logged out removed all in /tmp and /var/tmp logged in again. And while my two clocks were rendered correctly after login this changed when I resized them.
(I use 4.5 branche last recompiled on the 13. of August.)
Comment 40 Nico Dorn 2011-01-03 23:23:37 UTC
Bug confirmed for 4.5.4.

Reproducibility: everytime. Steps to reproduce (see also comment 13):
1) Create more than one activity.
2) Put an analog clock on one activity.
3) Change the activity.
4) Reboot. (After the reboot, the last selected activity, the one without the clock, is shown.)
5) Change to the activity with the analog clock.

Tested with Kubuntu 10.10, default theme, on two different computers with different graphic chips (Intel and NVIDIA).
Comment 41 Manuel Mommertz 2011-01-09 19:20:42 UTC
I found it!

The paint-function of analog clock has three steps:
1 - render the fixed parts of the clock to a pixmap and calculate hands position
2 - render the hands to a pixmap
3 - render the pixmaps to screen

There is a variable that holds which steps should be run. On start this is initializied to all. If the time changes it is set to step 2 and 3. If a repaint is needed without a change before only step 3 is run.

Now if the clock starts on a not-active activity, on the next repaint all steps should be run. But as soon as the time changes it is reset to only run steps 2 and 3. And zack -> the face isn't painted and therefor the correct hands position is never set (until the clock is resized).
Comment 42 Manuel Mommertz 2011-01-09 19:25:04 UTC
SVN commit 1213231 by mommertz:

Fix rendering if clock is on an inactive activity on login
BUG: 198770

 M  +1 -1      clock.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1213231
Comment 43 Alexey Chernov 2011-01-09 19:36:20 UTC
Thank you very much, so annoying bug. So, will this fix be in 4.6.0?
Comment 44 Manuel Mommertz 2011-01-09 19:45:28 UTC
Yes, I backported to 4.6 branche.
Comment 45 Alexey Chernov 2011-01-09 19:50:45 UTC
Nice, thank you.
Comment 46 Michael Büker 2011-01-09 20:34:37 UTC
From what I read about the nature of the bug, this should be easy to backport further. Would you maybe do that for 4.5 and 4.4 also?
Comment 47 Manuel Mommertz 2011-01-09 21:33:10 UTC
the svnbackport script from kde cannot apply my changes to 4.5. But I take a look tomorrow if I find some time.
Comment 48 Manuel Mommertz 2011-01-10 19:49:40 UTC
SVN commit 1213528 by mommertz:

Fix rendering if clock is on an inactive activity on login
CCBUG: 198770

 M  +1 -1      clock.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1213528
Comment 49 Manuel Mommertz 2011-01-10 19:49:59 UTC
SVN commit 1213529 by mommertz:

Fix rendering if clock is on an inactive activity on login
CCBUG: 198770

 M  +1 -1      clock.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1213529
Comment 50 Manuel Mommertz 2011-01-10 19:51:20 UTC
Just to note: the above are the backports for 4.5 and 4.4.