-
-
Notifications
You must be signed in to change notification settings - Fork 686
Core Text rendering issues with macOS 10.14 Mojave #751
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This happens only when you compile MacVim with 10.14 SDK (previous SDK works fine). For me the MacVim GUI flashes dark/light grey with desert color scheme in rhythm with the cursor blinking, if "Core Text Renderer" is turned on. |
This is because of a Mojave change that made all NSView automatically become layer-backed, which will break MacVim's rendering since it relies on behaviors from the legacy renderer. Fortunately it only happens when you link against the new 10.14 SDK so old builds would still work, but we would need a long term solution, presumably a Metal-based renderer similar to other fancy high-performance terminal emulator like Alacritty or Kitty. Currently the CoreText renderer also supports a CGLayer mode but it has miscellaneous issues including slow scrolling so I don't think that's the way forward. More info: |
Unfortunately it appears that MacVim is completely unusable on Mojave. Is there any temporary fix? |
@amadeus Are you building MacVim yourself using Xcode 10 on Majave? If so, you can build using the old SDK which will fix this issue. Easiest way is to download Xcode 9.4.1 from Apple Developer and build using that. If you are downloading builds from official releases I don't think it should be broken. Otherwise you can do this in Terminal to turn on CGLayer mode: |
@amadeus Download the binary form https://github.com/macvim-dev/macvim/releases |
@ychin Could you give me a bit more detail on the problem? I'd like to hack a bit on it, although I predict I won't be able to patch it before the regular MacVim committers have fixed it. It seems to me like the issue is someplace in NSWindow not having a background color set? And you want to fix it by dropping Core Text entirely and switching to Metal/Metal2? |
@joelfrederico I was actually planning to implement a first-pass for a fix for this this weekend since I have been looking at the renderer code when fixing some fullscreen rendering bugs, but if you do want to tackle the issue feel free to do that too. The way Vim works is that it treats the GUI as a dumb terminal and just issue draw calls to the GUI like it does for a terminal. The way MacVim draws is that it batches up these draw commands and calls The issue is that these draw commands Vim sent it are only incremental draw commands assuming the previous draws are still valid. When you call Another issue is we currently use The CGLayer implementation (you can manually turn that on by doing All of this is kind of messy which is why I think we should just implement a hardware accelerated renderer (using Metal) to replace CGLayer. We will still use CoreText for the text rendering. We could either just use a GPU texture as backing layer and draw texts on it which ties into the current renderer easier, or we could cache the font glyphs which would allow us to draw texts much quicker but may be tricky to implement (since MacVim supports ligature etc). Another issue with cached glyphs is they won't work (easily) with subpixel font smoothing, which isn't an issue in Mojave since that feature got removed anyway :(, but in older OS we may still want to have subpixel font rendering to be consistent with other parts of the OS. This is the gist of what I understand of the rendering bug, maybe we should make another issue dedicated to writing a new renderer. |
I think supporting older macOS is mandatory, but I'm not sure how compatible that is with using Metal. |
@ychin Thanks for the detailed description!
Please don't change your plans thinking I'm working on it! I'm just getting my feet wet, I don't expect to actually be able to do much of anything. |
Metal first appeared in macOS El Capitan, but not every graphics card supports it. So we could have current implementation as a fallback if Metal is failed to load or it set in settings before Mojave and Metal backend only on macOS Mojave+. |
This didn't solve anything on my Mojave machine. MacVim (the whole window) blinks along with the cursor. |
It works, for me. 151 on Mojave. |
Any updates on this? I have tried I also downloaded 151 binary from https://github.com/macvim-dev/macvim/releases, it doesn't work for me. |
@xiaohk How does the release not work for you? Does it crash or just blink a lot when you type? Do you have an external monitor? You can try to remove the CGLayer setting first by doing |
@ychin I think iTerm's Metal renderer uses pre-generated glyph images, it could serve as an example implementation. |
Oh and it also has subpixel antialiasing, see this google doc for the technical details: |
The release blinks with my cursor. I don't have an external monitor. I did try to set |
This is what I keep getting, even when I wipe the preferences and even when I start up with If I turn off CoreText rendering in the prefs dialog the blinking stops. I have a non-retina display in my laptop. |
Thx you all for working on this. |
I hacked on this a while back but haven't touched it recently. I'm not convinced that a Metal rewrite is necessary! The renderer just needs the ability to draw arbitrary rects instead of relying on being able to draw on top of existing content. The tricky part is that, currently, it doesn't keep any kind of state; it just draws as it receives commands. That would be the biggest change, but not that big. If redrawing everything is too expensive, there are strategies like using tiles that could be moved around without redrawing the whole window, or just using a layer per line, for example, and moving those to scroll without redrawing. |
I agree with the above observation. I see the same issue blinking window. It doesn't let me work. |
I see the blinking mccvim too. Exact same steps as y00rb above. Attached is a zipped movie. |
Turning off "Use Core Text renderer" and restarting (i.e. completely quit application, not just close window) should do it alone. |
Yes. Thanks a lot! |
@balajirama Thank you very much!!! I did disable |
Cross-posting this from my PR: my job’s okay with me spending some work time on this, but only if there’s a top-level LICENSE file (and there currently isn’t). If one can be added first, I’ll pursue a fix. |
ping |
@J-Liu see #757 (comment). |
@s4y |
Snapshot 151 works for me on MBP15 with Mojave. |
homebrew version is 151.
```
cask 'macvim' do
version '8.1.151'
sha256 '67aed665cb098e0e9c0fc3a4f99af6d4b4fda58531e6e46c6c9b0ffbed5faad2'
...
```
…On Fri, Nov 23, 2018 at 6:03 AM Alex Salt ***@***.***> wrote:
Snapshot 151 works for me on MBP15 with Mojave.
Doesn't work from homebrew, probably still older version
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#751 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAN46sSB4maG6zwCWmIEu9Z0DzgiugqNks5uxx88gaJpZM4W12xK>
.
--
--
alswl
|
My homebrew version (claiming to be 151) on MacOS 10.14.1 was still doing the flashing, until I disabled "Use Core Text Renderer" in the Preferences. |
Before this commit, the Core Text renderer relied on a legacy behavior of NSView to keep its content across draws. setNeedsDisplayInRect: could be used to draw over parts of the existing content as drawing commands were received without needing to redraw old content. Layer-backed views lose this behavior and may be asked to redraw any or all of their content at any time, and layer backing becomes the default for apps built against the macOS 10.14 SDK. This change adds a way to draw to an intermediate NSImageRep and then draw that to the view. It's similar to the CGLayer path, but I wasn't able to get the CGLayer path to work without hanging or crashing when I scrolled. My best guess from looking at stack traces is that using CGContextDrawLayerInRect to draw a layer into itself doesn't actually copy pixels, but adds the self-draw as an action to be performed when the CGLayer is drawn into a bitmap context. Scrolling stacks these actions, which either hang or overflow the stack when drawn. The new code is controlled by the MMDrawToImage user default, which is on by default in this change. Fixes macvim-dev#751.
@oseiberts11 disable |
@alswl yes my vim looks like burnt toast, it's horrible to code in. I'm just hanging in there until it's fixed, hopefully within a week or something :/ |
My alternative solution for CJK IME user is using vim in Terminal. |
Can't use this version due homebrew error:
|
Before this commit, the Core Text renderer relied on a legacy behavior of NSView to keep its content across draws. setNeedsDisplayInRect: drew over parts of the existing content as drawing commands were received, without ever redrawing old content. Layer backed views don't preserve content between draws and may be asked to redraw at any time, and layer backing is default on in the 10.14 SDK. This change adds a way to draw to a CGBitmapContext and then display that in the view's layer. It's similar to the CGLayer path, but I wasn't able to get the CGLayer path to work without hanging or crashing when I scrolled. My best guess from looking at stack traces is that using CGContextDrawLayerInRect to draw a layer into itself doesn't actually copy pixels, but adds the self-draw as an action to be performed when the CGLayer is drawn into a bitmap context. Scrolling stacks these actions, which either hangs or overflows the stack when drawn. The new code is controlled by the MMBufferedDrawing user default, which is on by default on macOS >= 10.14 with this change. Fixes macvim-dev#751.
Before this commit, the Core Text renderer relied on a legacy behavior of NSView to keep its content across draws. setNeedsDisplayInRect: drew over parts of the existing content as drawing commands were received, without ever redrawing old content. Layer backed views don't preserve content between draws and may be asked to redraw at any time, and layer backing is default on in the 10.14 SDK. This change adds a way to draw to a CGBitmapContext and then display that in the view's layer. It's similar to the CGLayer path, but I wasn't able to get the CGLayer path to work without hanging or crashing when I scrolled. My best guess from looking at stack traces is that using CGContextDrawLayerInRect to draw a layer into itself doesn't actually copy pixels, but adds the self-draw as an action to be performed when the CGLayer is drawn into a bitmap context. Scrolling stacks these actions, which either hangs or overflows the stack when drawn. The new code is controlled by the MMBufferedDrawing user default, which is on by default on macOS >= 10.14 with this change. Fixes macvim-dev#751.
Just upgraded via "brew upgrade macvim" and mvim started to this issue. Luckily disabling CORE worked for me. I look forward to the update. |
PR #757 should have fixed this issue. Sorry for the wait. Feel free to re-open if it didn't fix the issue. Note that there's a slight performance impact to scrolling but it should be acceptable, and it's a known issue. |
Great! I will be watching brew for when the update is available. |
@a7hybnj2 I can confirm, if you install the Homebrew version with How I updated:
After that, I drag the MacVim app bundle/icon from the subdirectory of the now open Finder window into my Dock. Done and done. |
if you try to install macvim via |
I just did a fresh install of macOS 10.14 Mojave and found that MacVim has a number of rendering issues while scrolling. The test gets garbled and the window can sometimes go completely black.
Seems like the workaround was to disable Core Text rending in the advanced preferences.
The text was updated successfully, but these errors were encountered: