The display controller and render device are completely distinct logical devices, even though they are often grouped in a "GPU". On mobile architectures they are quite far separated, leading to annoying problems surrounding what we on Linux call "split drm devices".

Updating plane properties such as to move the cursor plane around or disable it would by itself not block on render activities, as they are completely distinct blocks.

The render hardware could be powered down, but I doubt powering it up and compositing the cursor would take long enough to complete to cause any noticable lag.

Under the Linux APIs, updates to the display controller are done through KMS atomic commits, and one mistake you could do display-server side would be to provide a fence in this atomic commit that the scheduler will use to wait on long-running GPU work before using the provided graphics buffers. Under this API, none of the changes - including mouse movements - would then be applied until that fence is signalled. Changing plane associations can lead to resource reallocations that can be a bit heavy.

Not sure if the kernel driver in macOS works anything remotely similar to this, and the driver could also just be dumb and block on unrelated things ("let's just wait another vblank to see this apply....", "as we only need one plane now let's power down hardware and wait for that to settle..."). It could also just be windowserver that waits for work to finish on its own, not providing any cursor updates in the meantime.

The reality is that it will take reverse engineering or looking at actual code to know what's going on.

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.

This was a really informative and interesting reply articulated in simple enough terms that I am now interested in GPUs, thanks

But wouldn't the software cursor operations also go in the queue? I don't see the problem.

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

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

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

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

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.

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)

Do you have links to what you found? That solution sounds plausible in this case.

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.

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.

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.

You could just put it in your calendar. 'Check if that hacky bugfix at ~/.dirtyhack.sh is still required with chmod -x ~/.dirtyhack.sh'

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.

  % Overlay plane compatibility hack for cg4 frame buffer.
  % This is a nebulous layer abstracted from a messy program, to make it run 
  % on generic NeWS servers. It should be rethought and rewritten. Repent!
  % 
  % Requires the devices /dev/cgfour0, /dev/cgfour0_ovl, and /dev/cgfour0_ove
  % (which can all be major 39 minor 0, or whatever), and the following patch 
  % to the NeWS 1.1 server sources (but X11/NeWS doesn't need to be patched!),
  % in order to take advantage of a cg4 under NeWS 1.1 (Otherwise it falls back
  % to using exclusive-or). 

  % Damn damn damn! X11/NeWS Version 1.0 FCS on a cg4 can open up the
  % enable plane, but there's a bug that trashes the enable plane color map,
  % so we can draw in gray scales but we can't draw in white (black?).

[flagged]

That’s amazing! I am just imagining a room full of programmers with slightly divergent crontab start times all playing a "moo" sound effect, seemingly at random... not a bad ambient information radiator, actually!

“It was a brilliant cure, but we lost the patient.”

The Meta EULA does NOT allow you to record their tracking pixel.

Swift also has an interpreted mode, you can just

  #!/usr/bin/evn swift
  import Foundation
  print("Hello, world")

and chmod +x hello.swift and execute it.

Instead of doing swift in bash and calling swiftc, you can always shell out to Process() from inside a Swift script instead.

No

guard is an inverted if statement, with the additional requirement that the branch must exit the parent scope. It's useful sometimes for readability, particularly for avoiding the "pyramid of doom" when you have a lot of preconditions that need to be checked:

    if fooOK 
        if barOK {
            if bazOK {
                // do something
            }
        }
    }

can be written as:

    guard fooOK else { return }
    guard barOK else { return }
    guard bazOK else { return }
    // do something

Obviously there are other options (like writing a negated if), but sometimes guard is more readable. It's a style thing.

The more important use case for guard is that 'guard let' statements can pattern-match and introduce bindings that are valid for the rest of the scope:

    guard let foo = someOptional else { return }
    print(foo);

This is useful enough that Rust copied it in the form of 'let ... else {}' statements (but did not bring over boolean guard statements).

    return unless fooOK;
    return unless barOK;
    return unless bazOK;
    # do something

guard has two advantages: the compiler ensures that you exit the current scope if the condition does not hold (via return, break, continue, etc), and bindings established in the guard clause (e.g. let foo = optionalBar) remaining in scope after the guard block, rather than inside it like an if block.

Not real work. It's an amazing couch laptop, though. I do have a full CLI tooling pipeline setup, though. I mostly read, research, and write on it. Chrome tabs galore open, Obsidian, etc...

It's pretty amazing at the price point. Thought last year the M4 Airs were on sale for $749 -- I'm doubtful we'll see that price again on those....

I do, and I love mine. I program relatively low-resource software, so power is not an issue.

I think this ^ and the "Steve in his grave" comment should be a red flag for Apple execs.

Being flawless and polished at UX, hardware experience, and CX in general are the core of Apple's identity and revenue. Granted, the "hold it like this" thing was a huge gaff.

I also think the Neo is a culture miss that is diluting their brand. Their logo is synonymous with "expensive" and "quality" but the Neo is affordable and now it has cursor stutter.

What's the big deal?

It's just a simple one-liner

curl github.com/trustworthyguy/fix_everything | sh

And it all works. Not like recompiling entire kernel to play an mp3.

/s obviously

That was like 20 years ago. My computer insists on downloading gigabytes of videos at random (correction: specifically when I use the hotspot) because maybe I have a video screensaver enabled.

I had to set up a daemon to kill the downloader every 10 seconds.