Bug 234560

Summary:	CoverBling animation sometimes freezes
Product:	[Applications] amarok	Reporter:	Bernd Buschinski <b.buschinski>
Component:	Context View/Cover Bling	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kfunk, kretschmann, mail, manu.wagner, simon.esneault, thomas.luebking
Priority:	HI
Version:	2.3-GIT
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

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.