Non monochrome fonts in Qt applications are fuzzy and badly anti-aliased

[thoamp]

The setup is a NoMachine Workstation 6.4.6-25 (Evaluation), on a headless Fedora 29 running KDE. Sub-pixel rendering type is disabled/none[1], the compositor is off and the rendering backend set to XRender [2]. The quality in the display settings is set to maximum and FPS is set to 60.

When using qt-creator or konsole, any non monochrome fonts are fuzzy and a strain on the eyes. When taking a screenshot (via the Win10 client machine) and zooming in the color-on-white fonts in qt-creator the characters seem to have their anti-aliasing applied like a shadow, i.e. there is a non-symmetric halo around the colored pixels, see attached screenshot 1 and 2. Fonts in konsole (KDE Terminal) also look washed out, see screenshot 3, this is especially glaring when starting htop. This does not happen when using gnome-terminal or when starting qt-creator or konsole via X11 to the Win10 client. I also did a naive flood-fill of the screenshot, showing the uneven black pixels in case of the nx-konsole combination.

1: System Settings -> Appearance/Fonts -> Fonts
2: System Settings -> Hardware -> Display and Monitor -> Compositor

Attachments:

1. 

   nx_qtcreator.png
   

2. 

   nx_fuzzy.png
   

3. 

   nx_abcd.png
   

[graywolf]

Would you try this change in node.cfg:

DisplayServerExtraOptions "-extension Composite"

and this

DisplayServerExtraOptions "-extension MIT-SHM"

and their combination:

DisplayServerExtraOptions "-extension Composite -extension MIT-SHM"

If nothing changes, try this on the other key ProxyExtraOptions:

ProxyExtraOptions "16m-png"

[thoamp]

Editing /usr/NX/etc/node.cfg with the various options and restarting it each time via systemctl restart nxserver showed no changes. The only other settings I changed in node.cfg are DisplayServerVideoFrameRate 60 and DisplayServerUseVideoFrameRate 1.

A better and clearer way to reproduce this is setting the terminal to red-on-black. I took a screenshot of gnome-terminal and konsole from within NX, and while the user view shows gnome-terminal in clear fonts, viewing the screenshot within NX showed these artifacts everywhere. The pixels in the screenshot itself are perfectly clear of course, so sending it via NX seems to degrade it.

I also reset the client display settings to defaults, there some other settings were required to remove some blurry images in qt-creator, but nothing changed.

 

Attachments:

1. 

   nx_red_123.png
   

2. 

   nx_settings_default.png
   

[graywolf]

We have reproduced the asymettric halo and already working on fixing that. Thank you for reporting.

By the way, using PNG encoding would grant lossless compression without artifacts (with a little increase in bandwidth usage).

Please double check the value in ProxyExtraOptions:

ProxyExtraOptions "16m-png"

terminate all the running session, restart NoMachine to be sure:

/etc/NX/nxserver --restart

Then create a new session and check in session log whether PNG is actually used:

grep -H "Using pack method" /usr/NX/var/log/node/*C-*/session

[thoamp]

That’s good to know, thanks for looking into it.

Furthermore I tried the option with and without quotes as "16m-png" and 16m-png, and the session log always says Info: Using pack method dynamic with session xsession-default. and the visual artifacts are still present.

It seems ProxyExtraOptions itself can’t be interpreted:


$ /etc/NX/nxserver --version
NoMachine Workstation Evaluation - Version 6.4.6
$ grep ProxyExtraOptions /usr/NX/var/log/nxserver.log
/var/log/nxserver.log:2019-03-04 12:30:16 312.540 31265 NXNODE ERROR! Wrong syntax in configuration parameter ProxyExtraOptions at: 16m-png


No stray non-ASCII chars in the config file, either:

$ cat -A /usr/NX/etc/node.cfg | grep ProxyExtraOptions
#ProxyExtraOptions limit=256k,link=modem$
#ProxyExtraOptions 16m-png$
ProxyExtraOptions "16m-png"$


[graywolf]

Sorry, my mistake. Correct form is:
ProxyExtraOptions "pack=16m-png"

[thoamp]

Yes, with this option the display is perfect. However typing is a bit more laggy, probably due to the larger encoding and bandwidth overhead.

[graywolf]

Yes, it looks correct: in the latter case you get lower compression rates.

[Author]

Posts