Blurry text rendering on macOS Monterey

[NoirJ0e]

I follow the instructions wrote in the wiki and build it on my own machine, the output in the terminal seems ok

except the warnings but I believe it's because the system version is too new

but the program's appearance isn't good, the whole UI seems runs in low resolution

and I don't know if it's the way I use it wrong or something, what I expected to see is use nvui filename and it will open up a instance and let me modify the file, but what happened is it just create a instance but doesn't open the file I want, I have to drag the file into the instance or open it in the instance by some plugin's help

[rohit-px2]

I'm not sure about the resolution problem, I'll have to look into it. I did switch the text rendering mechanism a while ago but it shouldn't have caused any problems (uses QStaticText). Have you specified a font to use?
Also you can use the -- flag to forward arguments to Neovim so you could do nvui -- example.md.

[NoirJ0e]

Yes I did set a specified font to use, it's the same as your example which is Consolas but I change the size to 14, this is a quite strange issue.

And thx for telling me the correct way to edit a file :)

[rohit-px2]

If you don't want to use the -- flag I added a branch #88, just going to make sure it builds before I merge it. I've been got by linux and macos builds too many times at this point

[NoirJ0e]

update: I add the --ext_cmdline=true and surprisingly the text in the external block has been rendered correctly

[rohit-px2]

It's probably because of the different text rendering mechanisms. Cmdline (and popup menu) uses QPainter::drawText since I am not doing any text caching there (not much text to draw). Meanwhile on the main text grids the text is being created as QStaticText, stored, and then drawn using QPainter::drawStaticText. I'm guessing that there's some issues with drawStaticText on mac. I'll let you know when I've added a fix.

[rohit-px2]

Does #89 fix this?

[NoirJ0e]

Sadly no :(

[rohit-px2]

Rip. I don't really know what's causing the issue then. I'll tag this as 'help wanted', maybe someone else knows why this is happening.
Maybe you could try other fonts, do they have the same problem?

[ohmree]

I'm getting something similar on Arch Linux, X11, KDE Plasma, doom-nvim and the nvui package from the AUR started like this /usr/share/nvui/bin/nvui --ext_multigrid=true --ext_popupmenu=true --ext_cmdline=true:

I think my font configuration is fine since it works fine in doom emacs, kitty and a few other apps.

Maybe it has to do with display scaling? I have mine set to 125% in KDE's system settings.
I've tried setting it to 100% and restarting nvui with no success, and I'll try fully restarting the graphical session later to see if that fixes it.

[rohit-px2]

I added some commits for this today (setting antialiasing flags for rendering) on #89, could you check it out and see if it fixes your problem? Builds are here.

[NoirJ0e]

I'm getting something similar on Arch Linux, X11, KDE Plasma, doom-nvim and the nvui package from the AUR started like this /usr/share/nvui/bin/nvui --ext_multigrid=true --ext_popupmenu=true --ext_cmdline=true:

I think my font configuration is fine since it works fine in doom emacs, kitty and a few other apps.

Maybe it has to do with display scaling? I have mine set to 125% in KDE's system settings. I've tried setting it to 100% and restarting nvui with no success, and I'll try fully restarting the graphical session later to see if that fixes it.

I used to have the same problem as you but I can't represent it every time. My workaround solution is reboot the machine and it will work for me until the next reboot, quite strange.

[NoirJ0e]

I added some commits for this today (setting antialiasing flags for rendering) on #89, could you check it out and see if it fixes your problem? Builds are here.

Still have the same issue on macOS, maybe this is some QT problem on Monterey, we may need to wait until QT release new version for Monterey

[kaipingdalao]

cmake --build build --target nvui --config Release
fatal error: unable to execute command: Segmentation fault: 11
in Monterey,building error,please help me

[tthkbw]

As much as I would like to play with nvui, is it unusable on macOS Monterey because of this font rendering issue. I have tried multiple fonts and sizes--some are better that others, but they all give me a headache. I feel like I'm editing on an old CRT.

Apparently no progress on this recently?

I note that some have commented this could be a QT problem on Monterey. This seems unlikely to me. For example, Calibre uses QT and renders cleanly.

[reykjalin]

I'm pretty sure the solution to this would be to build a macOS application bundle and set the NSHighResolutionCapable property to true in the Info.plist file.

I've run into this before when playing around with Qt and other GUI frameworks and this fixed the problem for me every time.

The Qt docs have a guide on building macOS app bundles but it seems to only have a guide for QMake and not CMake.

The general lack of application bundles is honestly one of the things that makes me not want to invest time in setting up some of the Neovim GUIs out there because I dislike leaving my terminal open, so this could be a relatively easy win; generate an application bundle when building on macos.

[rohit-px2]

Cool, that might be what I was looking for! I'll create a new branch with the plist soon, will post it here when it's been created.

[rohit-px2]

Had to fix some build issues so it took me longer than I thought. I added the plist on the blurry_text_fix_mac branch and you can find builds here, let me know if that solves it.

[tthkbw]

I downloaded the build for macOS and tried it. It doesn't seem to have any effect on the blurry text problem on my machine--m1 mini running the latest Monterey, 12.2 with a LG 5k monitor.

It is not obvious to me that the plist file is being used. The structure of the app and location of the plist is the same as other .app packages I looked at. I also moved the nvui.app to the /Applications directory. However, I can only run nvui.app successfully by using the terminal open /Applications/nvui.app command. Running from Finder causes nvui to report that there is no Neovim in the PATH. I'm not sure what Finder thinks $PATH might be.

I don't know how to determine if nvui.app is actually using the info.plist included with it. If it is, then the problem is not fixed. If it is not, how to I make it so?

[rohit-px2]

I used CMake's bundle feature to bundle the plist with the app so it should be using the plist automatically. I don't have any other ideas besides that. Could you check if Neovim-Qt/Goneovim have the same rendering issue? They also render using Qt so if they are fine then there could be a way they solved it.
As for the PATH issue, no idea on why that's happening.

[tthkbw]

I loaded Goneovim version 0.5.1. It works and renders perfectly. Goneovim's plist file has quite a bit more 'stuff' than nvui's does. nvui has:

<dict> <key>NSPrincipalClass</key> <string>NSApplication</string> <key>NSHighResolutionCapable</key> <true/> </dict>

for the same key, Goneovim has:

` NSPrincipalClass
NSApplication'

but Goneovim does not have the key NSHighResolutionCapable.

[rohit-px2]

NSHighResolutionCapable is true by default, so I guess they don't need it and it's not causing the problem. I looked through the Goneovim plist file and didn't find anything that would necessarily help rendering.. I did find that Goneovim enabled a Qt flag called Qt::AA_EnableHighDpiScaling though. I added that in and it's building here now, so if you could see if that fixes that it would be great. Thanks for helping with this issue, Mac is hard to debug for me since I don't have a machine.

[tthkbw]

I’ll watch for the build and test for you.

[rohit-px2]

Tried the build myself (on Windows) and it looks like the automatic high dpi scaling has broken a lot of things.. I'll try and fix them and put a comment here when it's done

[rohit-px2]

@tthkbw I think the scaling issues have been fixed so if you could let me know how it's working that would be great. The build is here

[tthkbw]

Yes, it is fixed and displays properly now. However, the problem with running nvui.app from anywhere other than the command line using /Applications/nvui.app persists. Nvui must be using the PATH environment variable to find nvim, but I don't think the PATH environment variable exists other than from the terminal.

[rohit-px2]

Nice! And yeah, from what I've seen in Goneovim and Neovim-Qt, they spawn an external process to print the $PATH and then they manually set it. Might have to do something similar

[reykjalin]

I think the scaling issues have been fixed so if you could let me know how it's working that would be great. The build is here

Hmm, when I try to run this I see the following:

$ open ~/Desktop/nvui-macos-x64/bin/nvui.app/

The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600003611470 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

I wonder if that's because the CI is building that on intel architecture while I'm using the M1 chip 🤔

[rohit-px2]

Yeah only the x64 version is built, Github Actions doesn't have M1 virtual machines so that's probably why.

[coordinatio]

I observe very similar issue on Arch Linux. Here is how font rendering inside the latest nvui looks like in comparison to fonts in nvim-qt:

Please tell me if you know what information needed to help investigate the issue. I will try to provide it.

[coordinatio]

I have discovered that the issue goes away if the display scaling is switched off. Maybe that can help to resolve the issue.

I use Xorg and KDE and set global display scaling through KDE's systemsettings utility.