I think the author’s use of a 500Hz display covers up or minimizes a lot of issues. It’s really easy to look at this data and say 8ms click to flash is fabulous even though he has an config that does 4ms.
A better way to interpret this data is to normalize by the vsync interval or the swap chain depth. The slowest config is 2 frames slower than the fastest. At 500Hz this is 4ms extra which is likely imperceptible to everyone but elite pro gamers. At 60Hz this is 34ms extra which is pretty noticeable to even casual gamers.
At one point you could have said the same thing about Blizzard, that everything they did was gold. It’s hard to pinpoint where they went wrong, but it’s not clear to me that it was business model or game format related. Like, WoW was a fabulous success from day 1 and it was a live service game.
No, this scenario works fine. Car audio (and UI) can interleave with CarPlay. I can put podcasts on my center screen, my car manufacturer's navigation in the driver's screen, and the navigation prompts will duck the podcast and interrupt as appropriate. This isn't hypothetical or hard, my car does exactly this today.
Right, this is why video parse / decode ought to be sandboxed. Writing secure code for these formats, especially in C, is really hard. I just sort of glanced at the bug in the repo, but it sounds plausible. It certainly wouldn’t be the first of its kind.
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.
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.
I've also had computers with nvidia, amd (even back when it was still ATI) and intel gpu's, at least since 2006, and can't remember ever having an issue like this.
Not saying it's not an issue, but there is such an incredible amount of hardware configurations that linux supports, so it's a bit weird to say that "linux" in general has suffered a bug like this.
There was a time when it was quite bad, especially if using Wayland and under heavy CPU or I/O loads. I think this has mostly been solved now, but I do recall getting frustrated with the switch to Wayland because of it.
My latest and greatest ThinkPad T14s Gen 6 likes to do it sometimes on cachyos, I can't nail it down from a KDE or hardware issue as it never does it while docked or a external mouse
not necessarily ubiquitous, but you can encounter some issues with "lagging cursor" even today, if you use standard raspbian for example
> usbhid.mousepoll=0
> to /boot/cmdline.txt
> This option was implemented to enforce a mouse polling rate of 62.5Hz which dramatically reduced the XWindow event system update rate in certain circumstances (oddball or "performance" mice can have update rates of 1000Hz, which is silly).
The number is as low as 2. Hell, it may even be 1! I have had a subscription for years, I do not share it, and I read on 2 devices, and they've been hassling me with this nonsense for the past week or so. I'm holding out hope it's just a bug and they'll stop, but if it goes on much longer I will cancel too.
As a long time DF reader I can assure you that John does not use Chrome to browse the world wide web.
You are almost certainly correct in saying he is using it to illustrate his point because Chrome is engineered to be part of the internet advertising complex that commits so many of these crimes against design.
Yes, I would actually be surprised to learn that mode is available on any system. I’ve never seen that anywhere, though I only have a M1 Pro and an M4 Pro (and various Intel Macs).
You’re rendering to a framebuffer exactly 2x the size of your display and then scaling it down by exactly half to the physical display? Why not just use a 1x mode then!? The 1.75x limit of framebuffer to physical screen size makes perfect sense. Any more than that and you should just use the 1x mode, it will look better and perform way better!
Then complain about that. That would make a much more sensible blog post and discussion. Asking for a crazy workaround to a sane problem isn't a great way to get good results, especially with Apple. Beyond the obvious performance pitfall, this scale up to scale down approach will also destroy the appearance of some controls. There is some UI that aims for 1px lines on hidpi modes that will get lost if you do this. It's hardly a perfect mode.
Scaling up before scaling down is a sensible approach, especially when you want to run at a slightly lower scaled resolution. It worked fine up to M3 Pro. So whatever you think of it, it's something that worked fine for many years and suddenly doesn't anymore on the newer MacBooks.
The crazy workaround only needs to be done because of what Apple did probably around a decade ago and probably already heard a bunch of crying about and didn't care. No one removed subpixel antialiasing on their own, we do this bullshit because Apple forced us to to make text look halfway decent.
I can tell you that inside Apple, they have something called the standard question, and it goes something like this: “What are you really trying to do?”
If you haven’t personally filed a bug report at feedbackassistant.apple.com, I recommend that you do so. Title it something like “Poor text quality on LoDPI display”, file it in the Displays component, and in the description explain what you’re seeing. Here’s the critical part: you want to attach images showing what looks bad and what looks better, and why the current behavior is a regression and since when (earlier macOS versions for subpixel AA, earlier GPUs for 2x 1x mode). If possible, use the same display, but get an image of historical macOS when it had subpixel AA, macOS with this 2x 1x mode, Windows 11, and then current macOS at the standard 1x mode. I’m not sure screenshots will capture it, you’ll probably need to use a camera.
I know how they think at Apple. If you come at them with a bug written like OP’s blog, they are going to say it behaves as designed. To get them to fix something, you have to be descriptive about what the real problem actually is: the text rendering looks bad. Then you have to explain what used to work and what you’ve tried and bring receipts (the images). Don’t write a novel; write the shortest bug that fully describes the real problem, includes all of the relevant information including macOS versions, hardware info, and display model, and the evidence of the problem, but don’t include a bunch of emotional text or extraneous information (like SkyLight framework reverse engineering stuff).
Now you might say, “I’m not Apple’s free QA”, and you’ll be right. But, consider that you’re spending this time complaining about a problem online and you’ve spent good money on a display you’d like to use and it’s not working the way you want. Fair or not, you care about the outcome, and at this point you might as well take my advice and file a strong bug to make your case. Dupes help, OP should file one too, but be descriptive about the real problem, not proscriptive about bringing back the crazy workaround that they likely intentionally disabled because on the face of it, it makes no sense.
I do know that they read user bugs in the Displays component, because I have filed a few in there recently and they got fixed and they followed up with me about where they were fixed.
Exactly. Their holy war on the App Stores blunted Fortnite’s momentum at its apogee.
On one hand, I admire their chutzpah. The App Store model has weighed down the entire software industry and has prevented entire categories of new products from growing out of infancy due to anticompetitive practices. Everyone, Apple and Google included, would actually be better off without the App Stores in their present form, and I’d love to see them weakened or eliminated.
But on the other hand, Epic actually accomplished very little in their war, and nowhere near what being unavailable on mobile platforms for years cost them.
Additionally, their refusal to go after Xbox, PlayStation, and Switch never made any sense to anyone except for those with a financial interest in those arrangements. The rest of us were just confused — the console App Stores are the exact same model as the mobile App Stores.
I suspect Epic’s actual reason for not going after the consoles was a bit of realpolitik or cowardice depending on how you look at it. They couldn’t afford to be locked out of the mobile and console stores at the same time, so they invented some tortured rationale for why they could pay the console vendors their 30% but not the mobile vendors. But, this muddied their message and they came up mostly empty handed in the end, and here we are today.
A better way to interpret this data is to normalize by the vsync interval or the swap chain depth. The slowest config is 2 frames slower than the fastest. At 500Hz this is 4ms extra which is likely imperceptible to everyone but elite pro gamers. At 60Hz this is 34ms extra which is pretty noticeable to even casual gamers.