Bug 198770

Created attachment 35016 [details]
analog clock problem

this still happens on kde4.3 RC1

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

Thanks

Marking as NEEDSINFO

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.

Thanks

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)

Manuel, Maciej, can you check in KDE 4.4.1 if the problem is still present please? Thanks in advance!

This bugs is pretty hard to reproduce (usually happens here between KDE SC updates, especially when corresponding to analog clock SVG's are changed).

I've just logged in to my shine fresh build of kde 4.4.1 aaaand... bug still there :(

Created attachment 41279 [details]
fresh build of 4.4.1

Manuel: what about a new user with default desktop? is this a cache problem then? I'd really like to reproduce this.

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)

*** Bug 231571 has been marked as a duplicate of this bug. ***

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.

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)

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.

I can confirm for 4.4.3 on Linux

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

Still present in 4.4.81

*** Bug 240580 has been marked as a duplicate of this bug. ***

*** Bug 241446 has been marked as a duplicate of this bug. ***

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.

KDE needs to wipe out its /var/tmp/ dir on startup, that's it. It will workaround broken cache invalidation mechanisms.

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.

Please turn the Status to Confirmed otherwise this but is never going to be taken in account.

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

Segio: Thanks for clarification, I did not know the exact procedure.

Still it is clear, that this bug is "confirmed enough".

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.

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.

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.

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.

Created attachment 49669 [details]
for the records: still there

Reproducible the same way in 4.5.0 release.

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.

Thanks Alexey.

Ahem, excuse me – I'd like a second opinion here. The bug's survived bumps before.

I have noticed this bug twice since I upgraded to 4.5.0, so it's definitely not fixed yet.

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

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

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

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

Thank you very much, so annoying bug. So, will this fix be in 4.6.0?

Yes, I backported to 4.6 branche.

Nice, thank you.

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?

the svnbackport script from kde cannot apply my changes to 4.5. But I take a look tomorrow if I find some time.

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

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

Just to note: the above are the backports for 4.5 and 4.4.