Closed Bug 255824 Opened 20 years ago Closed 19 years ago

stop using png backgrounds with transparency in the download, extension and theme lists

Categories

(Toolkit :: Add-ons Manager, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: nirvn.asia, Assigned: bugs)

References

Details

(Keywords: perf)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040811 Firefox/0.9.1+ Firefox skin needs to stop using png backgrounds with transparency in the download, extension and theme lists until the bug 64401 (there is 3 or 4 bugs all speaking of this same problem) has been fixed. On half of the computers I use, those windows are very, very slow to refresh and scroll throu the list, it doesn't give a feeling of a 1.0 product. Either fix the png background transparency slow rendering problem, or do a quick band aid and remove the backgrounds in those 3 lists (it's not like it gives a super effect everybody will die for ... I much more for the speed and responsiveness of the windows) Reproducible: Always Steps to Reproduce:
Flags: blocking-aviary1.0?
Mathieu is right. In classic.jar/skin/classic/mozapps/extensions classic.jar/skin/classic/mozapps/shared classic.jar/skin/classic/mozapps/downloads, if you convert all those pngs to non-transparent gifs, not only scrolling performance is vastly improved but window resizing too. At first glance, itemfader.png, viewfader.png and itemselected.png are the most responsible for performance loss. If all images (or their links) are removed, srolling speed becomes perfect. It would be an easy win for Download, Extensions & Theme managers if we would remove transparency at least. At current state, performance is unacceptable even for a 1.0PR release. As Mathieu already noticed, missing transparency is not something to worry about. Look at the attached screenshot of this modified Extension Manager, where all pngs were replaced with non-transparent gifs and compare it to the original EM. Imo it is quite acceptable.
Flags: blocking-aviary1.0PR?
Attached image screenshot of modified EM (deleted) —
->Extension/Theme Manager, adding Asa Dotzler to cc list in order to get some attention. Bugs affected : bug 227260, bug 255812.
Component: General → Extension/Theme Manager
Keywords: perf
no need to change the button img though, its only the list backgrounds that are causing the problem
The problem affects only certain configurations, most people don't suffer from it, afaict. There are extensions that disable that transparency, IMO they just need to be made more visible (see Firefox release notes and bug 250050)
it affects around 50% of the computers I installed firefox on ... and everytime it happened, the other guy looked at me saying "is this normal, this thing is slow and not so responsive" and I had to explain that it was only a bug for those dialogs... ... my point is: nobody will miss the transparency and all the 50% users that would face a major slow down (I see it even on 2ghz cpus with good gfx cards) simply wont face it and everybody will be happy
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #4) > no need to change the button img though, its only the list backgrounds that are > causing the problem Performance suffers a little because of button images (window resizing was smootless after removing them) but I agree that *fader.png and itemselect.png cause the biggest problem. Anyway, this bug is highly visible on certain computers (e.g. mine is P4-2.4MHz with Geforce MX440 Win2KSP3).
same here, I can see the problem with strong computers like yours - any dev can put a block PR or at least final ? it's a question of 4 min of work on the default theme
A maybe useful note : Ext. Manager has excellend scrolling and resizing performance in Charamel theme. It's notably faster than Winstripe, even after modifying the images or removing the backgrounds in extensions.css. I suspect that Charamel author had additional tricks under his sleeve that I wasn't able to understand. Anyone else? Simply install Charamel 1.0.6 and compare it with the patched Winstripe.
-> ben
Assignee: firefox → bugs
QA Contact: firefox.general → bugs
I optimized the thress PNGs in question and shrunk each by at least 70% with no loss in quality (I hope). I just checked in the optimized versions on Aviary branch. Please test.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
Keywords: fixed-aviary1.0
... what do you mean by optimized ? it's not the size of the file that made it slow, it's the fact that they use transparency.
right. but since the PNGs were unoptimized (3x larger than they needed to be), we might see a performance gain from using optimized images. I didn't claim to actually fix this bug. I'm curious to know if my checkin makes performance any better.
Keywords: fixed-aviary1.0
ok I tried it and nothing changed, same performance lag... just make them opaque (doesnt make any difference anyway) and after you can close this bug... I guess firefox could revert to transparent backgrounds when they will fix the related bugs in the rendering engine
This bug is WONTFIX. If we remove something, the underlying problems are never fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
so you plan to fix the png with transparency in background slow rendering before 1.0 final ??? good news indeed if not, I can't do much except telling you that your own product doesn't look so professional on a 2.5ghz when suddenly going into a slow-to-respond mode. I really hope you'll fix the underlying problem before 1.0 final, otherwise rethink your decision ... your team removed some features (altss,off-line mode) out of 1.0 final because they very slushy, it wouldn't be so bad to do a temp., easy to revert, (we don't speak of removing anything) fix for a problem that is caused by a bug that has been hanging around for age (bug 64401), a bug which is _not_ blocking firefox 1.0 final btw ... its up to you, but I've been introducing firefox to a lot of users and all of them facing this problem pointed it out and didn't find it acceptable. Try to browse the extension manager window with 25 extensions...
if you decide not to move on this subject, at the very least redo your patch that you did for 0.9 and put it in the known issues section of your 1.0 PR release notes
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Performance gains are had by removing the non-existant fixed background, not the transparent background. ->WONTFIX.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WONTFIX
(In reply to comment #18) > Performance gains are had by removing the non-existant fixed background, not the > transparent background. ->WONTFIX. Has this fixed background reference been removed in current branch nightlies ?
with this build: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040915 Firefox/0.10 the bug is still present so I assume you state the problem but didnt do the changes yet; you might want to create a bugzilla # for it or write the bug number in this thread ... if you did the change, it was not the source of the problem
Flags: blocking-aviary1.0+
Status: RESOLVED → REOPENED
Depends on: 64401
Resolution: WONTFIX → ---
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Depends on: 227260
There is no longer any slow scrolling for me in the extension manager. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050504 Firefox/1.0+ Probably not the png background causing this. Patch for bug 292472 seemed to have fixed it.
Depends on: 292472
The background image has been removed (see bug 299395) but there is still a background image for the selected item. This bug is about slow scrolling which no longer appears to be a problem. resolving -> WFM If you are still experience slow scrolling using the default theme it would probably be best to open a bug with a summary describing the incorrect behavior and not the proposed solution... the proposed solution can of course be in the original comment.
Status: REOPENED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → WORKSFORME
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: