User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Open browser activate Proton Styling
Try shifting between different scaling options in Windows 10
Preferences > System > Display > Scale and Layout
Observe the icons

Actual results:

Despite the fact that SVG is used, Proton icons appear to be blurry/withShadow with 100% (recommended) scale (Resolution 1920*1080, 24" monitor).
Blurriness seems to be gone when scaling is raised to 150% or above.
With the same setting competitor browsers (with similar icon styles) do not suffer from this effect.
Pre Proton icons are also sharp with any Scaling option

Expected results:

Icons should be sharp with any selected scaling just like with Pre Proton icons.

The Bugbug bot thinks this bug should belong to the 'Firefox::Theme' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Hi,
The new Proton icons have landed recently, and they are also affected by the issue
See new comparison of Proton vs Release

If this is reproducible in release, then this isn't proton-icons related. It sounds more like a graphics issue?

Quick fly-by comment, but I noticed the new icons landing on m-c and I saw some mistakes in the source files.

The icons look blurry because they're not properly hinted to the pixel grid, so even if they're SVG, no matter how many pixels you have in your HiDPI monitor, they will always gonna render with blurred edges.

Apologies if this issue is already known.

If this is reproducible in release, then this isn't proton-icons related. It sounds more like a graphics issue?
Release doesn't have Proton icons. I have added a screenshot of the current release icons vs nightly Proton icons

(In reply to Alessandro Castellani [:aleca] from comment #5)

Quick fly-by comment, but I noticed the new icons landing on m-c and I saw some mistakes in the source files.

The icons look blurry because they're not properly hinted to the pixel grid, so even if they're SVG, no matter how many pixels you have in your HiDPI monitor, they will always gonna render with blurred edges.

Is there a specific example you can point to :aleca? I'm looking into this but there are a lot of icons to check and svg paths are not always very human readable. So far with the spot checks I've done I've not seen this issue.

I didn't look at the SVG markup (that's indeed super duper complicated :D), but I opened a couple of icons in Inkscape and enabled the pixel grid.

As you can see the new icons are not hinted to the grid, which it translates to a blurry and pixelated icons when rendered in the browser.

Below is the Photon icon, which is correctly hinted to the grid, and it doesn't produce those ghost pixels (except for the rounded corners, but that's a known tradeoff).

The blurriness is due to anti-aliasing kicking in when the edge of the icon only partly covers a pixel, and the browser approximates that partial coverage by drawing a semi-translucent pixel.

This is that add.svg icon on a 16x16 noise grid so we can see the pixels, magnified several times. It seems to be aligned on the grid to me. This is on ubuntu fwiw, I'm not sure if we use different graphics backends on windows that would have an impact on this.

Jeff, could anything in Graphics be causing this? I checked with image-rendering: crisp-edges; and there is no change. Just want to make sure that it is an issue with pixel-grid alignment inside of the SVG and not something else?

I'm still struggling to reproduce this. I've tried 100%, 125% and 150% scaling on Windows 10, different themes .. and I'm not seeing the blurry icons. I'm on a thinkpad (i.e. not a high-density display) What are the other variables here that I'm missing?

I understand the concept of pixel grid alignment, and I can see that some strokes/paths are not locked in to that grid - in-part due to the lighter stroke width that characterizes the new icon style. But the rendered result still looks sharp to me.

I'm still struggling to reproduce this. I've tried 100%, 125% and 150% scaling on Windows 10, different themes .. and I'm not seeing the blurry icons. I'm on a thinkpad (i.e. not a high-density display) What are the other variables here that I'm missing?
Hi here,
The icon color is less dark for you, maybe this is due to the selected Firefox theme (Light). Try setting Customization > Theme > System Theme.

:Serge, can you tell me more about the screenshots from comment #3. I see the first is visibly sharper than the 2nd. I assume the 2nd image is of Nightly. Is this using the System Theme? The high contrast in the first image is a bit confusing - is this using a non-default (lwt) theme? On release and pre-proton, icon opacity was ~80% except for lightweight themes, but that looks like 100% black to me.

Hi Sam,
Here is the explanation (from top to bottom)

1. Nightly, System theme, 100% Windows scale
2. Nightly, System theme, 150% Windows scale
3. Release, System theme, 100% Windows scale
4. Release, System theme, 150% Windows scale

All in all the settings on Nightly and Release are the same

All of them use Compact density (within Firefox), but the blurriness is the same for any density
If needed here is another screen from the latest nightly

Ok thanks that's great. Some of the updated icon haven't landed yet, so we have to ignore downloads, shield and reload. Having that mix is certainly making evaluating this more difficult, and that will get better as these pieces land over the coming days.

I have to say, to me at least, the top 2 there - nightly at 100% scale and nightly at 150% scale look sharper and all around better than the 2 below of release Fx. I will look at the appmenu icon (hamburger) more closely as that doesn't look as sharp as I would expect, but the others look pretty good.
Lets see what UX says, but I'm for "WORKSFORME" at this point.

It's not just the menu icon, but the blurriness is easier to notice in zoomed in screenshots when the icon has straight lines. Just zooming in reporters images might not be enough to see the blurriness, though. It depends on how you zoom in. So, just to make sure everyone sees the same result, you can open the image in GIMP, and scale it to an integer multiplier (eg. 1600%) without interpolation. I'll attach the result of the menu icon.

(In reply to Sam Foster [:sfoster] (he/him) from comment #16)

Ok thanks that's great. Some of the updated icon haven't landed yet, so we have to ignore downloads, shield and reload. Having that mix is certainly making evaluating this more difficult, and that will get better as these pieces land over the coming days.

I have to say, to me at least, the top 2 there - nightly at 100% scale and nightly at 150% scale look sharper and all around better than the 2 below of release Fx. I will look at the appmenu icon (hamburger) more closely as that doesn't look as sharp as I would expect, but the others look pretty good.
Lets see what UX says, but I'm for "WORKSFORME" at this point.

Hi Sam,
Already landed Proton-ready icons are not as sharp as their predecessors from release.
Please have a look at icons (100% scale) that have straight lines (horizontal lines in Back, Forward and Hamburger button).

On Nightly they are thinner but not sharper.
On the Release they are thicker and sharp at the same time.

New icon design relies on very thin lines, because of this it is hard to align them with pixel grid.
Maybe it was developed/designed on a very High pixel density display/monitor and wasn't noticed earlier.
However, icon sharpness is achievable, Microsoft EDGE does that nicely (icons are thin and sharp at the same time)

Also, when playing around with the following CSS rule I can "somewhat" achieve sharpness for the Back, Forward icons.
toolbar .toolbarbutton-1 > .toolbarbutton-icon {
height: changing it from 25px to 30px;
}
I am not an expert, but does sound like it is connected to the subpixel alignment within the SVG...
So with some effort the fix should be doable.

Taking into account that the main issue is that this affects Default 100% scale I am against "WORKSFORME" status

Can you attach your about:support contents? Can you also generate a memory report at about:memory and attach it to the bug at the 100% (bad?) and 150% (good?) scaling cases? Check the verbose box please so that we get small icons. If you get WebRender, can you force disable WebRender via gfx.webrender.force-disabled, does the problem persist (our SVG rendering paths are slightly different, and I wonder if there is a bug in that path)?

ni-ing tnikkel in case he has more ideas.

Hi here,
Flipping gfx.webrender.force-disabled visually does not give any changes.
Attaching the requested files (Scale 100%, 150% and WebRender On-Off).

I'm not sure, maybe the proton is causing the offset of these images to be slightly non-integer aligned?

From the memory reports, we aren't generating off-by-one rasterized versions of the SVGs which was my initial fear (e.g. instead of 16x16 at 100%, and 24x24 at 150%, I was wondering if we managed to get 16x15, which could cause distortion). Given it still happens with non-WebRender, this suggests it wasn't an oversight in the newer WR display list generation code.

I'm lowering priority here given that this won't be a MR1 blocker. Next step is analyzing feedback from diary studies to better understand if users notice an issue here.

Hi today icon color change had landed on Nightly.
Toolbar icons are now gray instead of black.
As a result it is literally hurt eyes to concentrate on a thin gray silhouette on a white background.

@Serge: Did you not update your Nightly build for several days? Your "before" and "after" screens show different icons (look at the reload or tracking protection icon for example) and that didn't land today. Also I am pretty sure that in your second screen the back and forward button are disabled (they have a much lighter color than your other icons) and that's not the case in your first screenshot. So it's not really suited as a comparison for a color change in today's Nightly.

@Sören,
I do not screenshot Nightly each day.
Because of this I used an earlier screen that did have black icons and compared it to todays Gray-ones.
Comparison shows overall change.
As for the Back-Forwad, yes they are disabled (and are lighter) but apart from them there are other icons that can be compared.

This may be same as my: https://bugzilla.mozilla.org/show_bug.cgi?id=1704300
Not sure about this: https://bugzilla.mozilla.org/show_bug.cgi?id=1707122

Hi,
Are there any updates on this bug?

It's not only icons. Look at the play indicators on tabs. The "I" of "playing" looks like it's taking 3 pixels.
In "picture-in-picture", only the "E" and the right side of "-" aren't glued to the other letters.

And the new spraker icon is way too small and I don't understand anything waht is compared to old one.

I didn't see a good summary of the issue and its cause in the above comments, and as some of the input came while the new icons were landing reading through the comments doesn't make the issue and its cause particularly clear up to this point.

The old icons used a stroke-weight of 2px, the new icons use a stroke-weight of 1.25px. This is a deliberate choice by our designers, and it results in a lighter, modern feel that looks great for most people. The stroke-weight change means that the horizontal and vertical lines in the new icons will necessarily involve some sub-pixel rendering on normal/1:1 density displays, resulting in the reported "shadows". This too is normal. However, at some scaling values, and with some display hardware, there's a kind of resonance (dissonance?) which results in particularly bad results. As this is at least partly hardware related, the screenshots which purport to illustrate this actually look fine on non-affected hardware. Which makes a kind sense as the screenshot captures the pixels, not the result our eyes see. I think that explains some of the gap between the reporters' expectations and the reactions and prioritization of this bug.

I don't think there is a good short-term fix to be had here, and as so far it seems to affect relatively few people, its not something we should sink a lot of effort in to. The problems described aren't unique to these icons or Firefox, rather they are a known limitation of vector art when there's only a few pixels to work with. Perhaps an icon font would allow use to get the best of both worlds, with manual hinting for smaller pixel sizes, and smooth scaling otherwise.

@Sam

The old icons used a stroke-weight of 2px, the new icons use a stroke-weight of 1.25px. This is a deliberate choice by our designers, and it results in a lighter, modern feel that looks great for most people. The stroke-weight change means that the horizontal and vertical lines in the new icons will necessarily involve some sub-pixel rendering on normal/1:1 density displays, resulting in the reported "shadows". This too is normal

How come that distortion/shadows created by sub-pixel rendering is threatened as a normal behavior?
Did the designer have in mind this "shadow" effect?
In this case, why this effect is not present with Hi-Res displays/resolutions.

A side note: if the Shadow theory is valid then it is executed in a strange way: for some new icons shadow goes below the prime horizontal line, for others - above it which doesn't seem to be a consistent shadow.

Could you please specify what is treated as standard/normal density display by the designer?
I may be mistaken, but 24" IPS monitor with Resolution FullHD (1920*1080 with no scaling adjustments) seems to be pretty standard in terms of usage/prevalence.
Seems like during design stage, a single (and different) specs were used as a target audience, so not all resolutions were tested properly.
Something like Retina displays and/or 4K resolutions?

Could you or someone else confirm or deny the statement above?

I don't think there is a good short-term fix to be had here, and as so far it seems to affect relatively few people, its not something we should sink a lot of effort in to.

The conversation within this ticket (and duplicates of it) doesn't seem to be as minor as you state.

As for the fix, did devs try to use a stroke-weight of 1px instead of 1.25px and compare the result?

The competitor browsers managed to pull of "a lighter, modern feel" without any shadows, so there is no reason for Firefox to not be able to do the same

1. Is a good summary already of the problem.
2. If the old icons uses 2px, so make this again 2px
3. How is that modern if looks bad?
4. "This too is normal." - anything in the world is normal, but not necessarily good
5. "non-affected hardware" - Pretty sure is on any hardware. So I need that 4K monitor just too see that icons look good? Why I would need a 4K monitor anyway that a normal 1920x1080 just to dimming this problem?

"Which makes a kind sense as the screenshot captures the pixels, not the result our eyes see." - You say that eyes are not seeing what the display is displaying? I disagree this too.

"I don't think there is a good short-term fix to be had here, and as so far it seems to affect relatively few people, its not something we should sink a lot of effort in to." - I disagree with you there.

"The problems described aren't unique to these icons or Firefox, rather they are a known limitation of vector art when there's only a few pixels to work with." - How they are looking good before, what limitation was before? I disagree this too.

Why the style is not split on different display sizes and see what would look better and set that to them?
Or change them back, pixel perfect icons would look good on any display anyway.

(In reply to Serge from comment #42)

@Sam

The old icons used a stroke-weight of 2px, the new icons use a stroke-weight of 1.25px. This is a deliberate choice by our designers, and it results in a lighter, modern feel that looks great for most people. The stroke-weight change means that the horizontal and vertical lines in the new icons will necessarily involve some sub-pixel rendering on normal/1:1 density displays, resulting in the reported "shadows". This too is normal

How come that distortion/shadows created by sub-pixel rendering is threatened as a normal behavior?

The "shadow" is a soft line, similar to how a curve is rendered on a square pixel grid, the 1.25 weight results in a strong line in one pixel column/row, and a lighter shade next to it. That is expected behavior, and most people report it looks good. This bug is to understand why for a few people this results in an unacceptably blurry icon.

The competitor browsers managed to pull of "a lighter, modern feel" without any shadows, so there is no reason for Firefox to not be able to do the same

What is the info you need here? I'm not closing out this ticket, the problem remains and we'll follow this discussion while the bug remains open. I'm not going to second-guess our designers' decision and yes of course they tested the icons at different resolutions. I'm still open to suggestions on how to improve the outcome for more people on different resolutions and display hardware, but simply reverting to the old style is not on the table as an option. I would still like to understand more about exactly why the icons look fine for some people and really blurry for others - when they are ostensibly on the same display resolution. Perhaps a photo of the screen would better illustrate the problem vs. a screenshot.

Not a good phone. But with the eyes are more blurry and bad to them.

And the desktop one.

@Sam

The "shadow" is a soft line, similar to how a curve is rendered on a square pixel grid, the 1.25 weight results in a strong line in one pixel column/row, and a lighter shade next to it. That is expected behavior, and most people report it looks good.

I do understand why this was done.
The main issue is that for Horizontal (and vertical) lines, the shadow effect appears in a wrong way.
See screenshot (top row - scale 100%, bottom - 175%).
Scale 100% - Icon 1, 2 and 9 has its "shadow" to the bottom. Let's assume this is normal.
Scale 100% - Icon 4 and 5 has its "shadow" above it. This straight leads to the Blurry effect (shadows can't be on top)
Scale 100% Icon 7 suffers most (its middle dot is barely visible), compare to the same icon with Scale 175%

Scale 175% mostly looks OK for all of the icons.

I'm still open to suggestions on how to improve the outcome for more people on different resolutions and display hardware, but simply reverting to the old style is not on the table as an option.

Comment 8 gave a pretty nice explanation how this can be fixed.
If you insist on the "shadowy" nature of this design decision, then Icons with the horizontal and vertical lines should be altered, so the shadow effect appears the same (to the bottom) for all the icons
OR
As a starting point, try to redraw a couple of "blurry" icons with 1px width and compare the results.

@sam
Here I have modified Icon 4.
I have shifted its shape 0.25px to the bottom.
When applied the shadow effect is now to the bottom (was on top before).
So to sum up: seems like the shapes within 16x16 pixel grid should always start with the full pixel and end with "half-pixel"
In this case, the shadow effect should always be on the bottom.

The severity field for this bug is relatively low, S4. However, the bug has 3 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1706382: S3

:Gijs, could you consider increasing the severity of this bug to S3?

For more information, please visit auto_nag documentation.