You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Non-native fullscreen broken with Core Text in macOS Sierra #312
In Snapshot 104 on Sierra 10.12 Beta (16A254g) when I enable "Use Core Text renderer" and disable "Prefer native fullscreen support", all text disappears. Looks like the background color is drawn over everything. Only the current word under cursor periodically appears and disappears as cursor blinks (and triggers redraw?).
Changing one of the options (i.e. running either CoreText + Native full-screen, or non-CoreText + non-native fullscreen) makes everything work fine.
I can unfortunately also confirm this with the most recent official Sierra (10.12) in combination with the latest stable MacVim 8.0 (110).
Most of the screen is black, except for some areas and a red blinking cursor.
It also happens when I switch back to full screen. Switching to a normal window restores the normal rendering (yikes, that ugly window chrome though!)
Reacted by Andrei Lisnic, Rossen K, Alexandre Côté, Amir Salihefendic, Ralph Holzmann, Trevor Johnston, Lichi Li, Anatoliy Yevpack, arzyu, Prem Sichanugrist and 4 more
This is a bit annoying, since native full screen mode does not return focus to terminal if you launch MacVim GUI from the command line and then ext (I diff files in MacVim GUI and do it in full screen to see files side by side).
Here is an observation that might help the devs with debugging.
If I recall correctly from long ago, non-native mode fullscreen involves painting the full screen with a color identical to that of the Vim background color, but underneath the "actual" MacVim window. (This is to make sure that there aren't borders left uncovered when the screen size isn't an exact multiple of the rows or columns.) All along, you may have seen this if you changed your colorscheme once already in NNFS, from a dark background scheme to a light one (or vice versa). If you made maxhorz or maxvert not be the full width or height, this was especially obvious. Changing the colorscheme to a sufficiently different one would leave the "borders" colored like the previous scheme's background. Going out of FS and back in would fix this.
Anyway, wrt this disappearing text problem on Sierra, you can see that it's this "fake" background painting that's covering the text and the "actual" MacVim window. E.g.: start MacVim, do "colo MacVim" and "set bg=light". Then go into NNFS. The text will disappear underneath the white "fake" background. While still in NNFS, do "set bg=dark". Wait a second, and text will disappear underneath the fake white again. Go out of NNFS and then go right back in. Now the text disappears underneath the (now) grey10 "fake" background.
I have no idea why this is happening on Sierra all of a sudden, but someone who knows what they're doing might now know where to start looking.
thx guys. @nuc yeah this is doing more computation than before (it currently draws offscreen and then copies the whole layer over), so drawRect is some milliseconds slower than with the previous method. There should be plenty of room to optimize it, but it'll need some work to draw to the layer offscreen and then update just the rects needed.
Reacted by Georgios Giannoutsos Barkas and wondger
Activity
chdiza commentedon Jul 24, 2016
Uh oh. I love non-native fullscreen mode. Unfortunately I don't have (and won't have) a Sierra beta to play around with.
amix commentedon Aug 23, 2016
Have the same issue
chdiza commentedon Sep 14, 2016
I can confirm this.
The text will appear for almost a second, then disappear behind the background (except for where the cursor is).
A keypress that scrolls the whole screen will temporarily bring the text back to where it should be, but then after a second it disappears again.
ralphholzmann commentedon Sep 19, 2016
still happening on the 2nd gold master of macOS Sierra
amix commentedon Sep 20, 2016
Bump up for re-interest. This is really affecting my zen moment with MacVim 😄
chdiza commentedon Sep 20, 2016
We'll need to wait for Sierra to come out first so that the devs can work on it.
ralphholzmann commentedon Sep 20, 2016
Well lucky for us, it gets released today!
amadeus commentedon Sep 20, 2016
Can confirm, this breaks for me as well :(
aapit commentedon Sep 21, 2016
I can unfortunately also confirm this with the most recent official Sierra (10.12) in combination with the latest stable MacVim 8.0 (110).
Most of the screen is black, except for some areas and a red blinking cursor.
It also happens when I switch back to full screen. Switching to a normal window restores the normal rendering (yikes, that ugly window chrome though!)
sahibalejandro commentedon Sep 26, 2016
🖐🏼 Same problem here! Any news on this issue?
mario-grgic commentedon Sep 27, 2016
This is a bit annoying, since native full screen mode does not return focus to terminal if you launch MacVim GUI from the command line and then ext (I diff files in MacVim GUI and do it in full screen to see files side by side).
amadeus commentedon Sep 29, 2016
Sorry to bug, any update on this? If I knew C or Objective-C I would totally try to help, but unfortunately I don't :(
chdiza commentedon Oct 1, 2016
Here is an observation that might help the devs with debugging.
If I recall correctly from long ago, non-native mode fullscreen involves painting the full screen with a color identical to that of the Vim background color, but underneath the "actual" MacVim window. (This is to make sure that there aren't borders left uncovered when the screen size isn't an exact multiple of the rows or columns.) All along, you may have seen this if you changed your colorscheme once already in NNFS, from a dark background scheme to a light one (or vice versa). If you made
maxhorzormaxvertnot be the full width or height, this was especially obvious. Changing the colorscheme to a sufficiently different one would leave the "borders" colored like the previous scheme's background. Going out of FS and back in would fix this.Anyway, wrt this disappearing text problem on Sierra, you can see that it's this "fake" background painting that's covering the text and the "actual" MacVim window. E.g.: start MacVim, do "colo MacVim" and "set bg=light". Then go into NNFS. The text will disappear underneath the white "fake" background. While still in NNFS, do "set bg=dark". Wait a second, and text will disappear underneath the fake white again. Go out of NNFS and then go right back in. Now the text disappears underneath the (now)
grey10"fake" background.I have no idea why this is happening on Sierra all of a sudden, but someone who knows what they're doing might now know where to start looking.
olimorris commentedon Oct 3, 2016
Just to add my voice to the, this is happening to me on macOS Sierra on a 2014 MacBook Air.
francof commentedon Oct 6, 2016
+1
19 remaining items
WIP: Fix problems with non-native fullscreen and mac 10.12
WIP: Fix problems with non-native fullscreen and mac 10.12
WIP: Fix problems with non-native fullscreen and mac 10.12
Fix problems with non-native fullscreen and mac 10.12
Fix problems with non-native fullscreen and mac 10.12
splhack commentedon Nov 20, 2016
can you guys test the master branch?
stranak commentedon Nov 20, 2016
It works great for me. Many thanks.
MacVim Snapshot 116
nuc commentedon Nov 21, 2016
Thanks for the fix!
Unfortunately, it feels a bit laggy, especially when moving the caret around. It doesn't feel slow in the native full-screen mode though 🤔
So, I think I will be sticking in the native full-screen mode for now.
amix commentedon Nov 21, 2016
Awesome stuff @splhack 👏 ❤️
splhack commentedon Nov 21, 2016
@amix praise must go to @osheroff :)
amix commentedon Nov 21, 2016
All praise @osheroff! 👏 ❤️ 💃
osheroff commentedon Nov 21, 2016
thx guys. @nuc yeah this is doing more computation than before (it currently draws offscreen and then copies the whole layer over), so
drawRectis some milliseconds slower than with the previous method. There should be plenty of room to optimize it, but it'll need some work to draw to the layer offscreen and then update just the rects needed.whilelucky commentedon Mar 12, 2017
Thanks for your work on this @osheroff 👍 🥇 Is there any progress being made towards optimizing the draw lag or has that been abandoned?
Sadly, like @nuc stuck with using the native full-screen mode for now.