I see flickering like crazy when I adjust the screen brightness on my M5 Macbook Pro on Tahoe.
But it's especially obvious when it dims itself based on ambient room brightness, I can actually see the vertical refresh happening as I move from a fully bright room to a dim one.
I checked and that's definitely the black and white version of the one encoded in the file.
Someone build a very simple OCR tool that successfully extracted the base64[1]. The only difference besides the lack of the document tracking ids at the bottom is the original was pink on blue for the first page and has some pink text on the second.
I don't know why I'd trust crypto companies with my company's money given the general lack of regulation; outrageous history of massive fraud, scams, security breaches and simply insiders running away with money; short history of these companies; lack of trusted deposit insurance; lack of reversibility; suspicious claims of guaranteed high "risk free" rates of return; and frankly, the general seediness of seemingly everyone involved.
More importantly, not only are those regulations not in effect, the final regulations haven't even been written or approved yet - which brings up certain questions about how a stablecoin could be compliant with them.
And of course, even if a US-based stablecoin is well regulated, it still doesn't make these foreign "savings" account companies offering guaranteed high rates of return is a safe place to park your money.
Everything about it feels scammy. The claim of compliance against non-existent regulations, too good to be true guaranteed high rates of return, companies set up in questionable jurisdictions and the emotional appeals of not being a sucker and fear of missing out? All that's missing is a suggestion that there's a limited time left to act.
> > (tranferring USDC or another GENIUS-compliant stablecoin on Solana).
> > The Genius act regulates stablecoin provision. US-issued stablecoins are backed by government bonds with proof of reserves. USDC and PyUSD are compliant already, USAT exists because USDT isn't compliant.
No.
> More importantly, not only are those regulations not in effect, the final regulations haven't even been written or approved yet - which brings up certain questions about how a stablecoin could be compliant with them.
No. The GENIUS Act is in effect, it was signed on July 18, 2025, becoming Public Law No: 119-27.
> No. The GENIUS Act is in effect, it was signed on July 18, 2025, becoming Public Law No: 119-27.
The law itself isn't the regulations. The law authorizes and directs regulators to create the regulations.
Moreover, the GENIUS Act doesn't become effective until January 18, 2027 (18 months after it was passed) or 120 days after regulators issue final regulations, whichever is earlier.[1][2]
The regulations for it are still being developed across dozens of state and federal regulatory agencies. The only thing someone like Tether did was get an existing bank to issue it which is a basic requirement to qualify as stablecoin issuer at all.
The 1200ms was an estimation, but it's definitely closer to 1200ms than it is for 250ms for me. There's definitely a difference in set up here- I'm on a Macbook Pro with an M1 Pro chip.
From a screen recording, I count 53 screen-recorded frames from the apparent start of the animation (which occurs after it's invoked) to desktop widgets becoming transparent (which appears to be the point input is no longer blocked). IINA says the video is 50.582 fps (very strange frame rate?) so that would be ~1050ms.
Of course, that doesn't include any input latency or the display latency, so I also took a video with my phone. I took two trials and I recorded a full 1.08 seconds from key depression to transparent widgets. I did two more with Reduce Motion on and got the exact same time.
I am very curious what your set up is, because I am invested in getting this as close to 8.3 ms as possible.
edit: For comparison, my Linux desktop with a similar experimental set up, this takes about 24ms from key depression to the next desktop becoming visible. The only experimental difference is that I had to switch to the "slow mo" camera to record the difference, and I have a 240hz monitor. The desktop is also considered one of the slower ones (GNOME).
TLDR: It takes 1.08 seconds, on my Macbook, to complete a desktop transition.
Not sure why yours is so much slower than mine. Mine is definitely 250 ms long or 15 frames from the time I hit the shortcut.
I used the onscreen keyboard viewer to get visual feedback when the shortcut was pressed and recorded audio so I could hear it being pressed. I even recorded it a second time using OBS to ensure I was at 60 fps and trimmed the whole segment down to just the animation and sure enough, the video is exactly 250 ms long according to IINA.
Also, I don't have any visible delay between pressing the key and the animation starting. The animation starts on the same frame as when the shortcut is recognized by the onscreen keyboard viewer (which is the same time as I hear it being pressed) in the recording. The keyboard delay must be < 16.6 ms.
You might not be aware of this, but you are in possession of a secret treasure that many MacOS users desperately want!
There is some input display on Macbook Pros, but that'd account for easily <100ms of the difference we're seeing (I'm holding `control` and measuring from depression of the arrow key).
I tried changing screen resolution, quitting apps like Rectangle, etc. No dice.
In digging more deeply than I had before, I did find some things which were rumored to speed it up. Disabling multi-color preview, and disabling "displays have separate spaces". (I am using only one display). This shaves off some time (taking about 950ms)! (!!!)
There is also a four-finger gesture which, if done fast enough, appears to speed things up. But it's difficult to reproduce and often "overshoots" to other spaces.
I have a few questions, if you'd oblige:
- Are you also using ProMotion (120hz)? (The biggest thing I can find to speed this up is switching to 60hz, but this does not quite get to 250ms).
- Are you also switching using ctrl+arrowkey(left/right)? (Ctrl+number is notably faster, but not what I'm looking for.)
- Were you using MacOS before this M1 Pro? (This is my first MacOS machine, I'm wondering if there might be some hidden configuration carried over from a previous install with faster transitions).
It depends which key combination or trackpad gesture is used to trigger the desktop switch, because they use different animation curvdes. It looks like they have different application focus or redraw behaviour too.
- Control-Left/Right takes about 1 second.
- Four-finger swipe left/right takes about 1 second.
- Alt-Tab to an app on another desktop takes about 0.25 seconds.
I'm using Sonoma 14.8.3, but from the comments it sounds like the timing distinction is similar on other versions.
While I don't quite have the same problems as others have, there are some pain points.
Stepping through the debugger too fast will sometimes put the debugger in a weird state where step never breaks again and all other breakpoints stop working.
Git pull through the UI with stash and merge can blow away your local changes if there is a conflict. The changes aren't stashed. They're just gone.
Xcode likes to sometimes recompile files that haven't changed slowing everything down, sometimes significantly depending on the file. No idea why.
It can get very confused if you're missing a parenthesis in the wrong place in a SwiftUI View leading to opaque swift compiler errors about code being too complex.
Even mildly complex use of a swift #Predicate will cause an error about it being too complex forcing you to break them down into smaller pieces and even then it takes far too long to build even on a brand new machine.
The simulators are quite slow to start/update/run and xcode sometimes fails to shut them down completely when quitting leading to them just continually running eating memory unless you kill the processes manually.
The simulators also are really limited in their functionality. No background processes, spotlight, network degradation simulation, out of memory killer, etc.
The profiler sometimes just fails to start an app correctly, immediately ending a run forcing you to close the profiler and reopen it again before it'll start working.
Symbol refactor (rename) can be painfully slow where the UI just locks up until it can find all the references.
Xcode likes to duplicate package dependencies in xcodeproj. It just creates new hashes for the same library and adds it as a dependency over and over again, so when the link phase happens, it adds libraries repeatedly over and over and over again unless you manually clear them out. Not sure what causes this, perhaps updating the version or merges between users.
I may be wrong, but the simulators seem to be Intel binaries which mess with audio since the last macOS update I did, so no zoom calls with XCode open for me.
> Hey, I'd agree with this-- and it's worth noting that 17^2 - 5^2 > 16^2, so even 1MPH slower would likely have resulted in no contact in this scenario.
Only with instant reaction time and linear deceleration.
Neither of those are the case. It takes time for even a Waymo to recognize a dangerous situation and apply the brake and deceleration of vehicles is not actually linear.
> It takes time for even a Waymo to recognize a dangerous situation
Reaction time makes the math even better here. You travel v1 * reaction_time no matter what, before entering the deceleration regime. So if v1 gets smaller, you get to spend a greater proportion of time in the deceleration regime.
> linear deceleration.
After reaction time, stopping distance is pretty close to n^2. There's weird effects at high speed (contribution from drag) and at very low speed, but they have pretty modest contributions.
I think the strategy is a lot more nuanced than that.
In any case, with zero reaction time, linear deceleration time to stop is proportional to velocity squared. With reaction time, the linear deceleration time is that plus the velocity times the reaction time.
so the two cases we're comparing are 17 * r + (17^2 - 5^2) vs. 16 * r + (16^2), or 17 * r + 264 vs 16 * r + 256. As long as reaction time isn't negative, a vehicle that could slow to 5MPH starting at 17MPH could slow to 0MPH starting at 16MPH.
(There are weird things that happen at <2.5MPH reducing deceleration to sublinear, but the car moves only a few inches at these speeds during a panic stop).
I don't think that's a great analogy since a sailboat's right-of-way isn't unlimited and it can certainly be found at fault for a collision with a triple-E container ship - especially given maritime law uses the comparative fault system where fault is shared between parties.
For instance, a sailboat must alter course if a collision can't be avoided by the give-way vessel alone:
Rule 17(b):
> When, from any cause, the vessel required to keep her course and speed finds herself so close that collision cannot be avoided by the action of the give-way vessel alone, she shall take such action as will best aid to
avoid collision.
So if you sail your boat into a container ship and it tries to give way, but doesn't have the ability to do so quickly enough to prevent a collision, you're violating the rules if you don't also alter course as well.
Plus, if we're going to connect this to a pedestrian, if a sailboat suddenly cut in front of a container ship with zero concern for its limited maneuverability/ability to stop, the sailboat would also violate Rule 2 by neglecting precaution required by seamen and failing to consider the limitations of the vessels involved.
But it's especially obvious when it dims itself based on ambient room brightness, I can actually see the vertical refresh happening as I move from a fully bright room to a dim one.
reply