Closed Bug 373675 Opened 17 years ago Closed 16 years ago

Icon resize doesn't support alpha-transparency

Categories

(addons.mozilla.org Graveyard :: Developer Pages, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jwkbugzilla, Assigned: nmaier)

References

Details

Attachments

(3 files, 2 obsolete files)

Extension icons often use alpha-transparency. However, if I upload the Adblock Plus icon (http://www.mozdev.org/source/browse/~checkout~/adblockplus/src/chrome/skin/classic/adblockplus.png) it will be resized (32x32 to 32x32 :) and the result looks broken. Apparently the alpha-transparent parts have been changed to opaque using a black background. If I save the same image with a white background without any transparency and upload it everything is fine.
I attempted to fix this in r2608. "Attempted" means it does now respect alpha transparencies, but resized images still don't look entirely beautiful and smooth. That, however, looks more like a problem with the gd library rather than part of this bug.

I also avoided resizing images that already have the destination size. Thus we don't make the quality worse by resizing 32x32 to the same size, as you mentioned above.

I mark it fixed for now, please let me know if you disagree.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Yes, seems to work fine (and didn't reopen bug 372808, comments are still stripped from the file).
Nope, doesn't work for me (downthemall).
We're using png24 with semi-transparency.

Icon:
http://bugs.code.downthemall.net/trac/browser/trunk/chrome/skin/common/icon.png?format=raw

Working solution (for that icon at least) is to call
> imagesavealpha($sourceImage, true);
after |imagecreatefromString)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch enabling alpha for sourceImage (obsolete) — Splinter Review
Comment on attachment 260012 [details] [diff] [review]
enabling alpha for sourceImage

We wanna write a test for this too?  Just a gold-master or A/B thing would work fine, I suspect.
Attachment #260012 - Flags: review?(fligtar)
Attachment #260012 - Flags: review?(fligtar) → review+
Assignee: nobody → MaierMan
Status: REOPENED → NEW
Alright, it got a review...
So now somebody will have to check this in and update the production servers accordingly ;)
Whiteboard: [checkin needed]
I was waiting for comment #6 before checking in.
Keywords: checkin-needed
Whiteboard: [checkin needed]
Attachment #260012 - Attachment is obsolete: true
Attachment #302850 - Attachment is patch: true
Attachment #302850 - Attachment mime type: application/octet-stream → text/plain
Status: NEW → ASSIGNED
Keywords: checkin-needed
Please address comment #6.
Keywords: checkin-needed
Ok, you're desperate for a test-case?
Here you are.
Doesn't include the test-data images. Will attach mine later.
Isn't that elegant.
And actually I don't know much about creating test cases for cake/AMO...
Actually it was quite a challenge to get the stuff up and running.
Attachment #302850 - Attachment is obsolete: true
Attachment #304175 - Flags: review?(fligtar)
Comment on attachment 304175 [details] [diff] [review]
Same as above, this time with a testcase

r=fligtar

Checked in r10620, along with a few other test fixes.

This is only on 3.2 branch, so it will be pushed live when that launches in March.

Thanks for the patch and testcase!
Attachment #304175 - Flags: review?(fligtar) → review+
Status: ASSIGNED → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.2
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: