Bugzilla – Bug 6505
SqueezePlay sometimes handles transparent GIFs incorrectly
Last modified: 2011-11-06 23:24:59 UTC
For BottleRocket (http://forums.slimdevices.com/showthread.php?t=41482) I've been working on icon lists for Jive. I hoped to have On & Off icons that would be based on the simple 0/1 icon like that shown on the Jive Goodbye shutdown screen. I created two GIFs, On with a white 1 and grey 0, and Off with a white 0 and grey 1. Both have transparent backgrounds. Firefox, Nautilus, and Gimp all think the GIFs are OK. But the white 1 in the On icon (but not the 0 in the Off icon!) is treated as a transparent area.
Created attachment 2593 [details] sample problem icon GIF with white "1" that is displayed as transparent rather than white
Peter: we can look at this, but as a workaround, what happens if you use a PNG?
Trouble there, too. I can view all four with Firefox using URLs like http://localhost:9000/plugins/BottleRocket/html/images/power-on.png but the JHB displays the "unknown album" icon for all four PNG icons. This isn't a big deal for my plugin -- not only do I plan on not using icons until #6504 is closed, but I'm happy to use a color other than white. I've got a pair of red GIFs that display fine.
Created attachment 2597 [details] sample bad PNG this displays in the web UI, but not at all on JHB
Reset priority
I have just had a quick look at this and can confirm that the gif is not rendered correctly. The png is rendered ok, so I think another but (either in SqueezePlay or the Peter's plugin) was preventing the png from working. Peter could you try the png again. gif's are not a priority at the moment, changing the target to 7.1,
punting to 7.2
we plan to change the rendering engine to use cairo, so I am making this bug dependent on that change.
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code. Feel free to move it back if it's specific to the single original product.
Reset priority before triage.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
We need to review when this bug will be fixed.
This looks non-trivial to fix, and is not required for the core platform. For now, marking as future.
Richard is no longer available to us.
Unassigned bugs cannot have a priority.