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

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

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.

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.

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

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.