Hacker News Reader

Comment by KarlKemp | Hacker News Reader

I'm not really sensitive about this issue, but recently had an experience that has raised my interest: after making some regretful mistake, I had to use an an UEFI shell to shuffle some boot settings around (the one that comes with the Clover bootload).

And typing was..noticeably more "immediate". It was bewildering, sort of like wearing prescription glasses for the first time.

I like all the extra stuff editors and the OS do these days and don't wish to turn the time back, and I doubt it's realistic to achieve both. But maybe someone like Apple, being fully integrated, should take a shot at it. It'd be the sort of polish that makes using a computer enjoyable.

View on HN

In this case what you were experiencing might have been the lack of compositor, which adds a 16ms delay, or just using a slow editor. The theoretically best possible average latency under a compositor model at the top of the screen is 16+(16/2)=24ms which isn't that far from the 30ms I observe at best on macOS. Cutting the compositor would still halve average latency.

Unfortunately Apple shows no interest in getting rid of that delay, while Microsoft is moving towards sometimes using hardware overlays to avoid that (see raphlinus's comment about DirectFlip), and Linux lets you disable it at the cost of tons of artifacts. Apple only recently tried to add compositor bypass for fullscreen Metal apps but the way they did it is super opaque and I have never succeeded at getting it to trigger and they have no example program that they say definitely does it.

Do the artifacts really matter for terminal use? AIUI the main drawback of not using a compositing layer is screen tearing - which is something that's only really apparent wrt. video or animation that takes up a large fraction of the screen. It would be nice if we could be more selective about when to enable compositing, especially since even Wayland now has support for bypassing the compositing step in full-screen apps.

Thanks for reminding me. Years ago, on another iMac, I did this to turn off VSync. I recall it did work. I don't know if it does work on recent macOS's though.

https://stackoverflow.com/questions/12345730/how-to-disable-...

A single fullscreen window where the content view is either a Metal or GL layer, and nothing else in the layer hierarchy should be sufficient.

Using Instruments’s Metal and Display instruments you can see the drawables and the vsync they present on. Bring up the app switcher with cmd-tab to trigger the compositor and you can see the difference in Instruments.

One weird thing is, you can configure a 2 or 3 drawables swapchain on the Metal layer. Using 2 doesn’t work for me when the compositor bypass enables - it always locks to 30Hz, even when doing nothing but drawing a solid color. When the compositor is enabled, the 2 buffer swapchain runs at full speed, presumably because it’s effectively triple buffered. But, in the 3 buffer case, in fullscreen, you can see that you will just use 2 buffers provided you can render fast enough, so it seems like there’s no latency cost to the 3 drawable config in the ideal case.

Yah it was over a year ago so my memory is hazy but as far as I know I tried to do exactly that. I watched the WWDC talk and made sure I met all the conditions they say, and tried to use Instruments and Is It Snappy to verify it and I didn't seem to be triggering compositor bypass and had no way of figuring out why not. What I really want is a single open source demo app on Github where someone has said "I tested and this triggers Metal compositor bypass and I confirmed with Instruments and/or Is It Snappy"

Reply on news.ycombinator.com