Skip to content
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

Non-native fullscreen broken with Core Text in macOS Sierra #312

Closed
stranak opened this issue Jul 24, 2016 · 39 comments

Comments

@stranak
Copy link

commented Jul 24, 2016

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.

@chdiza

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link

commented Aug 23, 2016

Have the same issue

@chdiza

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link

commented Sep 19, 2016

still happening on the 2nd gold master of macOS Sierra

@amix

This comment has been minimized.

Copy link

commented Sep 20, 2016

Bump up for re-interest. This is really affecting my zen moment with MacVim 😄

@chdiza

This comment has been minimized.

Copy link
Contributor

commented Sep 20, 2016

We'll need to wait for Sierra to come out first so that the devs can work on it.

@ralphholzmann

This comment has been minimized.

Copy link

commented Sep 20, 2016

Well lucky for us, it gets released today! sierra release date

@amadeus

This comment has been minimized.

Copy link

commented Sep 20, 2016

Can confirm, this breaks for me as well :(

@aapit

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link

commented Sep 26, 2016

🖐🏼 Same problem here! Any news on this issue?

@mario-grgic

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link
Contributor

commented 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 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.

@olimorris

This comment has been minimized.

Copy link

commented Oct 3, 2016

Just to add my voice to the, this is happening to me on macOS Sierra on a 2014 MacBook Air.

@francof

This comment has been minimized.

Copy link

commented Oct 6, 2016

+1

@splhack splhack self-assigned this Oct 7, 2016
@Shigeki1120

This comment has been minimized.

Copy link

commented Oct 8, 2016

+1

2 similar comments
@athom

This comment has been minimized.

Copy link

commented Oct 11, 2016

+1

@qzg

This comment has been minimized.

Copy link

commented Oct 13, 2016

+1

@nicksergeant

This comment has been minimized.

Copy link

commented Oct 13, 2016

Hi folks - can we stop with the +1ing? There is a subscribe button directly to the right of this thread, for the purpose of being notified when there's work being done on this issue:

http://i.nick.sg/d538dbff6c6d4a55bbe0ce91026a37d0.png

The +1s don't add to the discussion, and in many ways can be frustrating for both the developer and those who are only interested in following along with further work on this issue.

@splhack

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

It seems like NSView backing layer(graphic context) will lose all rendering result when MacVim renders cursor.

set guicursor=a:blinkon0
@chdiza

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2016

Is that supposed to be a workaround, or just to demonstrate the nature of the bug? For me, that guicursor setting only stops the disappearing text until I move the cursor, at which point the text disappears again.

It does, however, reveal that if the cursor is on the last line in the window (not the buffer), it's only the text on lines above that one that disappear, while the cursor's line is entirely visible.

@trevvvy

This comment has been minimized.

Copy link

commented Oct 24, 2016

@nicksergeant I don't think people are +1'ing so they can subscribe. When there are 33 open issues on a project, isn't it nice to know which issues are affecting the most people?

Is there an alternate mechanism in github for people to use to indicate their interest in an issue getting sorted?

@nicksergeant

This comment has been minimized.

Copy link

commented Oct 24, 2016

@trevvvy yup, you can add to the 👍 on the issue description itself:

http://i.nick.sg/c6ea9558bf514ef593fb3995798f494d.png

@amadeus

This comment has been minimized.

Copy link

commented Nov 3, 2016

Is there any way I can tip some money to get this fixed? It's really causing me productivity problems and would love to see it fixed asap.

@splhack

This comment has been minimized.

Copy link
Contributor

commented Nov 3, 2016

Have anyone tried 10.12.2?

@ralphholzmann

This comment has been minimized.

Copy link

commented Nov 3, 2016

I gave up and switched to neovim :|

@dimitriacosta

This comment has been minimized.

Copy link

commented Nov 5, 2016

@splhack I'm using 10.12.1 and getting the same problem with fullscreen

@harobed

This comment has been minimized.

Copy link

commented Nov 7, 2016

@ralphholzmann it is fixed with neovim?

@nuc

This comment has been minimized.

Copy link

commented Nov 10, 2016

@splhack Having the same problem at 10.12.2 Beta (16C41b).

@osheroff

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2016

i've been poking at this bug over nights and weekends when I get a bit of time to spare. The bug, near as I can tell, has to do with CoreText and borderless windows. The bug still repros even if you short-circuit the full-screen behavior like so:

diff --git a/src/MacVim/MMWindowController.m b/src/MacVim/MMWindowController.m
index b6c6786..cf7be60 100644
--- a/src/MacVim/MMWindowController.m
+++ b/src/MacVim/MMWindowController.m
@@ -335,7 +335,7 @@
     if (fullScreenWindow) {
         // Delayed entering of full-screen happens here (a ":set fu" in a
         // GUIEnter auto command could cause this).
-        [fullScreenWindow enterFullScreen];
+        //[fullScreenWindow enterFullScreen];
         fullScreenEnabled = YES;
     } else if (delayEnterFullScreen) {
         // Set alpha to zero so that the decorated window doesn't pop up
@@ -743,7 +743,8 @@
         // custom full-screen can appear on any screen, as opposed to native
         // full-screen which always uses the main screen.)
         if (windowPresented) {
-            [fullScreenWindow enterFullScreen];
+            [decoratedWindow setStyleMask:NSBorderlessWindowMask];
+            //[fullScreenWindow enterFullScreen];
             fullScreenEnabled = YES;

             // The resize handle disappears so the vim view needs to update the

(repros even with a window smaller than the screen size)

The other thing I've noted is that what seems to happen is that each draw call is blowing away the previous window state: if you do :redraw!, the window is drawn properly at first, but then the next "partial" draw -- I think when the cursor starts to blink -- gets rid of all the window state before it that's drawn.

@amix

This comment has been minimized.

Copy link

commented Nov 12, 2016

The MMFullScreenWindow.m implementation looks very "complicated", and maybe if we implemented it in a more simple fashion, it could do solve this issue.

osheroff added a commit to osheroff/macvim that referenced this issue Nov 14, 2016
When you set a borderless style on a subclasses window in 10.12, the
original behavior in which you could progressively draw partially on a
stale window seems to be gone; it blanks the thing after each draw. It's
totally unclear to me whether the CoreText engine as written was ever
"correct", or maybe it just "accidentally worked" -- no documentation on
the internets seems to indicate you're allowed to only draw CoreGraphics
updates to a window in drawRect.

This PR works around that by drawing onto a persistent background layer
which we then blit to the screen.

nn-fullscreen seems to work, as do most common operations.  This PR also
makes resizing a CoreGraphics view much smoother; the old code was
pretty flickery.

I haven't dealt with DrawSignDrawType yet; not sure how to trigger that
code path.

maintainers: am I on the right track here? Any tips?

addreses macvim-dev#312 (though not fully, yet).
osheroff added a commit to osheroff/macvim that referenced this issue Nov 14, 2016
When you set a borderless style on a subclasses window in 10.12, the
original behavior in which you could progressively draw partially on a
stale window seems to be gone; it blanks the thing after each draw. It's
totally unclear to me whether the CoreText engine as written was ever
"correct", or maybe it just "accidentally worked" -- no documentation on
the internets seems to indicate you're allowed to only draw CoreGraphics
updates to a window in drawRect.

This PR works around that by drawing onto a persistent background layer
which we then blit to the screen.

nn-fullscreen seems to work, as do most common operations.  This PR also
makes resizing a CoreGraphics view much smoother; the old code was
pretty flickery.

I haven't dealt with DrawSignDrawType yet; not sure how to trigger that
code path.

maintainers: am I on the right track here? Any tips?

addreses macvim-dev#312 (though not fully, yet).
osheroff added a commit to osheroff/macvim that referenced this issue Nov 14, 2016
When you set a borderless style on a subclasses window in 10.12, the
original behavior in which you could progressively draw partially on a
stale window seems to be gone; it blanks the thing after each draw. It's
totally unclear to me whether the CoreText engine as written was ever
"correct", or maybe it just "accidentally worked" -- no documentation on
the internets seems to indicate you're allowed to only draw CoreGraphics
updates to a window in drawRect.

This PR works around that by drawing onto a persistent background layer
which we then blit to the screen.

nn-fullscreen seems to work, as do most common operations.  This PR also
makes resizing a CoreGraphics view much smoother; the old code was
pretty flickery.

I haven't dealt with DrawSignDrawType yet; not sure how to trigger that
code path.

maintainers: am I on the right track here? Any tips?

addreses macvim-dev#312 (though not fully, yet).
osheroff added a commit to osheroff/macvim that referenced this issue Nov 14, 2016
When you set a borderless style on a subclasses window in 10.12, the
original behavior in which you could progressively draw partially on a
stale window seems to be gone; it blanks the thing after each draw. It's
totally unclear to me whether the CoreText engine as written was ever
"correct", or maybe it just "accidentally worked" -- no documentation on
the internets seems to indicate you're allowed to only draw CoreGraphics
updates to a window in drawRect.

This PR works around that by drawing onto a persistent background layer
which we then blit to the screen.

nn-fullscreen seems to work, as do most common operations.  This PR also
makes resizing a CoreGraphics view much smoother; the old code was
pretty flickery.

I haven't dealt with DrawSignDrawType yet; not sure how to trigger that
code path.

maintainers: am I on the right track here? Any tips?

addreses macvim-dev#312 (though not fully, yet).
osheroff added a commit to osheroff/macvim that referenced this issue Nov 14, 2016
When you set a borderless style on a subclasses window in 10.12, the
original behavior in which you could progressively draw partially on a
stale window seems to be gone; it blanks the thing after each draw. It's
totally unclear to me whether the CoreText engine as written was ever
"correct", or maybe it just "accidentally worked" -- no documentation on
the internets seems to indicate you're allowed to only draw CoreGraphics
updates to a window in drawRect.

This PR works around that by drawing onto a persistent background layer
which we then blit to the screen.

nn-fullscreen seems to work, as do most common operations.  This PR also
makes resizing a CoreGraphics view much smoother; the old code was
pretty flickery.

I haven't dealt with DrawSignDrawType yet; not sure how to trigger that
code path.

maintainers: am I on the right track here? Any tips?

addreses macvim-dev#312 (though not fully, yet).
osheroff added a commit to osheroff/macvim that referenced this issue Nov 15, 2016
When you set a borderless style on a subclasses window in 10.12, the
original behavior in which you could progressively draw partially on a
stale window seems to be gone; it blanks the thing after each draw. It's
totally unclear to me whether the CoreText engine as written was ever
"correct", or maybe it just "accidentally worked" -- no documentation on
the internets seems to indicate you're allowed to only draw CoreGraphics
updates to a window in drawRect.

This PR works around that by drawing onto a persistent background layer
which we then blit to the screen.  This PR also makes resizing a
CoreGraphics view much smoother; the old code was pretty flickery.

addreses macvim-dev#312.
osheroff added a commit to osheroff/macvim that referenced this issue Nov 15, 2016
When you set a borderless style on a subclasses window in 10.12, the
original behavior in which you could progressively draw partially on a
stale window seems to be gone; it blanks the thing after each draw. It's
totally unclear to me whether the CoreText engine as written was ever
"correct", or maybe it just "accidentally worked" -- no documentation on
the internets seems to indicate you're allowed to only draw CoreGraphics
updates to a window in drawRect.

This PR works around that by drawing onto a persistent background layer
which we then blit to the screen.  This PR also makes resizing a
CoreGraphics view much smoother; the old code was pretty flickery.

addreses macvim-dev#312.
@splhack

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2016

can you guys test the master branch?

@stranak

This comment has been minimized.

Copy link
Author

commented Nov 20, 2016

can you guys test the master branch?

It works great for me. Many thanks.

splhack added a commit that referenced this issue Nov 20, 2016
Binary targets macOS 10.8+

- Vim patch 8.0.0094
- Fixed Non-native fullscreen issue on 10.12 Sierra (#312)

Script interfaces have compatibility with these versions

- Lua 5.2
- Perl 5.16
- Python2 2.7
- Python3 3.5.2
- Ruby 2.0
@splhack splhack closed this Nov 20, 2016
@nuc

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link

commented Nov 21, 2016

Awesome stuff @splhack 👏 ❤️

@splhack

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2016

@amix praise must go to @osheroff :)

@amix

This comment has been minimized.

Copy link

commented Nov 21, 2016

All praise @osheroff! 👏 ❤️ 💃

@osheroff

This comment has been minimized.

Copy link
Contributor

commented 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 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.

@lakshyaranganath

This comment has been minimized.

Copy link

commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.