Closed Bug 404402 Opened 12 years ago Closed 12 years ago

Ship and use different sizes of the Firefox window icon

Categories

(Firefox :: Shell Integration, enhancement, P2)

x86
Linux
enhancement

Tracking

()

VERIFIED FIXED

People

(Reporter: micmon, Assigned: Dolske)

References

Details

(Keywords: polish)

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007111904 Minefield/3.0b2pre

Right now Firefox seems to be shipping with a handful of strangely sized application icons (at least strange for the use on a Linux desktop). There are two things that should be done:

## Provide separate icons in PNG format for the commonly used sizes 16x16, 22x22, 24x24, 32x32 and 48x48. All with nice alpha and AA. Not just scaled down versions but tweaked versions to better fir the smaller sizes. If possible, also provide a scalable version of the logo in SVG format. This would fix the look of the Application launcher in the menu.

## Don't use a fixed size icon for the window icon. The current icon (48x48?) looks very blurry in the window list (scaled down to 16x16) but looks pixelized in window previews, scale and the task switcher. GTK apps have a mechanism to pick up the right size of the icon from share/icons/hicolor/apps/$SIZE/$APPNAME.png


Reproducible: Always
I totally agree... and in addition a tangoish version will look much better now that we will have a tangoish linux build
Severity: normal → enhancement
Summary: Firefox application icon → [linux] Ship and use different sizes of the Firefox icon
Version: unspecified → Trunk
I don't see any obvious dupes so confirming this as a valid RFE.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: polish
The 128x128 PNG icon has always scaled fine for me when adding it to a launcher, and I don't remember the app icon looking odd... I can't check my Ubuntu box at the moment, but it looks fine on my Solaris box.

Perhaps you could attach a couple screen shots showing what you're seeing?

The official tarball releases include a couple of .xbm files in icons/, which only have 1-bit transparency, so perhaps those are getting picked up for you?
Justin: yes, the 128x128 png firefox logo scales very, very well. For the launcher I use this, no problem. But firefox ships various versions of its icon, some of which are ugly xpm versions as you pointed out. I don't really understand how this works but it seems to me that the following icons are used inside of firefox:

## chrome/icons/default/default.xpm: seems to be used in the window switcher.

## browser.jar/chrome/content/branding/icon64.png: seems to be used as the window and task list icon for.

Regardless if we get specialized versions (or an svg) or not, I think firefox would profit from picking the icons from a central source, not scattered around and naturally not the xpm version. Ideally, Firefox would first check the system icon theme (freedesktop) for icons to use and then fall back to icons/mozicon128.png if it doesn't find any. If freedesktop lookup is to complicated, you could also just put pre-scaled (and perhaps fixed here and there) versions of the icon into icons/ (png for 16x16, 22x22/24x24, 32x32, 48x48).
Attached image Graphically show what I just explained (obsolete) —
And I totally forgot: the Mac people will probably ask for a 512x512 version of the icon, which is the new high resolution standard in the new Mac OS.
Hmm, I'd guess the usage of default.xpm is coming from nsWindow::SetDefaultIcon()...

http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#3816

That said, this also WFM on my Ubuntu box, even when running a nightly from the command line. The icon looks fine (smooth, aliased) in the window title bar and Gnome window list panel.

So, I'm wondering:

1) Why isn't this working for you / what conditions cause the .xbm to be used

2) Given that FF3 already increased the minimum platform requirements on Linux, is there any reason to continue shipping .xbm versions?

Large icons for OS X are covered in bug 348047, and for Vista in bug 340976.
Well, as far as I know FF3 will require at least GTK 2.10. I don't see a reason why a half-way recent system should require xpm. 
Depends on: 410215
While looking at bug 410215, I realized why I wasn't seeing the pixelation I was expecting... default.xpm is 48x48 with 1-bit transparency, but when it's scaled down to 16x16 the scaling is (presumably) smoothing out the hard transparency.
Bug 410215 landed, so "default.xpm" and "default16.xpm" can now be replaced. The patch added support for default.png, default16.png, default32.png, and default48.png. Some or all may be dropped in as replacements.
Depends on: 412049
It would not fix issue of blurry icons, because program which wants to show icon should decide, what size it wants to use, not Firefox should decide.

-1 for shipping icons with Firefox in his directorys
+1 for shipping icons like other do (in /usr/share/icons/hicolor)
And it Firefox would ship icon in hicolor icon theme's dir, it would use just "firefox" icon from current icon theme (it would make Firefox integrate better with Linux).
O, it's has been said here already. Sorry...
This is basically just a cut'n'paste of the changes made in bug 412049. Where ever it changed "default.xpm" to "default16.png", I added a line for "default48.png".

I'll request review one I've actually tested this. :-)
Assignee: nobody → dolske
Attachment #289797 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attached file 48x48 icons
I wonder why you only do 16px and 48px sizes though GTK recommends "16x16, 32x32, 48x48 at minimum" in http://library.gnome.org/devel/gtk/2.8/GtkWindow.html#gtk-window-set-icon-list - any specific reason?
I think all sizes (16, 22, 24, 32, 48, scalable) should be shipped and placed in hicolor icon theme.

No hardcoded pixmaps should be used, for example because of accessibility reasons (overriding icons eg by highcontrast icon theme is good for some groups of people).
We are getting brand new artwork from Jon Hicks (creator of the original Firefox icon) late this week so we can make the beta 3 code freeze.

While the Firefox icon does scale pretty well, Jon goes to the work of pixel polishing every resolution to give it an extra level of finish, and it really does make a difference.  For OS X and Windows we are producing the icon at the following resolutions:

512, 256, 64, 48, 32, 16

I unfortunately don't know anything about how application icons are packaged on Linux, just to confirm 22x22, and 24x24 are standard sizes that we need to support?  Am I missing any others?

>If possible, also provide a scalable version of the logo in SVG format. This
>would fix the look of the Application launcher in the menu.

I believe Jon is doing all of his work in illustrator, so providing an svg file shouldn't be a problem.
forgot 128 above.  Also, are we actually going to ship with an svg icon, or did you simply need that to create a higher resolution rasterized version (in which case we can give you a png at any size you need, to make sure we aren't losing color profile information or anything else is going wrong).
Alex, bug 410215 does only allow us 16/32/48px icons - 22px or 24px sizes or SVGs might be often used but apparently not are not in the recommended formats/sizes of GNOME, as seen in the URL in comment #16
GNOME can accept SVG happily and we should use that. To set an icon you need a GTK pixbuf and one can easily convert an SVG to that since SVG is treated as any other image type within GTK.

I can probably modify patch in aforementioned bug to accept the SVG if you want.
>GNOME can accept SVG happily and we should use that.

Is the GTK pixbuf vector or raster?  If vector, does it use the vector representation for every size, or just sizes larger than the ones we have specified pngs for?

Sorry about asking so many questions, I just want to make sure that we are leveraging icons that have been polished for specific resolutions when we can.  
(In reply to comment #22)
> >GNOME can accept SVG happily and we should use that.
> 
> Is the GTK pixbuf vector or raster?  If vector, does it use the vector
> representation for every size, or just sizes larger than the ones we have
> specified pngs for?

Raster, but pixbufs can be any arbitrary size so it will render the SVG at any size we want. Conversion between the SVG and pixbuf happens at runtime.

We can specify raster images instead of an SVG. GTK has a function that can automatically detect which is the best pixbuf to use at a given size. At a minimum we need 16x16, 32x32 and 48x48.
>GTK has a function that can automatically detect which is the best pixbuf to
>use at a given size.

Ok, so it sounds like we want to do that, and specify png files that have been modified to look perfect at particular resolutions, so that it will default to those before it uses the svg representation to generate a rasterized icon.

Does GNOME use the svg representation for resolutions between specified ones, like 36x36 or 18x18?  The reason I ask is that the source svg is a rather complicated image (in particular the fur has more detail), and while it will work great for anything larger than 128x128, I'm not sure we necessarily want to leverage this raw source material for very small sizes.
I'm not sure what happens in that case.
(In reply to comment #16)
> I wonder why you only do 16px and 48px sizes though GTK recommends "16x16,
> 32x32, 48x48 at minimum" in

Mostly just because it's to fix the immediate regression by only having a 16x16 version, as dbaron noticed in bug 413293.

I also have a small concern about the performance impact of adding more icon sizes -- we feed them to GTK every time a window is opened. The switch from XPM to PNG saved about 10ms / 5% on our Txul benchmark [the XPM decoding was clearly braindead, but the point is that it's not free.] Adding just one size back will help quantify the cost.

I think there's also some confusion here about *which* icons we're talking about. I've been assuming we're talking about the icons used in the window, but looking back it seems people might also be talking about the application icon (eg, as used in a launcher). That's a different issue (and an another example of why 1 issue per bug is a good rule!). I'd suggest spinning off another bug for the application icon.
>I'd suggest spinning off another bug for the application icon.

filed bug 413607
Yes, there has been some confusion around here ;)

The link above that stated "16x16, 32x32, 48x48" as the required sizes was just covering the window/switcher/pager icon. Ideally, those would be icons found in the hicolor theme and FF would pick the right size automatically.

For the launchers, 22x22/24x24 is indeed the most important size as this will be what most people see (see bug 413607).

As for using SVG or PNG... GNOME normally uses PNG, SVG (of available) is normally only used for scaled-up images beyond 48x48. This could change in the future, as GNOME (like OSX) is going to ship hires artwork at some point.

For the window list icon it's save to go with 16x16 and 48x48 for now I think. Perhaps first check for a matching "firefox" icon in hicolor and just use those buildin icons as a fallback?
(In reply to comment #28)
> Ideally, those would be icons found in
> the hicolor theme and FF would pick the right size automatically.

This also sounds like fodder for a separate bug. :-)
Comment on attachment 298423 [details] [diff] [review]
48x48 icons, Patch v.1

Tested patch, works on my Solaris box. The icon in the alt-Tab switcher was blurry before this patch (was 16x16 upscaled), and now is not.

My switcher is showing a 32x32 icon, so it's actually displaying a scaled down version of the 48x48 version. [Same as is did before we just had the 48x48 XPM.]
Attachment #298423 - Flags: ui-review?(mconnor)
Attachment #298423 - Flags: review?(mconnor)
Comment on attachment 298423 [details] [diff] [review]
48x48 icons, Patch v.1

Also requesting review from bsmedberg since I'm adding the 48x48 icon for xulrunner too.
Attachment #298423 - Flags: review?(benjamin)
> This also sounds like fodder for a separate bug. :-)

So, lets file new bug, which could block this one (I know, you're very happy :> ).
Attachment #298423 - Flags: review?(benjamin) → review+
Attachment #298423 - Flags: ui-review?(mconnor)
Attachment #298423 - Flags: ui-review+
Attachment #298423 - Flags: review?(mconnor)
Attachment #298423 - Flags: review+
Nominating for blocking.
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Checked in the 48x48 patch/icons. Leaving bug open pending landing of 32x32 icons.

Checking in browser/app/Makefile.in;
  new revision: 1.144; previous revision: 1.143
Checking in browser/app/default48.png;
  initial revision: 1.1
Checking in browser/branding/unofficial/Makefile.in;
  new revision: 1.5; previous revision: 1.4
Checking in browser/branding/unofficial/default48.png;
  initial revision: 1.1
Checking in browser/installer/unix/packages-static;
  new revision: 1.146; previous revision: 1.145
Checking in other-licenses/branding/firefox/Makefile.in;
  new revision: 1.25; previous revision: 1.24
Checking in other-licenses/branding/firefox/default48.png;
  initial revision: 1.1
Checking in xulrunner/app/Makefile.in;
  new revision: 1.34; previous revision: 1.33
Checking in xulrunner/app/default48.png;
  initial revision: 1.1
Attachment #298423 - Attachment description: Patch v.1 → 48x48 icons, Patch v.1
I don't see any sign of perf regressions from adding the 48x48 icons, so adding the 32x32 icons now. rs=mconnor, same basic thing as the 48x48 patch, so no further approvals needed.
Checked in the 32x32 patch/icons.

Checking in browser/app/Makefile.in;
  new revision: 1.145; previous revision: 1.144
Checking in browser/app/default32.png;
  initial revision: 1.1
Checking in browser/branding/unofficial/Makefile.in;
  new revision: 1.6; previous revision: 1.5
Checking in browser/branding/unofficial/default32.png;
  initial revision: 1.1
Checking in browser/installer/unix/packages-static;
  new revision: 1.147; previous revision: 1.146
Checking in other-licenses/branding/firefox/Makefile.in;
  new revision: 1.26; previous revision: 1.25
Checking in other-licenses/branding/firefox/default32.png;
  initial revision: 1.1
Checking in xulrunner/app/Makefile.in;
  new revision: 1.35; previous revision: 1.34
Checking in xulrunner/app/default32.png;
  initial revision: 1.1
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
I think the smaller sizes also should be shipped, because now we'll see blurry icon in menus (16x16 or 22x22 or 24x24).
I have 16px, 32px and 48px versions in my icons/default/ directory with today's nightly. 22x22 and 24x24 (22px+1px border) should also be in this directory.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Bug 413607 is for shipping additional sizes of the application icon, as a convenience for those who want to use such icons in launchers/menus/etc.

This bug is only for the window icon. See bug 410215 comment 2, and what I said here in comment 26 about keeping bugs narrow in scope. (Which I thought you were agreeing to here in comment 28). So this bug seems fixed: we're not using the single-sized XPM, and we have separate icons for the recommended 16x16, 32x32, and 48x48 cases.
Summary: [linux] Ship and use different sizes of the Firefox icon → Ship and use different sizes of the Firefox window icon
Firefox should be supporting up to 128x128 on Linux, else it still looks blurry on KDE4 with 48x48.
Reclosing this (blocker) bug as explained in comment 39. Work here is done: use bug 413607 for discussion of the application icon's icon (eg, as used in a launcher). If there's a need for yet more window icon sizes, that should happen in a new bug -- not this one.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Depends on: 423426
Could someone confirm the exact set of sizes we need for linux, we are in the process of creating a new application icon and I want to make sure we get pixel polished versions in all of the sizes that we need.
Recommended sizes for the launcher: 16x16, 22x22, 24x24 (=22x22 + 1px border), 32x32, 48x48. "Nice to have" would be a highres version (256x256 on GNOME, and/or 128x128 for KDE iirc)
http://library.gnome.org/devel/gtk/2.8/GtkWindow.html#gtk-window-set-icon-list says "Recommended sizes to provide: 16x16, 32x32, 48x48 at minimum, and larger images (64x64, 128x128) if you have them." and bug 410215, guided by that, added only support for 16x16, 32x32 and 48x48 sizes for window icons in Mozilla apps.
We may want to provide bigger/other sizes for distros to use somewhere, but for window decorations, we are currently not able to use anything else than 16/32/48.
(In reply to comment #44)
> We may want to provide bigger/other sizes for distros to use somewhere, but for
> window decorations, we are currently not able to use anything else than
> 16/32/48.

...which is totally fine but for launchers 22/24 is critical.

As I pointed out, as long as we set the icons through our own GTK support, we only support 16/32/48, but distros might like 22/24 or >48 versions . Note that we don't ship them in the standard distro locations ourselves, so it might be nice to have them available, but we won't use them ourselves (for technical reasons, see bug 410215).
(In reply to comment #46)
> As I pointed out, as long as we set the icons through our own GTK support, we
> only support 16/32/48
It's a one-line change to add additional sizes:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/gtk2/nsWindow.cpp&rev=1.264&mark=1350#1336
Blocks: 437374
No longer blocks: 437374
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.