New issue
Advanced search Search tips
Starred by 19 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Sign in to add a comment

Font antialiasing flip-flops according to subpixels when resizing window

Reported by, Oct 23 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Load up
2. Look very closely on fonts or icon fonts as you slowly resize the browser window horizontally
3. For every 1 pixel the window becomes smaller, antialiasing of all fonts on the page shifts

What is the expected behavior?
Antialiasing of fonts shouldn't shift when resizing the browser window.

What went wrong?
It's probably overzealous centering math. A 10px wide box can be perfectly centered in a 100px wide window, and align to whole even pixels, but it can't be perfectly centered if said window becomes 99px wide.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes I've only just noticed it now, but I'm really into removing fuzz from icon fonts so I'm confident it used to work

Does this work in other browsers? Yes 

Chrome version: 38.0.2125.104  Channel: stable
OS Version: OS X 10.10.0
Flash Version: Shockwave Flash 15.0 r0

The issue is most noticable when looking at icons from icon fonts. As such, the effect should also be easily visible on But obviously it affects text too — it's just less jarring with text.
72.7 KB View Download

Comment 1 by, Oct 23 2014

Paul Irish sent me a couple of older builds of Chromium to test, and the bug was present also in Chromium M37. The M36 build I tested on was fairly crashy though, but I wasn't able to reproduce the issue here, so presumably this bug wasn't an issue in the stable channel in mid-august. 
Labels: Needs-Feedback
Can you please help me to understand the issue in a better way, followed the below steps on chrome canary version 40.0.2204.0 for MAC Book Retina 10.9.5

1) Navigated to URL:
2) Observed the icons and Zoomed the page, Resized the browser as well. Did not observe any issue with the icons.

Please correct me if I am wrong.

Attached a screen shot for the same.
Screen Shot 2014-10-30 at 2.34.13 PM.png
15.3 KB View Download

Comment 3 by, Oct 30 2014

You can't see it on a retina screen, the issue is on a non-retina 1x resolution screen. 

Try these steps, which use a different icon set that may make the effect more visible.

1. Use a non-retina computer, such as a Macbook Air or a PC.
2. Navigate to URL
3. Don't zoom the browser page, only resize the window horizontally — very slowly. 
4. When looking very very closely at the screen, observe how the rendering of each icon.

In addition to affecting icons from icon-fonts, it also affects text, but only when centered. For example, observe the "Powered by Google Project Hosting" text at the bottom of this very page, now horizontally scale the browser down very very slowly on a non-retina screen, and you'll see the antialiasing change for every pixel the window becomes smaller. This is not the intended behavior, and you will not see it in Firefox, Safari, other browsers.

Comment 4 by, Dec 10 2014

Would love this ticket acknowledged somehow, Github is looking terrible depending only on the width of your browser window. 

See the two attached screenshots again, it shoudl be clear one lock is blurry and the other is not. 

Again, this happens ONLY in Chrome, and ONLY on a non-retina screen, and ONLY for fonts and icon fonts that are horizontally centered on a screen, like most websites are these days. 
5.4 KB View Download
5.6 KB View Download

Comment 5 by, Jan 7 2015

I can confirm the issue on Mac Chrome 39.0.2171.95, Thunderbolt display.
Attached file.
9.0 KB View Download

Comment 6 by, Jan 16 2015

I recorded some videos of the phenomenon to explain it. Remember, you only see it on non-retina screens!

Here's how a Github lock icon (which is from the Ocicons icon font) looks when the window is slowly resized horizontally:

Here's how it looks in Safari, which does not have this bug:

Note how in the Chrome video, the antialiasing of the icon font changes for every single subpixel size value, whereas in Safari the antialiasing doesn't change because the width isn't calculated on the subpixel but on the whole pixel.

Comment 7 Deleted

Comment 8 by, Feb 9 2015

Here's an animated GIF showing a horizontally centered "Uploading" message, and how it shifts antialiasing for every pixel the browser is resized.

Hopefully that should clarify it is a general font issue, not just an icon font issue.

REMEMBER! You can only see it on a non-retina screen!

Comment 9 by, Apr 9 2015

Is this being considered? I'm struggling with icons on my site that look really ugly when they're rendered on a 'half pixel'.
2.3 KB View Download

Comment 10 by, Jul 10 2015

Labels: -Cr-Content Cr-Blink
Labels: -Cr-Blink Cr-Blink-Fonts

Comment 12 by, Jan 14 2016

bump. same issue

Comment 13 by, Jan 22 2016

Labels: -Needs-Feedback Cr-Blink-Layout-Subpixel
Status: Available

Comment 14 by, Jan 22 2016

Tested again on Chrome/Mac 47.0.2526.111 (64-bit), still happening. 
Attached an animated gif.
6.3 KB View Download

Comment 15 by, Feb 24 2016

See my comment here for a screencast demonstrating this issue:

Issue number 570812 seems to be duplicate of this issue.

This bug affects all fonts, not just icon fonts. It's just easier to spot with icon fonts.

Comment 16 by, Feb 25 2016

GitHub addressed the issue on their article about changing to inline svg:

I've done the same a while ago. Svg does not have the issue of subpixel rendering and could be a possible fix.

Comment 17 by, Feb 25 2016

@comment15 That only means that there is a font rendering bug that needs to be fixed. Firefox doesn't have this issue. Chrome and Safari didn't have this issue in the past either.

Comment 18 by, Sep 17 2016

I can no longer reproduce this, could you please retest in the latest canary and report back?

Comment 19 by, Sep 17 2016

Just tried the latest Canary (Version 55.0.2863.0). The issue is still there.

See,output and zoom in on pixels to see the issue. I have attached a short screencast of the issue as well.

To zoom on pixels, you can either take a screenshot and then use something like Photoshop to zoom on actual pixels, or you can use OS X's zoom which can be enabled from System Preferences → Accessibility → Check "use scroll gesture...". Make sure to uncheck "Smooth Images".
3.5 MB Download

Comment 20 by, Sep 17 2016

Thanks for confirming. Is this on a retina or normal screen?

Comment 21 Deleted

Comment 22 by, Sep 17 2016

The issue is still present on both retina and normal screens.

On normal screens, you don't even need to zoom to see the problem.

Comment 23 by, Sep 19 2016

I highly doubt this has anything to do with fonts at all, but is instead due to the compositor taking an already rasterized layer and blitting it at a subpixel location (with what looks like gamma incorrect bilinear resampling). This is quite obvious from the images in comment #4 since in the blurry.png not only is the lock icon blurry, the lcd subpixel sampling (color fringes) on the text have obviously been blurred.

Comment 25 by, Sep 19 2016

Components: -Blink>Layout>Subpixel -Blink>Fonts Blink>Compositing
Changing component to Compositing for re-triaging?
Project Member

Comment 26 by, Sep 20 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit - Your friendly Sheriffbot
Labels: -Hotlist-Recharge-Cold PaintTeamTriaged-20170920 BugSource-User
Status: Available (was: Untriaged)
This bug was dropped because the component was changed without marking the bug as Untriaged.

Comment 28 Deleted

Comment 29 Deleted

Components: -Blink>Compositing Blink>Paint
I think this belongs to paint, as there is no compositing layer in the repro.

This is not a simple problem though. If we simply snap the box of each LayoutText like everything else, it may have negative effects on text spacing I think (in worst case, some text will be up to 0.5px tighter in between, and up to 0.5px looser for some other text).

I'm thinking perhaps we should snap paint offset at block/inline boundary so that inline layout objects will get a consistent fractioanl paint offset regardless block location, while still accumulate subpixel layout internally.
Snapping at block/inline boundary might work. Prototype it?

Sign in to add a comment