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.
userbinator
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.
TheTon
A fix so amusing and ridiculous it gets the bug enough attention that Apple fixes it for real.
elicash
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.
whywhywhywhy
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
gcr
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 needed
anotherpaul
I'm on a NEO right now, my Chrome has like 25 tabs open. Doom Emacs running in terminal, Obsidian open, Apple Music, Apple NOtes, etc. I have a lot open...
AND I'm not seeing this issue. What am I missing?
I'm on 26.4.
:shrugs:
EDIT: I guess I wait to update and install the latest version? Maybe the linked page could have stated there's a new regression in newer MacOS versions that introduced this?
taude
Bonus points if you manage to record the Facebook tracking pixel.
amelius
Steve turning in his grave
m132
is any one here using the neo for any coding work ? how is it ?
comments (10)
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.
userbinator
TheTon
elicash
whywhywhywhy
All an App needs on MacOS seems to be a binary and a little .plist
gcr
anotherpaul
AND I'm not seeing this issue. What am I missing?
I'm on 26.4.
:shrugs:
EDIT: I guess I wait to update and install the latest version? Maybe the linked page could have stated there's a new regression in newer MacOS versions that introduced this?
taude
amelius
m132
ing33k