41–50 of 115 posts
ah yes, the famous mac "Just works" OS
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.
Steve turning in his grave
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.
Sun's framebuffers with 8 bit color + 1 bit monochrome + 1 bit enable (like the cgfour / GX aka Lego graphics accelerator) put the cursor in the monochrome layer, and NeWS supported it as an overlay plane, an optimization of xor drawing and undrawing. The enable layer would switch between the color and monochrome layers on a per-pixel basis.
With NeWS, I could open up the enable and monochrome layers directly and draw into them with PostScript to perform temporary non-destructive highlighting, and make monochrome overlay windows that didn't damage the color windows underneath. But it was a bit of a hack (much uglier than this cursor lag fix). Here is a window subclass that lifts a monochrome window into the overlay plane so it doesn't damage color windows behind it:
https://donhopkins.com/home/archive/psiber/cyber/overlay.ps
% 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?).
https://donhopkins.com/home/archive/psiber/cyber/mics.ps
And the popup pointing hand shaped callout window also used it so it didn't have to repaint the color window underneath when you moved or dismissed it:
Round rect corners are to blame? The root cause for the issue is probably (I'm not an Apple developer) due to huge round rectangles on the window shape corners. Rendering the window with the corners would include rendering whatever other windows and widgets under the window. (Which will have a lag and some more operations with transparency, which the developers probably want to avoid - while I'm not sure about this p…
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…
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 di…
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…
But wouldn't the software cursor operations also go in the queue? I don't see the problem.
Earlier quoted context omitted.
linux was plagued for a long time by lagging mouse cursor
I've been using Linux every day for the last 17 years, and that's the first time I'm hearing this. I'm genuinely surprised. The way you word it, it looks like a famous ubiquitous problem. Mind sharing any details?
Earlier quoted context omitted.
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 di…
Since this is but an iPhone crammed into a laptop, could this behaviour stem from the fact that iPhones generally need not render a cursor?
EDIT: Also note that there is nothing new with the Neo here, as all Macs since the M1 have used the same chip architecture as the iPhone.
Desktop GPU designs did not focus on tiny efficiency gains, and often only has a primary plane, a single overlay plane (for e.g., a video), and a dedicated cursor plane. Some even have to share a single overlay plane between all connected displays. It's a recent thing for desktop GPUs to get more flexible in this area, in part to improve laptop battery life in the cases where the laptop is almost entirely idle.
(For those unaware, a "plane" here is the entity in the display controller you configure to show a rendered graphics buffer, in a particular location and with particular transforms. You commonly have one plane that just covers the whole screen, and then sometimes put dynamic content on top in other planes so you can avoid having to redraw the main buffer when smaller bits of it change, like a video player or cursor. You could also e.g., scroll by rendering an entire document in advance and then move the plane around to reveal parts of it.)
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…
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.