Bug 234560 - CoverBling animation sometimes freezes
Summary: CoverBling animation sometimes freezes
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Context View/Cover Bling (show other bugs)
Version: 2.3-GIT
Platform: Gentoo Packages Linux
: HI normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-16 21:00 UTC by Bernd Buschinski
Modified: 2011-06-05 19:53 UTC (History)
6 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 Bernd Buschinski 2010-04-16 21:00:58 UTC
Version:           git-84ad0085280802c2a1ae93baa59b33a216828978 (using KDE 4.4.2)
Compiler:          gcc-4.5.0 
OS:                Linux
Installed from:    Gentoo Packages

in amarok 84ad0085280802c2a1ae93baa59b33a216828978

the coverbling animation on track change only works corretcly if I first maximized the applet.
Note I mean the maximize function in the applet, without it it just draws the final image.
But the names are always "animated" correctly on track change.

+ use the coverbling and the album applet
Comment 1 Andreas Kuhl 2010-04-22 14:39:38 UTC
Can confirm this...
Comment 2 manu.wagner 2010-04-22 18:53:57 UTC
Hi,

Do you mean that the cover is displayed but without any transition effect ?
I can't seem to reproduce @ my end, but my version has not been merged upstream yet...
Comment 3 Andreas Kuhl 2010-04-23 08:01:17 UTC
Yes, there is a latency of a few seconds and then the current cover is replaced by the next cover without any transition.

Sometimes, the transitions work when starting Amarok, most times not. I can always temporary fix it by enlarging the coverbling applet and downsizing it again. After this, transitions always work (at least for the duration of the Amarok session).
Comment 4 Mark Kretschmann 2010-04-26 19:32:22 UTC
@Manu: I think this might just be another side of the same bug that I had talked about before (animation not working in all cases).

I have a suspicion that this has to do with the free amount of graphics memory. All of these covers are QPixmaps (if I'm not mistaken), and with a large set of covers and little graphics memory this could become an issue, because QPixmap resides in graphics memory.
Comment 5 Thomas Lübking 2010-04-28 14:33:53 UTC
@Mark
unlike TRAM (where eg. opengl places textures) VRAM should be mapped (but with the most broken driver ;-) to RAM via AGP or PCIe/PEG (it's just becoming really painfully slow then, but pixmaps should keep working) and from there to swap... (but then you start to have _real_ problems :)

I'd go for an initialisation bug that gets validated on resizes (esp. as maximizing is not going to lower pixmap usage)
Comment 6 manu.wagner 2010-04-28 15:26:13 UTC
I think Thomas is right : it doesn't look like a performance issue but it's more likely to be an init problem.
As I am not observing this @ my end, it might be solved in my merge request there http://gitorious.org/amarok/amarok/merge_requests/156
So one option would be to try that one out...

About Mark's problem, I'm not sure it's a memory issue (as all QPixmap are empty but the ones that are really browsed thru)
Comment 7 Kevin Funk 2011-06-05 12:28:59 UTC
Manu, do you have a fix for this? Create a quick review request if possible. The merge request link from Gitorious is broken.
Comment 8 manu.wagner 2011-06-05 17:57:31 UTC
the changes I was mentionning have been merge already.
Is anyone still facing the issue ?
Do you have any debug traces ?
Comment 9 Kevin Funk 2011-06-05 19:53:16 UTC
Okay, nice. Thanks for the work.