The developers decided that the extension icons should have the same size as the built-in browser icons (16x16px), see  https://crbug.com/546206  It was an arbitrary decision, not based on any real needs or design requirements. Now they ignore and close all reports that state the obvious decrease in legibility/readability/quality of the icons, labeling them as WontFix, and I bet it'll be the trend for at least several years, so let's brace ourselves and buy glasses.

Looking at the in-depth MD redesign article on https://medium.com/@KounterB/redesigning-chrome-desktop-769aeb5ab987 it's quite obvious that all important decisions were finalized without taking extension icons in account. Then with the release date drawing near the designer suddenly realized that 19x19px icons of extensions don't fit in the new idealized scheme. The only solution was, naturally, to reform the 'non-essential' 3rd-party stuff: extension icons. 'Non-essential' based on some statistics showing that majority of Chrome users don't use extensions much, I guess, otherwise it's hard to explain why such violation would be allowed as anyone who has eyes can see the obviously reduced quality.

I think this is bad enough to be worth fixing.

Here's a better comparison showing the difference in legibility before and after MD:
Before: http://i.imgur.com/3dZky8X.png
After: http://i.imgur.com/YhDIcRS.png

 Bug 613576  was about this and marked Fixed, but has problems.  Given the screenshots above, we clearly use less vertical space than before even with the fix -- how did the old code compute the size?  Can we do something similar?  The new font also uses 1-px-thick strokes, which makes it far more difficult to read.  For a tiny badge like this, we should consider a style change in addition to a size change.  Finally, it suprises me that we don't have any mechanism for getting the largest font that will fit within a given vertical space, and the solution in the CL on that bug, which increments by 1 up to 5 times, makes me uncomfortable.  FontList::DeriveWithHeightUpperBound() is already very close to this, so maybe we could generalize that a bit (and possibly improve its efficiency?).

I'm going to assign this to Evan since he worked on the previous bug here, but we may need designer input here.

 Issue 617362  has been merged into this issue.

 Issue 623140  has been merged into this issue.

So glad to see someone is finally working on this one! Looking forward to seeing it fixed.

> getting the largest font that will fit within a given vertical space

that's not sufficient, we want the largest font that will fit within a given vertical space *for a specific string*. The difference is caring about the tallest character in the font vs. the tallest character in the font that actually appears in the string. This is the reason for that loop.

I honestly don't see a huge difference in the legibility in the screenshots pkasting posted. The 27 seems clearer in MD. The 3 is not as legible as the 4, but then they are different characters.

over to Devlin. +sgabriel for aforementioned designer input.

An (external) comment on legibility remarks in #7.

I agree than 27 wasn't very legible before, but the reason for that seems to be poor contrast at the top with the badge being gradient-shaded. With MD that is no longer an issue.

I would say there are 2 problems with MD badges

1. The font used is very thin. Even on relatively high-DPI devices the glyphs are ~1px wide, and that doesn't seem to improve with scaling. The old badges had significantly bolder glyphs that were easier to read.

2. An issue I raised at  Bug 613576 : the whitespace around the text seems uneven, and larger than necessary, which contributes to being poorly readable. It's still reproducible for me on Windows with Canary, while on Linux this seems okay.

Attached a 2x scaled screenshot, Windows on the top, Linux on the bottom.

Deleted: badge_win_linux.png 17.0 KB

	badge_win_linux.png 17.0 KB View Download

>Before: http://i.imgur.com/3dZky8X.png
>After: http://i.imgur.com/YhDIcRS.png

Let's look at the bounding box of "27" (white and whitish pixels on the smoothed edges):

Before: 11x9 px (99 pixels), font has strokes 1.5-2px wide with a pronounced 1px white core plus ~1px of antialiased edges
After:   9x6 px (54 pixels), font is 1px thin, even less perceptually since the strokes are smudged by subpixel antialiasing

The spot occupied by the text became nearly two times smaller.
The objective numeric difference is huge. 
The perceptual difference is also huge as observed on a high quality Dell U3011 display.

>I honestly don't see a huge difference in the legibility in the screenshots pkasting posted.

It may be caused by the hardware used by #7 e.g. a display that oversharpens everything thus neglecting the visual difference, or due to some other influence.

I am running my chromium on Linux with option "--force-device-scale-factor=1.2" because of this bug. And even though - it is extremely difficult to see the numbers on the icons.

Check this screenshot I am attaching - It is difficult to recognize if the displayed digit is 1 or 4 or maybe even 7. Without --force-device-scale-factor=1.2 it is totally impossible.

Deleted: small-icons.png 4.4 KB

	small-icons.png 4.4 KB View Download

 Issue 674586  has been merged into this issue.

I'm escalating this to P1.  I continue to hear significant feedback that this is a serious accessibility issue, and I believe it.  The screenshot difference in comment 3 seems egregious.  This is my #1 concern about top Chrome MD.

I'm not sure devlin@ is the right assignee here.  This isn't really an extensions system issue.  I think we need UI design agreement that this is a problem, but mostly engineering ownership to change it.

->bettes for design considerations.  Please see screenshots in comment 3.  The basic questions are:
* Is there a problem?  If no, stop.
* Do we need to increase the size of the badges, or can we just make fonts more legible in the current badge size?
* If we need to increase badge size, how much?  Do we also have to bring back into question the overall sizes of extension icons?
* If we only need to make fonts more legible, are there recommendations for how to do that?

My personal take on the above is: leave extension icon sizes alone, leave badge sizes alone (they were the same height before MD), change font drawing back to something like what it was pre-MD (I don't know, technically, exactly how the fonts were drawn).

> leave extension icon sizes alone

I don't want to get *too* offtopic, but it's worth noting that MD shrank all the icons from 19x19 to 16x16, so extension developers had to redesign their icons to make them not-blurry.  Based on the screenshots above, few have actually done so.

@13: Acknowledged, but I'm going to leave that issue alone in hopes of not derailing a potential fix for this one :)

This is tricky. The legibility of the badge is going to inevitably be different depending on your hardware resolution, your OS's system typeface, and the color badge the extension chooses to use. 

I'd advise us to first start by experimenting with a bold font-weight before investigating alternate badge and icon sizes. That should have a notable ROI. 

Feel free to assign back to me for review. Thanks! 

@rpop, can you help find someone to do the engineering work here?  This is a significant a11y issue (see screenshots in comment 3) and based on comment 15 I think the right thing to do is to investigate how we drew text in these badges pre-MD and try to restore that text-drawing algorithm as much as possible, without touching the badge/icon sizes for now.

Some people who are probably capable of doing this: estade, bsep, pkasting, msw?

I agree that this is an a11y regression and we should fix it. Evan, since you're most familiar with this area, could you try out the plan in #15 and post screenshots for bettes' review?

(It would be nice to understand how the pre-MD code here rendered this typography to know whether returning to that rendering is feasible or not)

If the cross-platform font renderer is not able to emit digits within a pixel-perfect boundary, then I would suggest storing them as sprites instead.  You really need to hoard every pixel when working in such a small space.

The screenshot from #10 looks like the badge rectangle itself is getting downsampled...

To #19: It's important to remember that badges support arbitrary text and not just digits.

if the plan is to use bold font, this is the line you need to change:
https://cs.chromium.org/chromium/src/chrome/browser/ui/extensions/icon_with_badge_image_source.cc?rcl=7b36c43b8d390438422b8fcaaeaf97cb15f8e625&l=125

I don't think I'll be able to work on this soon.

Is it possible to confirm that the badge and its text are always rendered *after* the canvas has been scaled to its final output resolution (assuming that such scaling exists)?

Perhaps, for testing purposes, you could draw a small checkerboard pattern on the badge, and then watch whether the pattern appears intact.

I would like to get this fixed. +extensions team folks to see if someone can take this on

Here's what I'm seeing on my system (running Linux). As many others have stated, it's illegible more often than not (depending on which characters are shown in the badges).

Deleted: 2017-04-24_04-34-32-AM.png 5.8 KB

	2017-04-24_04-34-32-AM.png 5.8 KB View Download

Assigning to catmullings@ to take a look.

This will likely be as much a UX issue as an eng issue; bettes@ do you have the bandwidth to iterate with us on this?

@28: We've already gotten initial design direction from bettes@ in comment 15.  This is purely engineering work at this point.

(Also I'm happy to help do some of the iteration from the design side here to save designer bandwidth, I feel like I have a good enough handle on this problem to get us to a "this looks good, is it OK to ship" point.)

Since it's been awhile, may I ask if there has been an update to this?  Been waiting to update my Chrome since this happened.

It's become better. The font is still thin but it's bigger when the badge text is one character in length thus easy to read. 

If there hasn't been an update on the bug, there's no update.

@32 - Still appears the same to me on my laptop.  I'll have to test it on my desktop as well.
@33 - My apologies.  I'll wait.  Didn't know what the etiquette was and it seemed like it was close to being fixed back in #30.

@33: No apology necessary, but I forgive you :).  Sorry for the disappointing news :(

Ping - how is this work coming along? 

Taking a look...

Going bold seems reasonable. Let's go with that as a quick fix if there are no other objections

Deleted: Comparison.png 1.0 KB

	Comparison.png 1.0 KB View Download

I still think what I said in comment 16/18 ("it'd be nice to understand what we did before") is true so we have some idea of whether this is actually a sufficient fix... but for the fix itself it may be right and is certainly a good first step per comment 15.

@45: Agreed it would be nice to fully understand what was going before, but this appears to be a reasonable improvement, even if it's later determined to be imperfect.

This is especially the case given that this bug has not seen any actual code action since it was opened.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2433d79ee698e74733485dc93917ed539e14dd46

commit 2433d79ee698e74733485dc93917ed539e14dd46
Author: Robert Liao <robliao@chromium.org>
Date: Thu Jan 17 18:48:57 2019

Make the Badge Text Bold

As a quick fix, this change makes the badge text bold to make it easier
to read and make it more in line with the pre-Material Refresh style.

BUG=649054

Change-Id: I4b709fc7a7fa7445bc546ff02afb1c6f7e2f12c2
Reviewed-on: https://chromium-review.googlesource.com/c/1410276
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Commit-Queue: Robert Liao <robliao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623770}
[modify] https://crrev.com/2433d79ee698e74733485dc93917ed539e14dd46/chrome/browser/ui/extensions/icon_with_badge_image_source.cc