Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Does anyone know if this is fixed in macOS 27?by zuhsetaqi
- Sometimes the cure is worse than the disease.by xnx
- “It was a brilliant cure, but we lost the patient.”by y1n0
- This is a great example of how to make a minimal app bundle with Swift. Thank you!
All an App needs on MacOS seems to be a binary and a little .plist
by gcr - Crazy this would be the case when the MacOS cursor has been buttery smooth and only ever lags if the entire system is about to go down even on 800Mhz G4 Titanium Powerbook this was the behavior.by whywhywhywhy
- Steve turning in his graveby m132
- Oh please. Steve would have made the Mac Book even worse functionally, but it would have had prettier aesthetics.
Dude was the definition of narcissism.
by ActorNightly - Relevant quote from https://www.folklore.org/Shut_Up.html:
We showed [Gates] how the Macintosh mouse cursor moved smoothly, in a flicker-free fashion.
"What kind of hardware do you use to draw the cursor?", he asked. Many current personal computers had special hardware to draw small bitmaps called "sprites", and he thought we might be doing something similar.
- One of the most damning indictments of current software architecture is the laggy mouse which we've all gotten used to on mainstream OS.
The other day my son and I were sitting in front of the XBOX ONE we (try to) use as a Plex client and laughing about how showing a new logo while the machine is doing something meaningless to us is an act of brand destruction and that they should be showing us a Playstation logo instead... And how with the NES you could just hit the power button and start playing. The cursor never lagged like that on the 1984 Mac.
by PaulHoule - Its also one of the most immediately visible degradations of user experience. The cursor is your agent to interact with the computer, an extension of your arm basically. It should be one of the most smooth and responsive pieces of an OS.
I remember a long time ago, early days of Gnome 3 when doing large file operations would hang the cursor. It made the whole system feel like complete garbage, totally unacceptable.
A cursor lagging (or any kind of GUI/user interaction stutters) should be a critical high priority bug, all hands on deck sort of thing. The entire experience of using the damn thing hinges on the responsiveness of the interface and pointing devices.
by thewebguyd - A fix so amusing and ridiculous it gets the bug enough attention that Apple fixes it for real.by elicash
- This is such a nice fix but then you install it's set it up to launch on start and forget about it. 5 years later the bug has been fixed for 4 and I still have tho script record a random pixel every 10 seconds. Never know how to know that the hacky fix is no longer neededby anotherpaul
- You could just put it in your calendar. 'Check if that hacky bugfix at ~/.dirtyhack.sh is still required with chmod -x ~/.dirtyhack.sh'by nehal3m
- I’m not sure what the bug is, but this is a terrible fix. What this is doing is forcing the WindowServer to composite the cursor rather than treat it as a hardware overlay. I suppose the issue must be pretty bad for OP if this helps, but … ugh.by TheTon
- Yeah. It simply shouldn't be falling back to a software cursor in the first place. That's the bug.by BearOso
- Terrible fix but it's a fix that's minimally-invasive and addresses a bug that causes a disproportionate annoyance to the fix. I can imagine your cursor lagging is something that is extremely annoying over time.by nusl
- Reminds me of a fix I wrote a decade ago. My Laptop would sometimes start emitting a high frequency whine when on battery. I figured out it only happened when the CPU went into performance states lower than P2 for power saving.
So I wrote a bash script that auto-started on battery mode and then calculated a hash every few seconds. Boom, whine solved. Terrible fix, but I never measured how much battery it cost me, so it was... fine.
by pbmonster - Before reading the background info, I was going to recommend a much simpler fix, but they actually already mention it in there: "Also the mouse cursor size can be changed."
This was going to be my suggestion because it also fixed a similar CPU/GPU related issue many years ago: Apple's own TV.app would have minuscule color handling differences whenever subtitles would show during a movie. This was driving me nuts while showing a moody black & white film for a movie night - every time a subtitle would pop up, the entire scene's black levels would shift slightly (and it wasn't any kind of adaptive/localized brightness or anything like that, it was the actual rendering).
Some online sleuthing revealed it was GPU related (pure GPU video decoding vs. the CPU overlaying subtitles on the screen), and that bumping up the cursor size (even the tiniest amount) in mouse settings would fix it. It worked.
It's barely noticeable, but I actually prefer the slightly bigger mouse cursor now anyway, so it's part of my standard macOS setup.
by exogen - Do you have links to what you found? That solution sounds plausible in this case.by MontagFTB
- I have found this to be true. I manage an organization with around 600 Apple laptops and now when setting them up I always increase the cursor size slightly. No one complains and it does appear to be a smoother experience.by roody15
- Yes, however, a small change of the cursor size doesn't work for me for the Neo lag (idk about the TV app). I have to set it to a size that is significantly bigger, to trigger the fix. (edit: Added that side note to the gist)by retroplasma
- This issue was related to an old macOS optimization called "detached mode" or FSLP (fullscreen low power). There were related bugs in Chrome and Firefox:
- https://issues.chromium.org/issues/41359717
- https://bugzilla.mozilla.org/show_bug.cgi?id=1747999
macOS skipped compositing when only a single fullscreen surface with a black background was being rendered, but there were many ways for that render path to misbehave.
It only ever affected integrated graphics on dual GPU Macs, as far as I can remember.
by Sidnicious - But at the moment when it lags the system switches from hardware cursor to software cursor (CGCursorIsDrawnInFramebuffer() goes from 0 to 1) so maybe that transition is stalled somehow on Macbook Neo.
With the disclaimer that I have zero knowledge of the MacBook Neo hardware, but I do know a bit about GPUs in general (including having written some GPU-accelerated drivers for Windows and the associated cursor-handling code), I'm going to make a wild guess: this lag is caused by waiting for the GPU command queue to flush.
As a bit of background information: the GPU is fed commands from a queue that the CPU writes to. These commands perform the drawing operations that the GPU is designed to accelerate. A hardware cursor is basically a small bitmap that can be positioned anywhere on the screen and moved around by simply updating position registers (which is normally done per mouse interrupt); the hardware draws it automatically. A software cursor is manually drawn by the graphics stack, which saves what was under it, draws the cursor, and then whenever it needs to be moved, writes the original data back, saves the data at the new position, and then draws the cursor there.
Flushing the command queue is necessary when switching to a software cursor, or otherwise doing software writes to the framebuffer, because you need to wait for the GPU to finish drawing what it has queued, or it may end up drawing over what software wants to draw, including the cursor. Or worse, the command is a blit (e.g. scrolling a window) and you end up with remnants of the cursor at its previous position.
by userbinator - > A hardware cursor is basically a small bitmap that can be positioned anywhere on the screen and moved around by simply updating position registers (which is normally done per mouse interrupt); the hardware draws it automatically
Do modern machines still have custom hardware for cursors? That would surprise me, as a GPU can easily blit a small cursor on top of whatever gets drawn.
by Someone - how do hardware cursors work in a composited desktop?
the cursor could just be another small rectangle texture you position on top of the other surfaces. there is no need to read the framebuffer/write into it, its just a z-stack of 3d surfaces now
by nok22kon - >A software cursor is manually drawn by the graphics stack, which saves what was under it, draws the cursor, and then whenever it needs to be moved, writes the original data back, saves the data at the new position, and then draws the cursor there.
If a hardware layer is not being used the cursor layer will be treated like any other layer in the compositor. Modern compositors don't try and save and write pixels like that. It will just rerender it.
>(which is normally done per mouse interrupt);
It's normally done every frame the compositor makes.
>or it may end up drawing over what software wants to draw
The compositor composites everything at that will be shown on the next refresh of the display. Things don't indepently step on each others toes since it's just the compositor rendering and synchronizing all hardware layers (planes).
by charcircuit - But wouldn't the software cursor operations also go in the queue? I don't see the problem.by jstanley
- >A software cursor is manually drawn by the graphics stack, which saves what was under it, draws the cursor, and then whenever it needs to be moved, writes the original data back, saves the data at the new position, and then draws the cursor there.
AFAIK this hasn't been true for a long time on most platforms, certainly on macOS. The desktop image is composited on the GPU by assembling the underlying windows with appropriate effects like shadows and scrolling/scaling. A software cursor is just another overlay which may also have a transparent shadow.
Actually preserving what was under the cursor and putting it back is the sort of thing you wouldn't do anymore, because that's a cache which requires babysitting based on everything that's underneath and around it.
e.g. On macOS there's full screen zooming for accessibility, and if you wiggle the mouse, the cursor grows in size briefly (maybe even too big for hardware cursor to support).
by unconed - This was a really informative and interesting reply articulated in simple enough terms that I am now interested in GPUs, thanksby bloqs
- This is plausible to me as well. A couple years ago we were trying to make dynamic memory allocation in Vello more robust and explored using async readback of a status buffer. In that case, the async task doesn't wake until the command buffer completes and signals a fence back to the CPU.
Long story short, performance was disappointing and we abandoned the approach. It's easy to believe it's a real problem especially when there are other factors including GPU being clocked down to save power.
Same caveat as parent, I have no direct knowledge of MacBook Neo or this specific issue.
by raphlinus