Font Antialiasing Issues

[Glog78]

Contour Terminal version

0.3.9-master-f05bb1a5

Installer source

Github: source code cloned

Operating System

arch linux

Architecture

x86-64

Other Software

none

Steps to reproduce

compiled from source qt5 Increasing Fontsize might make it more obvious used gray as antialiasing setting. Happens after my latest rebuild from git (today)

Config -> https://termbin.com/34pr6

Expected Behavior

Glyphs to be rendered smooth

Actual Behavior

see -> t , corners of the c , o in mastodon , shadow after n in online

Additional notes

No response

[uspasojevic96]

Did you try changing AA in contour config? That's why it's there, if no option works for you, this is then a bug

[Glog78]

render_mode=grey
strict_spacing=false

render_mode=monochrome
strict_spacing=false

rendermode=light
strict_spacing=false
(see the c which isn't completly filled) << currently most likely the best result

rendermode=lcd
strict_spacing=false
see the % and the shadows at the edges

If i didn't miss one there should be all off them
also grey was totally fine for a long time , my update today broke it but i have skipped alot of commit's so i can't say which one introduced it.

[christianparpart]

I didn't touch font code nor OpenGL rendering code in a long time. That most likely could not have changed. Is this a new problem to you?

I very rarely experience a weirdly rendered character. I remember I fixed that by slightly increasing the font size. I'm using gray-scale AA. 🤔 hmmm....

is this problem specific to one glyph and/or one font?

[Yaraslaut]

I don't get any issues

P.S. nice config colors

you can try contour debug font.render to give more info

[Glog78]

I didn't touch font code nor OpenGL rendering code in a long time. That most likely could not have changed. Is this a new problem to you?

I very rarely experience a weirdly rendered character. I remember I fixed that by slightly increasing the font size. I'm using gray-scale AA. thinking hmmm....

is this problem specific to one glyph and/or one font?

It's basically totally new. I compiled today and had this problem. It is also not only one specific glyph. It's happening depending on background color and or it seems depending also on font resolution which i usually change with hotkeys inside of contour.

[rhcher]

Meet same issue but with only on one computer which I get coutour from source code on master. But I can't see this issue with my another computer that I get contour from github Release. I can test on first computer with Release contour tomorrow.

Edit:
Test on first computer with Release and the issue still exits. It has nothing to do with whether the contour is compiled from source or from github Release page.

[Glog78]

Didn't give anything out of the ordenary. Besides alot of messages like ->
[2022-12-19 17:39:02.319302] [font.render] rasterize (0, 12pt, 63) to rasterized_glyph(0, 5x17+(3, 14), alpha_mask)

Also updating the config doesn't helped -> https://termbin.com/9h52 | same issues

PS: The colorscheme is adapted from gruvbox-material ->
vim ->
Plug 'sainnhe/gruvbox-material'
set background=dark
colorscheme gruvbox-material

i didn't used the new features like statusline and so on so i never adapted for the new modes but maybe someone want's to ...

[Glog78]

i wanted to try the release build but both release branch and master fail for me to build now -> https://termbin.com/obxn

[rhcher]

i wanted to try the release build but both release branch and master fail for me to build now -> https://termbin.com/obxn

Just download from here https://github.com/contour-terminal/contour/releases/tag/v0.3.8.247

[Glog78]

I don't get any issues

P.S. nice config colors

you can try contour debug font.render to give more info

oh btw if it is not an jpeg artifact you got an small strange glyph too -> do you see how the n is rendered different ? ./build/src/co[n]tour (first line) vs all other n's in the text ?

[Yaraslaut]

Indeed, this one n is different from the others

[Glog78]

i might have found one reason -> resizing the window pixel by pixel in width creates rendering differences ...

the b get's a bold starting line ^^

the P (in FTP) and the e in Datei

the last g is placed much further away than on the earlier shots

Assumption -> could it be that the OpenGL rendering is applying an additional filter besides the font rendering engine itself ?

[Yaraslaut]

It seems that this commit broke rendering
a7bb9385b7e2af62cfdfff6d13c822d93e4cdeb6
@Glog78 can you confirm this?
For previous commit c2ee1a1f244c46650401d57a12f1d74e3dce8b99 i don't see problems in rendering

[Glog78]

i can confirm a7bb938 broke it , thank you for the help

[Yaraslaut]

i can confirm a7bb938 broke it , thank you for the help

Great, thanks

@Utkarsh-khambra can you look at why is it happening ?

[christianparpart]

i can confirm a7bb938 broke it , thank you for the help

Great, thanks

@Utkarsh-khambra can you look at why is it happening ?

I think I can spare you the pain of debugging through the OpenGL code, which isn't actually too hard, but in order to understand it, one should probably also know how OpenGL works internally and all related side effects. :-)

I think the problem is that the width is being changed, for the OpenGL rendering, but the actual width on the display will not change (and cannot). so the width must not be changed - as the painted scene must be put down to OpenGL pixel-perfect.

Why? Because otherwise OpenGL tries to be intelligent and interpolates the textures such that it fits the desired target dimensions, resulting into artifacts (like above).

I think, an attempted fix therefore would be to at least revert the part where the width is being changed, and then look for another solution. 🤔 hmm...

[christianparpart]

Reading through the motivation text of the PR again:

Because if terminal width is specified to be 80 cols then it should be 80 cols for both scrollbar hidden and visible.

I think one way to solve that would be to touch QOpenGLWidget::sizeHint() instead. I am not a Qt pro (sadly!), and there's still the QML PR open that btw addresses the scrollbar issue entirely differently (i.e. the problem doesn't even apply). but I think it'll take me quite a bit more until I can merge the QML PR, sorry :)

[Utkarsh-khambra]

I checked all the text rendering stuff with the default config, where the scrollbar is visible by default, that's why I didn't notice this. I'll look into this.

[Yaraslaut]

@Glog78 can you please check on latest master if this is fixed after recent pr #1139 ?

[Glog78]

i hope this is still visible ... tested lcd instead of grey and there is still a small line behind the @

[Yaraslaut]

i hope this is still visible ... tested lcd instead of grey and there is still a small line behind the @

This issue was fixed here #1213
Can you check @Glog78 if everything is ok now with anitaliasing in your case?

[Yaraslaut]

I will close this issue, if you still encounter it @Glog78 just reopen it then