Text rendering seems blurry compared to other editors


#1

I am evaluating atom.io, but I am stuck at the font rendering. I believe I am using the same font in atom.io as I use in Sublime, but the text is just less readable in atom.io
I can read Sublime’s text across the room and it is always clear and crisp, but with atom.io it is fuzzy and I find myself having to look twice where I can just glance at Sublime.
Here is a sample:

It doesn’t seem like much, but on an entire screen of text all day long, the difference is enough to make atom.io hard for me to continue using.

Does anyone know if there is something I can do to adjust atom.io more?
This is on Windows.
I’ve already looked at this thread, but nothing I tried from it appeared to make a significant difference:
Atom vs TextMate font rendering

I’m not posting this to complain, only to learn if there is something I am missing that could improve my experience with atom.io.


#2

Something else you might also try from this Issue:

is enabling or disabling Hardware Acceleration in Atom’s Settings View:


#3

Thanks, that does seem to help, although as a further down post shows with screen shots, there is still a noticble lack of clarity on Windows non-retina displays in atom.io compared to ST even with hardware acceleration off.


#4

I have no checkbox like this in my settings pane :frowning:
I’m using windows version 0.189.0
Maybe I can disable hardware acceleration in config or with command line argument?


#5

The ability to enable/disable Hardware Acceleration has been removed in this commit:


#6

font rendering is blurry since 190. what happened? Theres no hardware to enable as @Alchiadus shown above.

html {
  font-size: @font-size;
  text-rendering: optimizeSpeed;
  -webkit-font-smoothing: antialiased;
}

not helping too.


#7

Could you give the following information?

  • What OS and version are you running?
  • Can you reproduce the issue after completely exiting Atom and restarting using atom --safe?

Also, subpixel-antialiased is generally a better alternative for -webkit-font-smoothing.


#8

1 . Linux 3.14 with KDE 4.13

2 . Yes

subpixel-antialiased looks better but still not as clear as other KDE text editors or chrome.


#9

On OS X 10.3. Just updated to 0.206 from 0.204. Subpixel antialiasing no longer working. Crap.


#10

I seem to see a difference in the rendering between -webkit-font-smoothing: subpixel-antialiased and -webkit-font-smoothing: antialiased using Atom v0.206.0-e1514cf on Mac OS X 10.10.3. I’m not qualified enough to determine if it is “true” subpixel antialiasing, but if there is a change I would tend to suspect that it is working.

Antialiased:

Subpixel Antialiased:


#11

where do you add it?

I tried inside

* {
}

but didn’t work.


#12

@leedohm, I’m also seeing a difference between antialiased and subpixel-antialiased, but I still don’t think it’s working. Did a little more reading (including the issue you referenced above and this), and it seems like a Chrome issue. I’m confused, though, since subpixel antialiasing was working in 0.204.0, as evidenced in the top line of my screenshot.

@v3ss0n, the atom-text-editor selector works for me.

Edit: I think I know what happened. Release notes for 0.206.0 say:

Switched to a tiled rendering strategy to improve text editor rendering performance, especially scrolling.

Sure enough, it seems subpixel antialiasing works in 0.205.0. 0.206.0 killed it. Darn.


#13

We should make a comparison test and report here : https://github.com/atom/atom/pull/6733 if we are sure due to tiled rendering ,


#14

See if adding the !important flag helps? It might be that your CSS is being overridden by whatever changed because that ruleset is more specific


#15

Hm. Reading through that PR discussion, I might have assumed incorrectly. But, when I zoom in on text in 0.205.0 it sure looks subpixel-antialiased. Can @nathansobo provide any wisdom here?


#16

Hi there. Yep. It seems our tiled rendering strategy, which boosts scrolling performance dramatically, also broke subpixel anti-aliasing. I was actually under the impression that it wasn’t working to begin with. I guess Chrome got it working correctly at some point and I missed it. The fix is to make our tiles opaque, which will take some work but it’s definitely doable. We should have a fix out soon.


#17

Hello everyone!

I am truly sorry this has caused headaches to you and I’d like to apologize for that. As @nathansobo pointed out, however, we are already working on a fix which should bring sub pixel anti-aliasing back. :+1:

I must admit I am not able to see any difference between 0.205 and 0.206 in terms of font rendering, since sub pixel anti-aliasing doesn’t seem to work on my machine. Hence, I’d be very grateful if anyone could build the PR and confirm it actually solves the issue.

@timglorioso: does the PR fix the issue on your machine?

Thanks :blue_heart:


#18

@as_cii, the opaque tiles did the trick. Much appreciated! Makes a huge difference on my non-retina Air.


#19

Thank you very @nathansobo and @as_cii . Your work for Tiled Rendering worth losing Antialiasing for me , if theres no way to get it work i mean. If you can , loads of respects for you!.

Awesome work , guys!


#20

So, we have just merged https://github.com/atom/atom/pull/7127: you can have a look at all the nitty-gritty details right there, but the TL; DR; is that the tiled editor should work without breaking text legibility.

If nothing goes wrong in the meantime, we should :ship: it in time for 0.208. We still need to address text readability on Hi-DPI Windows machines: @paulcbetts is already investigating a possible solution and he’s going to report what he finds out.

Thanks everyone for your kind feedback and support! :bow: :bow: :bow: