Serious problem with font quality degrading over time

[drewhamlett]

So you guys started off great. I think I came in at Sprint 15. This is a screenshot of Sprint 17. Great product. Great font rendering. Fast, sleek. Great editor. No modifications out of the box.

So then Sprint 20 came along and change some rendering. I was told to put subpixel-antialised to fix it. It was changed because of flickers during animation(which I have never actually seen and I've used this day in and day out for a while).

So then Sprint 27 comes a long. It brings worse performance, and of course worse font rendering. I try to fix it with subpixel-antialised, and it helps a little bit.

So then Sprint 28 gets launched, with even worse performance and worse font rendering. Now not even changing the font or font-rendering fixes it

I know there was a switch in shell but why is everything getting so bad. I just want the team to download Sprint 17 and use it. Then go and use Sprint 28. You can't tell me it has gotten better.

Thanks

[njx]

@drewhjava - from the screenshots, it looks like you're on Mac retina, right? There was a serious font quality degradation on Windows in Sprint 27 due to a new CEF, but as far as we know there haven't been any changes in Mac font rendering between our initial removal of subpixel-antialiasing and today. In particular, sprint 27 and 28 should be identical (they use the same CEF), and in practice we haven't noticed any difference, so I'm not sure why you're seeing a difference there.

We'll definitely look into reproducing it--just want to verify that you had subpixel-antialiasing set (or unset) in both sprint 27 and 28 when you made your comparison.

Also, as a point of clarification, our XD folks actually preferred the lighter look of the font after we switched away from subpixel-antialiasing (even though we originally did it in order to avoid the animation issues you mentioned). @larz0 might want to weigh in on this, but this might just be a difference in aesthetic opinion.

Ultimately, I think the solution for that issue is that we'll eventually allow fonts to be configurable, so you could choose a heavier weight for the code font. That's tracked on this card, https://trello.com/c/2nfWx6wX/353-3-user-specified-font, which is currently sitting on the backlog but is fairly far down the list.

The performance issues are separate--we had to put in a temporary workaround for a crash bug in CEF in the v8 optimizer, and the workaround affects the performance of code hinting. We weren't seeing huge issues in our own testing, but it seems like other people are seeing worse problems; that's being tracked in #4608. Hopefully that will go away once we can upgrade to a newer build of CEF (but later builds are causing a different crash, #4571, that we're trying to track down).

[TomMalbran]

Even though the font isn't configurable, is pretty easy to change the code or add an extension that all it does is add a new stylesheet with code to replace any font property. I wanted to make the font slightly bolder too, since it looks too thin in the new CEF so I added the next code from an extension:

.platform-win .CodeMirror {
    -webkit-text-stroke-width: 0.2px;
}

[drewhamlett]

@njx I'm not on a retina Mac. There was definitely a change between Sprint 27 and 28. I had subpixel set and unset for comparison.

I just don't think you should let XD people decide the font rendering for a text editor. You should follow the conventions of the OS. I think I've said that before. No other text editor on Mac has fonts this light. If they want light fonts then they will feel right at home on Windows XP.

As for me, one of the big reasons I chose MacOSX was the fonts.

@TomMalbran Thanks for your help this helped a lot!

[larz0]

@drewhjava are you talking about line 57 of brackets.less?

/* Turn off subpixel antialiasing on Mac since it flickers during animations. */
-webkit-font-smoothing: antialiased;

Looks like it's been like that since January. If you're talking about other parts of the UI I can take a look.

[lkcampbell]

I can weigh in on this issue now that I have a Mac.

Regarding subpixel antialiasing, I tried commenting and uncommenting the line in brackets.less that @larz0 mentions. On the retina screen, everything looks pretty good but when I hook up my Macbook to my Samsung monitor, commenting out the -web-font-smoothing line makes the font look quite a bit better. If the line is included, the font is pretty thin and light. I definitely notice it and I prefer the thicker font.

[drewhamlett]

I'm glad to see someone on the team is finally noticing this. It brings up an interesting point. How long did it take you to grow accustom to MacOSX font rendering? To me, MacOSX font rendering seemed extremely fuzzy when I first switched from Windows XP. I find Windows(even 7 and 8) font rendering extremely harsh now though.

I'm just wondering if we have a bunch of Windows clear type lovers on the brackets team or something. When I was 12, I liked the Windows 95 font rendering, but I prefer MacOSX rendering now. It feels better on the eyes.

Eventually, I would like to see the Brackets team to open up every other text editor on MacOSX and compare. It's weird though, Sprint 17 and below had some of the best rendering I've seen in a text editor.

[lkcampbell]

I'm still not use it but I have only had my Mac for a week.

[njx]

Hi--let me recap the issues.

• The reason that subpixel antialiasing is turned off is that Chrome turns off this antialiasing during animations, so if we turn it on by default, text flickers to the lighter appearance during animations (probably because the text is being rendered to bitmaps that are uploaded to the GPU).
• On retina, having it turned off doesn't have any effect.
• On non-retina, having it turned off makes fonts appear lighter. Our XD folks decided that the current weight is fine, but others disagree.
• We have limited ability to affect the weight of the default font (Source Code Pro) without having the font team redesign it (which would also likely affect the Windows appearance). We can use heavier weights that are available for the font, but when we've tried them in the past it I believe XD felt they were too heavy even with the lighter appearance of grayscale (non-subpixel) antialiasing.

@larz0, I think the next step would be for you to evaluate the appearance of the font on a non-retina display, along with heavier weights.

@drewhjava, just out of curiosity, have you tried hacking in other fonts (with subpixel antialiasing off) and seeing whether you find them too light as well? I'm wondering if there's something about the design of Source Code Pro that makes it particularly susceptible to this difference.

[njx]

BTW, one reason I don't think we've done much with this is that we haven't really heard other complaints about it. It might be worth starting a thread on the Google Group to see if anyone else feels the same way about the Mac rendering on non-retina.

[drewhamlett]

@njx
I do remember the animation issue. #2791. Although it should be noted that I never saw any issues with animations. The only animation I see in brackets anyway is the super distracting code complete slide animation.

The reason I started this issue was to bring up that turning on subpixel after Sprint 27, no longer corrects the fonts as it did in the past. Everything, I would say, was great until 28.

I don't see how anyone can't notice it, but you're right, I've been following Brackets for awhile and have never see anything on it. It's hard to believe, but some people actually prefer anti aliasing turned off for programming on MacOSX. I would argue that they would like Windows XP better(http://chrissilich.com/blog/sublime-text-font-smoothing-anti-aliasing-issues-in-mountain-lion/). This person likes the bottom picture better then the top. -_-

Do you guys have any analytics on Mac vs Windows downloads, as I don't see any issues on Windows. I'm just wondering if there are just that many Windows users using Brackets, then MacOSX.

Thanks!

[larz0]

Is this much better?

[lkcampbell]

@larz0, to me, your screen shot looks better than what I have on my Samsung.

@drewhjava, I agree with you, I like the top example in that link better, but the guy who wrote the article said the fatter font causes more eye strain? Not sure exactly how he quantified the amount of eye strain, but, okay.

I don't know. maybe it all is too subjective. Maybe @njx is correct: the only way to really address this issue is to eventually fulfilled the Trello story on font formatting and let everyone pick their own fonts.

[larz0]

@lkcampbell I'm using Source Code Semi-Bold instead of Source Code Medium in that screenshot. It'd be nice to be able to specify fonts in Brackets (Source Code Pro has seven different weights).

[drewhamlett]

@larz0 I code at a larger font size, so it's hard to tell. I will tell you that the side bar is still wrong. A font should never look like that on MacOSX out of the box(that's not subjective either. That's the system wide setting. Hinting is all jacked up). Take a look at my pictures in the original post and compare your side bar.

[larz0]

Which one is better?

[lkcampbell]

@larz0, I like the second one, the fatter font.

[drewhamlett]

@larz0 Both are much better. I would say the first one though. Compare the .travis.yml text in the first picture or second picture to the .travis.yml in the picture you posted early. It's night and day.

This is Sprint 22 with subpixel-antialised turned on and this theme default setting.

.code-font-mac() {
    .code-font();
    /* Use the Medium weight on the Mac to counterbalance the grayscale antialiasing. */

}

I took the line out where it sets SourceCodePro to medium.

[lkcampbell]

I feel like I am at an optometrist appointment.

[larz0]

@lkcampbell @drewhjava ok this is clearly a font preference issue. Anyone want to write an extension? :)

First one is using subpixel-antialiasing with light gray filename color instead of white because #fff makes it really fuzzy for some reason.

Second one is using antialiased SourceSansPro SemiBold with no changes in color.

[drewhamlett]

@lkcampbell Hahaha.
@larz0 If it can be fixed with an extension that's fine but I wasn't able to get it looking that good with the later releases.

I'm still saying.

https://f.cloud.github.com/assets/1495261/1507856/69e41844-49b3-11e3-9f89-72c58bd27592.png

Is not correct, for MacOSX

I had this a while back.

https://github.com/drewhjava/brackets-theme-update

But it doesn't fix it in the later versions. That's why I started this topic.

Later on I started using what njx mentioned in this issue. #2791. (his last post)

[larz0]

I just up voted this: https://trello.com/c/2nfWx6wX/353-3-user-specified-font

[larz0]

Both 13px

[drewhamlett]

Brackets 33 on left Brackets 21 right.

Also are you on Mavericks or Mountain Lion?

[larz0]

@drewhjava yes that's a known CEF issue as previously discussed. I'm on Mavericks.

[bassu]

Same is the case on Linux. Whatever anti-aliasing and stroke settings are being used, they make visibility quite frustrating.

See it for yourself. The blurriness is there.

[JeffryBooher]

Adding CEF/Tracking labels as this may have been addressed in 1750

[denji]

sprint 0 build 1.0.0-15191 (release 3f2eb90)
build timestamp: Fri Oct 31 2014 12:47:15 GMT-0700

Too thin font ru_RU on the Retina ( ant7/ant-brackets-theme )

As you can see, the font is significantly different depending on locale:

[vinnytroia]

I just opened a bug about this but it looks like this has already been closed?

[vinnytroia]

[nethip]

@vinnytroia Which build are you using and on which platform? On Windows Brackets now is already Hi-Dpi enabled.

[vinnytroia]

OS X - 10.10.
Brackets 1.2

is there a better build available?

On Apr 23, 2015, at 3:39 AM, Prashanth Nethi [email protected] wrote:

@vinnytroia https://github.com/vinnytroia Which build are you using and on which platform? On Windows Brackets now is already Hi-Dpi enabled.

—
Reply to this email directly or view it on GitHub #4640 (comment).

[nethip]

@vinnytroia We have integrated CEF 2171 in Brackets 1.1 and there could be some rendering differences when compared to Brackets 1.0. We have not pushed anything much that has to do with the rendering of the overall app.

I have tried to compare 1.0 and 1.3 (just released) and I could not find them to be very different.
Could you tell me more about your system's configuration?

• Are you on a retina display?
• Are you using a Scaled Resolution?
• Also the image you had posted above shows screenshots of different code instances? Could you post the screenshots with the similar code instance, so that we have an apples to apples kind of comparison.

Also please see the discussion at #10083 and it could be possibly related.

[vinnytroia]

The two screenshots are from different programs running on my mac (retina display). The idea was to show you how fonts render on most programs on my mac vs how they are displayed in brackets.

On Apr 27, 2015, at 7:35 AM, Prashanth Nethi [email protected] wrote:

@vinnytroia https://github.com/vinnytroia We have integrated CEF 2171 in Brackets 1.1 and there could be some rendering differences when compared to Brackets 1.0. We have not pushed anything much that has to do with the rendering of the overall app.

I have tried to compare 1.0 and 1.3 (just released) and I could not find them to be very different.
Could you tell me more about your system's configuration?

Are you on a retina display?
Are you using a Scaled Resolution?
Also the image you had posted above shows screenshots of different code instances? Could you post the screenshots with the similar code instance, so that we have an apples to apples kind of comparison.
Also please see the discussion at #10083 #10083 and it could be possibly related.

—
Reply to this email directly or view it on GitHub #4640 (comment).

[nethip]

@vinnytroia I now get what you are saying. We have tested Brackets on Retina display and it did not look awfully bad. I will give it a spin again tomorrow and update you with the results. Thanks!

[nethip]

@vinnytroia We are in the process of fixing the rendering issues on MAC.
I have kind of packaged an extension which would make fonts look crisper on MAC. Would you mind installing the extension from the following location and tell us if it indeed improves the rendering?

https://www.dropbox.com/s/yu6dqt5qm079r3r/EnableSubPixelRendering.zip?dl=0

You could install it by dragging and dropping the zip file onto the extension manager dialog.

[vinnytroia]

not much change.

On May 19, 2015, at 2:55 PM, Prashanth Nethi [email protected] wrote:

@vinnytroia https://github.com/vinnytroia We are in the process of fixing the rendering issues on MAC.
I have kind of packaged an extension which would make fonts look crisper on MAC. Would you mind installing the extension from the following location and tell us if it indeed improves the rendering?

https://www.dropbox.com/s/yu6dqt5qm079r3r/EnableSubPixelRendering.zip?dl=0 https://www.dropbox.com/s/yu6dqt5qm079r3r/EnableSubPixelRendering.zip?dl=0
You could install it by dragging and dropping the zip file onto the extension manager dialog.

—
Reply to this email directly or view it on GitHub #4640 (comment).

[WolfieWerewolf]

I just installed the latest packaged version of Brackets for OSX from the main website and experienced this issue. I wanted to confirm that the above patch provided by @vinnytroia has made a massive improvement. Cheers for that. About reports:
Release 1.6 build 1.6.0-16680 (release 3df0ac6)
build timestamp: Tue Jan 12 2016 05:35:00 GMT-0800

[stela5]

The @nethip extension helped a little