Hacker News Reader

Comment by joan_kode | Hacker News Reader

Looking at the screenshot in full size [1], it looks really cool but the text is visibly blurry (look at the = signs for example). Text rendering is hard, and especially for a text editor it's a good idea to just use the current platform's text rendering instead of rolling your own. Of course SDL "rolls its own" because it focuses on being exactly the same on every platform.

SDL seems to offer font hinting which would somewhat solve the immediate problem, but I'm not sure it's being used properly here. With that said, text rendering is optimized for the current device's DPI, so maybe I'm just reading too much into a screenshot taken at a different DPI.

[1] https://user-images.githubusercontent.com/3920290/81471642-6...

View on HN

SDL has hinting because it uses freetype. But this program doesn't use that. It uses stb_truetype which does not support hinting.

Yes, the rendering implementation uses gray-scale antialiasing.

But system uses ClearType - compare rendering in window caption (rendered by Windows) and the text inside client area.

Gray-scale may work on high-DPI monitors, but on typical monitors it will be blurry.

But Apple and Microsoft still use ClearType even on high-dpi monitors.

For that matter, Sublime Text, that uses similar architecture (but Python instead of Lua), uses ClearType.

Apple removed all subpixel antialiasing on Mojave [1] and on Windows it isn't used for any 'modern' app using UWP onwards afaik

[1] https://arstechnica.com/features/2018/09/macos-10-14-mojave-...

well, apple certainly de-emphasized subpixel antialiasing.

i am still using a non-retina monitor for all of my day-to-day work. when i first installed mojave, it made my display look so bad that it gave me headaches. so i wiped my mac entirely and re-installed the previous version of macos. later, i learned that subpixel anti-aliasing is still there, it just takes some fiddling to get it back.

https://www.howtogeek.com/358596/how-to-fix-blurry-fonts-on-...

eventually, i will have to get with the program and buy a retina display. but i am thankful for this loophole that allowed me to put it off for awhile.

I just purchased an HP Z27 (4K 27”) because I couldn’t deal with the low-res monitors I had at home. The high quality monitors in my office had really spoiled me.

I’m so glad I did. Night and day difference.

It has become a challange to have a sane default for text rendering. Many users are still on really bad LCD monitors with low contrast. Macbooks also does 2x scaling. On a 4k monitor on PC i recommend fractional scaling eg 1.5 but as an app dev you cant control that. So do you increase text size to make up for the small pixels, or do you leave that up to the user.

Mea culpa, thanks.

> But Apple and Microsoft still use ClearType even on high-dpi monitors.

This isn't true.

I don't think Apple uses ClearType and OS X defaults to no AA on retina displays.

Yet, there is no support (yet?) for RTL languages.

I have just downloaded it too and witnessed this issue, the text looks weird, like a little bit blurry, it would be perfect if it looked like on Sublime Text 3 or on this image https://i.ibb.co/qYCpx3x/1588859182372.gif

If you compare the SDL-rendered text to the window chrome (OS-rendered), they appear to be similar. It just looks like this is a screenshot of a low DPI display. Nonetheless, peeking at the repo's issues shows that high DPI displays haven't quite been figured out either:

https://github.com/rxi/lite/issues/46

That could possibly be a result of the image compression as well, no?

Shouldn't PNG be lossless by default ? (you could do some lossy pass to optimise but in that case you're probably better off using JPEG ?)

Sites like github often "optimize" images to lower bandwidth costs. Basically any platform you share images on that is at scale will probably re-compress images. For PNG they often reencode the image in a lossy way.

GitHub doesn’t “optimize” your images, just as it doesn’t format your code. People would storm the barricades if Github changed their files.

They do change files that are embedded in readmes, just like most web platforms do. The original file is unchanged, but the version embedded in the readme preview on github.com is changed.

They just proxy it on the fly with camo: https://github.com/atmos/camo

Reply on news.ycombinator.com