Text become fuzzy and unusable after scroll

[ghost]

• VSCode Version: 1.12.0 Insider
• OS Version: Windows 10 Version 1703

Steps to Reproduce:

1. Install it on a Hi-DPI screen device with 125% scale (May not require, it's my environment)
2. Paste some long code into editor
3. Take a screenshot without image compress
4. Scroll down mouse wheel by once, take another screenshot, or feel it with your eye

Screenshot

This is normal (clearly)

This is fuzzy

Screenshot with zoom

---

This is normal

This is fuzzy

Possible reason

I think it's an upstream issue with Chromium, if Code use CSS transform to scroll/move element will cause this issue.
I hope develop team can take a look with this, this make Code unusable at all

See also

• Symbol & Text may fuzz and unclear (Symbol & Text may fuzz and unclear #7799) [upstream, electron]

[bpasero]

@alexandrudima lets sync on this when we are both in the office, looks like a Chrome regression.

[alexdima]

@ArianeLu I am on a Surface Book with 200% scale and regardless of the scroll top position the editor font is rendered with subpixel antialising:

Sometimes, when changing the scale, I need to sign out and sign back in to Windows for all the apps to react to the change. Does signing out help in any way?

[alexdima]

Could you perhaps share your settings? (i.e. @bpasero @aeschli is it now possible users can define transparent backgrounds via themeing?)

[ghost]

@alexandrudima
Noting to share, It's fresh install, without custom settings.
If i changed screen scale, it should more fuzzy in all time, not just after scroll

My user settings:

{
    "workbench.iconTheme": "vscode-icons",
    "terminal.integrated.shell.windows": "C:\\WINDOWS\\Sysnative\\bash.exe"
}

#22336 (comment)
This commend author may have same issue

[bpasero]

I also did a quick test on my macBook pro both with my external monitor and the notebook screen and I am seeing subpixel antialising with any DPI scaling (100%, 125%, 150%). Would also like to understand what kind of setting could cause this.

Btw please only look at the editor and not anywhere else! We did loose subpixel antialising outside the editor but that is Electron unrelated (I can see this with 1.11 stable already).

[bpasero]

@ArianeLu when you say in your screenshot "this is fuzzy", it seems to me from that screenshot that subpixel antialising is still being used, can you clarify that is different from the screenshots and what produces the fuzzyness?

[ghost]

@bpasero Look the char "L" on two screenshot, as you say, it looks like subpixel antialising, but it was difficult to read on my external monitor (DELL P2416D).

The fuzzy looks like have a shadow around the char, I don't think subpixel antialising will cause text fuzzy like this one. Something maybe wrong...

I can't reproduce this issue on VSCode 1.10.2.
Also, 1.11.1 is not affected

Related Code:

Element with class .monaco-editor-background have inline attribute transform: translate3d(0px, -455px, 0px)

• translate3d(0px, 0px, 0px) - Good
• translate3d(0px, -1px, 0px) - A bit fuzzy
• translate3d(0px, -2px, 0px) - Unreadable
• translate3d(0px, -3px, 0px) - Better than -2px, but still unreadable
• translate3d(0px, -4px, 0px) - Good, text very clear

I can't find this attribute on .monaco-editor-background with Code 1.10.2

[ghost]

And this one

• Green text from left to right : top, translate -1px, translate -2px
• White text: Top position right side is after scroll

[ghost]

@bpasero Can you understand my description? Or any idea with my guess about the transform attribute?

[alexdima]

@ArianeLu

I think the root problem here is that Chromium decides to go to grayscale antialising on your machine/environment. Grayscale antialising is problematic exactly because, as you point out, it cannot correlate the font rendering with real screen pixels. Perhaps because it cannot correlate the layer's position with real screen pixels is why it goes to grayscale antialising in the first place.

If you believe it is due to our usage of translate3d, then there is an easy way to test that: use the setting "editor.disableTranslate3d": true in your settings. You should then observe all the editor dom nodes being positioned with top or left and no longer with transform.

[ghost]

@alexandrudima After add this options, text looks good.

[bpasero]

@alexandrudima here is an update from what I see after doing more testing with the editor.disableTranslate3d setting. I can confirm that there is a regression in subpixel-aa when starting to scroll.

Translate3d: ON, Scrolling: NO, Subpixel-AA: WORKS

Translate3d: ON, Scrolling: YES, Subpixel-AA: does NOT work

I lost subpixel-aa when scrolling.

Things look a lot better with translate3d disabled:

Translate3d: OFF, Scrolling: NO, Subpixel-AA: WORKS

Translate3d: OFF, Scrolling: YES, Subpixel-AA: WORKS

I should add that I am only getting subpixel-aa in the editor with translate3d turned off ever since I fixed #24532. For some reason, the entire workbench was using grayscale-aa when the workbench container (.monaco-workbench) was not having a background-color associated. Puzzles me why that has an impact though...

Remains to understand why Chrome turns the editor into grayscale-aa once scrolling starts. Since its fixed after disabling translate3d, it is probably that. Checking for chrome issues that might be related I stumbled upon https://bugs.chromium.org/p/chromium/issues/detail?id=521364

[alexdima]

@bpasero I don't think this is happening on all environments. e.g. it is not happening for me. What is the setup that triggers it? 125% scaling in the OS (mine is configured with 200% scaling)?

[bpasero]

@alexandrudima I am running with 125% but I also see this with 100% as well as 200%.

[alexdima]

@bpasero Do you sign out of Windows and sign back in between changes to the scaling setting? There are numerous apps (I wouldn't be surprised if Chromium is one of them) that cannot react to changes to scaling unless you sign out of Windows. (I'm trying to find out what is the root cause of this)

[bpasero]

@alexandrudima wow, you are right, subpixel-aa works in 200% after doing a windows restart. So maybe this is only an issue when the multiplier is an odd percentage?

[egamma]

According this tweet https://twitter.com/paulcbetts/status/852050882523000832 this only affects non-integral DPIs

[ghost]

Really said, for my device, 100% is too small and 150% is too large.
Hack it then work with 126%? LOL, That's impossible

[alexdima]

@ArianeLu We will look into a solution. My favorite resolution would be to disable our usage of translate3d only in the cases where this issue is hit (i.e. not for folks running at 100% or 200%) due to the scrolling performance implications.

[alexdima]

I could reproduce. Here are the values I get (with window.zoomLevel: 0) for:

Scaling factor	Zoom Level	Zoom Factor	Pixel Ratio
100%	0	1	1
125%	0	1	1.25
150%	0	1	1.5

I'm looking into disabling the usage of translate3d in the editor when the pixel ratio is not an integer.

[bpasero]

@alexandrudima awesome, thanks!

[ghost]

@bpasero @alexandrudima Text become darken and tiny after open built-in terminal, I can't find out why

[ghost]

Look like this one

[ghost]

#26800