Description: "brushed exuberance" A context browser style for amaroK, based slightly on Fnis by otey. Makes use of brushed metal look quite exuberantly Probably needs KDE > 3.5.1 to run smoothly. And looks best with kde baghira style.Last changelog:
0.5: allow width up to 500px; aligned album length; more consistent hovering; made conTEXT (script) box look better 0.4: fixed display errors for amarok < 1.4 (overlapping bug in home tab etc.) 0.3b: disc separator prettified 0.3: album's song list prettified; song separator was missing in suggested songs list 0.2: recently played tracks prettified 0.1b: made wikipedia links recognizable
When making brushed blue amaroK (http://www.kde-look.org/content/show.php?content=35184), I encountered similar performance problems.
I suspect it may be to do with using small images which repeat to cover the background. Maybe KHTML gets delayed over each time it has to render /images/background.png? (small image of brushed metal which matches Baghira when tiled; I think you used it unmodified as /images/back.png. IIRC I made it by cropping the background from the original Brushed Blue, which used a single large image because it didn't need to support scrolling).
Maybe making the image a bit bigger so it only gets rendered 2-3 times would make it render faster?
Do your other PNGs repeat at all?
Is it possible that in background.png I have used some stupid encoding option in Gimp which makes it take longer to render? I don't know much about the PNG format.
In any case, this is all hard for me to test because I get this problem only intermitently. Can someone who can reproduce the performance thing try my theme to see if it is affected too? Thanks a lot.
Hmm, I don't think the repeating background would cause such grave problems like msoos is experiencing. As for my other PNGs, yes they are repeated..moreover, they are a bit smaller and partly transparent, so they probably need the most computing power... I remember I had some problems too when playing with different background-style values..I also played with the image sizes, but AFAIR this did not affect performance.
Maybe it's just that KDE 3.5.1 (KHTML) improves something in PNG rendering?
Just looking through the KDE 3.5.1->3.5.2 changelog, I found a reference to this bug, fixed in 3.5.2 but not 3.5.1. Rendering transparent PNGs with KHTML seems relevant to it. http://bugs.kde.org/show_bug.cgi?id=114938
It's great, but it takes ages to render, scrolling through the artist's albums takes ages, at about 1 fps. I have never had any problems with other themes, or any other thing for that matter. I also have working HW-accelerated 3D-rendering (DRI). I use amarok 1.3.8, on Debian sid.
thanks for your comment, now I can understand why people started voting 'bad'.. The problem is not "intended" in any way, for me rendering performance is perfect (KDE 3.5.1, amaroK svn, no DRI).
Please, anyone having the same issue, post your specs. Or any idea how this could be solved. (It's not the amarok version, I tried 1.3.8 now, and repaired some display bugs btw.).
Ratings & Comments
7 Comments
When making brushed blue amaroK (http://www.kde-look.org/content/show.php?content=35184), I encountered similar performance problems. I suspect it may be to do with using small images which repeat to cover the background. Maybe KHTML gets delayed over each time it has to render /images/background.png? (small image of brushed metal which matches Baghira when tiled; I think you used it unmodified as /images/back.png. IIRC I made it by cropping the background from the original Brushed Blue, which used a single large image because it didn't need to support scrolling). Maybe making the image a bit bigger so it only gets rendered 2-3 times would make it render faster? Do your other PNGs repeat at all? Is it possible that in background.png I have used some stupid encoding option in Gimp which makes it take longer to render? I don't know much about the PNG format. In any case, this is all hard for me to test because I get this problem only intermitently. Can someone who can reproduce the performance thing try my theme to see if it is affected too? Thanks a lot.
Hmm, I don't think the repeating background would cause such grave problems like msoos is experiencing. As for my other PNGs, yes they are repeated..moreover, they are a bit smaller and partly transparent, so they probably need the most computing power... I remember I had some problems too when playing with different background-style values..I also played with the image sizes, but AFAIR this did not affect performance. Maybe it's just that KDE 3.5.1 (KHTML) improves something in PNG rendering?
Just looking through the KDE 3.5.1->3.5.2 changelog, I found a reference to this bug, fixed in 3.5.2 but not 3.5.1. Rendering transparent PNGs with KHTML seems relevant to it. http://bugs.kde.org/show_bug.cgi?id=114938
It's great, but it takes ages to render, scrolling through the artist's albums takes ages, at about 1 fps. I have never had any problems with other themes, or any other thing for that matter. I also have working HW-accelerated 3D-rendering (DRI). I use amarok 1.3.8, on Debian sid.
thanks for your comment, now I can understand why people started voting 'bad'.. The problem is not "intended" in any way, for me rendering performance is perfect (KDE 3.5.1, amaroK svn, no DRI). Please, anyone having the same issue, post your specs. Or any idea how this could be solved. (It's not the amarok version, I tried 1.3.8 now, and repaired some display bugs btw.).
Maybe you want to try version 0.2 (see above). I guess it'll be at least a little faster?
This is great. I am going to have to edit the text though so it's blue.