404402 - Ship and use different sizes of the Firefox window icon

Status: VERIFIED FIXED

(Firefox :: Shell Integration, enhancement, P2)

Description

[Michael Monreal [:micmon]]

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

Comment 1

[Andrea Cimitan]

I totally agree... and in addition a tangoish version will look much better now that we will have a tangoish linux build

Comment 2

[Samuel Sidler (old account; do not CC)]

I don't see any obvious dupes so confirming this as a valid RFE.

Comment 3

[Justin Dolske [:Dolske]]

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?

Comment 4

[Michael Monreal [:micmon]]

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).

Comment 5

[Michael Monreal [:micmon]]

Attachment: Graphically show what I just explained

Comment 6

[Michael Monreal [:micmon]]

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.

Comment 7

[Justin Dolske [:Dolske]]

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.

Comment 8

[Michael Monreal [:micmon]]

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. 

Comment 9

[Justin Dolske [:Dolske]]

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.

Comment 10

[Justin Dolske [:Dolske]]

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.

Comment 11

[u294409]

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)

Comment 12

[u294409]

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).

Comment 13

[u294409]

O, it's has been said here already. Sorry...

Comment 14

[Justin Dolske [:Dolske]]

Attachment: 48x48 icons, Patch v.1

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. :-)

Comment 15

[Justin Dolske [:Dolske]]

Attachment: 48x48 icons

Comment 16

[Robert Kaiser]

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?

Comment 17

[u294409]

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).

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 19

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 20

[Robert Kaiser]

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

Comment 21

[Michael Ventnor]

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.

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.  

Comment 23

[Michael Ventnor]

(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.

Comment 24

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 25

[Michael Ventnor]

I'm not sure what happens in that case.

Comment 26

[Justin Dolske [:Dolske]]

(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.

Comment 27

[Alex Faaborg [:faaborg] (Firefox UX)]

>I'd suggest spinning off another bug for the application icon.

filed bug 413607

Comment 28

[Michael Monreal [:micmon]]

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?

Comment 29

[Justin Dolske [:Dolske]]

(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 30

[Justin Dolske [:Dolske]]

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.]

Comment 31

[Justin Dolske [:Dolske]]

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.

Comment 32

[u294409]

> 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 :> ).

Comment 33

[Alex Faaborg [:faaborg] (Firefox UX)]

Nominating for blocking.

Comment 34

[Justin Dolske [:Dolske]]

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

Comment 35

[Justin Dolske [:Dolske]]

Attachment: 32x32 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.

Comment 36

[Justin Dolske [:Dolske]]

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

Comment 37

[u294409]

I think the smaller sizes also should be shipped, because now we'll see blurry icon in menus (16x16 or 22x22 or 24x24).

Comment 38

[Michael Monreal [:micmon]]

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.

Comment 39

[Justin Dolske [:Dolske]]

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.

Comment 40

[İsmail Dönmez]

Firefox should be supporting up to 128x128 on Linux, else it still looks blurry on KDE4 with 48x48.

Comment 41

[Justin Dolske [:Dolske]]

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.

Comment 42

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 43

[Michael Monreal [:micmon]]

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)

Comment 44

[Robert Kaiser]

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.

Comment 45

[Michael Monreal [:micmon]]

(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.

Comment 46

[Robert Kaiser]

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).

Comment 47

[Steffen Wilberg]

(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