I built a macOS tool to hold ProMotion’s refresh rate fast and steady (HzHold)

Blooey

AshX As someone who is sensitive to low frequency flicker and is trying to evaluate whether higher refresh rates would improve things, this is really useful.

Thanks, that’s great to hear. On my Mac, HzHold clearly increases the frequency and visual uniformity of temporal behavior. It’s easy to see in the pixel-inversion tests when ProMotion idles near 24 Hz compared with when it holds steady at 120 Hz.

AshX I’ve often wondered why the MiniLED MacBook Pros allow you to lock the refresh rate at 60Hz, but not 120Hz.

I have too. Hence HzHold. In full fairness to Apple, they can guarantee variable-refresh compatibility because they control the entire built-in display pipeline down to the hardware. Since there isn’t a mainstream need for a higher fixed scan-out frequency, they’ve understandably chosen to keep those modes hidden and reclaim the power savings. Fixed refresh options exist mainly for video standards and workflows that require them. For niche cases like instruments, macro capture, or anyone who prefers temporal consistency, a steady high cadence can still be useful. HzHold doesn’t unlock a mode but keeps the system refreshing at its maximum cadence while it’s active. Apple could almost certainly offer the same result more efficiently as a native display mode if they ever decide to expose it.

AshX Curious how this performs with Stillcolor enabled.

Stillcolor disables OS-level quantization at the first stage, before the frame is handed off to the display, which is very cool. If those bits could be truncated and passed directly without further quantization, that would be the gold standard for all Mac hardware. On the internal ProMotion panel, though, the timing controller still appears to apply its own quantization for dithering and inversion. Without Stillcolor, the OS pre-quantizes the color values so they can pass through the controller unchanged. With Stillcolor active, the raw high-precision values no longer align with the controller’s native steps, so the controller quantizes them itself. In effect, it’s a choice between panel quantization with Stillcolor or OS quantization without it. HzHold works at the last stage in the pipeline, keeping the refresh cadence fast and steady so any temporal patterns remain consistent regardless of their source.

AshX Unfortunate it’s only compatible with MacOS 26 because I don’t think anyone here has found the latest OS tolerable.

That makes sense. The current build targets macOS 26 (“Tahoe”) only because that’s the hardware and environment I can test properly. The App Store expects developers to verify each supported platform before submission, so I stayed within what I can confirm works reliably.

Each macOS release can change how much of the interface operates in higher-than-panel-native precision before quantization. It's reasonable to expect that Tahoe’s Liquid Glass design calls for more high-bit alpha blending than a flatter UI. Maintaining a high refresh cadence helps keep those temporal behaviors consistent either way.

I also test the UI with a microscope and slow-motion capture, and the stability improvements visible in the pixel-inversion tests appear to carry through to the Tahoe interface as well. I may open a TestFlight with a lower target OS at some point, but for now I’d love to hear observations from anyone already on Tahoe.

AshX

Blooey"#p47556 Thanks, that’s great to hear. On my Mac, HzHold clearly increases the frequency and visual uniformity of temporal behavior. It’s easy to see in the pixel-inversion tests when ProMotion idles near 24 Hz compared with when it holds steady at 120 Hz.

This is very interesting. So even though you’re getting more dither frames with an increased refresh rate, the theory is that perhaps the higher frequency is worth the trade-off. I’d love to hear about your own sensitivities and how this impacts your symptoms.

Blooey If those bits could be truncated and passed directly without further quantization, that would be the gold standard for all Mac hardware. On the internal ProMotion panel, though, the timing controller still appears to apply its own quantization for dithering and inversion.

I appreciate this detailed explanation. Many of us have just being guessing, but it seems like you have a much more thorough understanding of what is occurring in the rest of the display pipeline.

Blooey Without Stillcolor, the OS pre-quantizes the color values so they can pass through the controller unchanged. With Stillcolor active, the raw high-precision values no longer align with the controller’s native steps, so the controller quantizes them itself. In effect, it’s a choice between panel quantization with Stillcolor or OS quantization without it.

Have you noticed a marked difference between the GPU dithering and the TCON FRC dithering? Given how interconnected these two processes are, I wonder if disabling GPU dithering destabilizes the display at all?

In terms of symptoms, GPU dithering feels immediately worse on all MacBooks. The panel FRC seems to be tolerable for slightly longer.

Blooey HzHold works at the last stage in the pipeline, keeping the refresh cadence fast and steady so any temporal patterns remain consistent regardless of their source.

Interesting. I would have assumed it would be utilized earlier in the chain as the refresh rate is affecting how many dither frames are processed.

Blooey Each macOS release can change how much of the interface operates in higher-than-panel-native precision before quantization. It's reasonable to expect that Tahoe’s Liquid Glass design calls for more high-bit alpha blending than a flatter UI. Maintaining a high refresh cadence helps keep those temporal behaviors consistent either way.

This seems to explain why Tahoe, and other versions of MacOS, make usable devices uncomfortable.

I’m curious if from a theoretical perspective you can chime in on the differences between the older Retina screens cited as being capable of “millions of colors” on the M1 MacBook Air and the M1/M2 13” Touchbar MacBook Pros. There is a clear difference between the M2-M4 MacBook Airs that use the newer Liquid Retina LCD screens.

These are all 60Hz screens, of course, but it seems that the older Retina displays use much less processing on the internal panel compared to the later devices. My guess is that those internal panels are 8-bit and the new Liquid Retina, 14”/16” MiniLED, and Studio Display Macs are 8-bit+FRC. And if the former are 8-bit+FRC, they don’t seem quite as aggressive as the MiniLED or MBA Macs.

It’s very difficult to identify what is going on under the hood as it relates to the OS and display processing. Apple Silicon seems much less predictable than the Intel era.

Blooey

Rowe I figured out a hacky way to lock my Macbook Pro to 120hz a while back and have been using it since. I only find the screen tolerable with it on.

Brilliant. You’d be surprised how similar the approach has to be with HzHold, just without the clock or gadgetry. Like your setup, it doesn’t unlock a mode but keeps the system refreshing at its maximum cadence while active. Apple could almost certainly offer the same result more efficiently as a native display mode if they ever decide to expose it.

Rowe I've bought the app, and this is a nicer way to do it. Seems to use the same system resources, but much less of a faff to setup.

That’s great to hear, and thanks for picking it up. And best of all, you don’t need a black wallpaper anymore. HzHold itself uses very little CPU or GPU, but it does keep overall system activity higher than when the system is idle. Once you’re using the Mac normally, that activity tends to blend with the existing system load.

Rowe But please add an option to hide the app icon from the dock (this is the only thing I prefer about the other method).

Noted on the Dock icon. I’ve been considering that trade-off and might add a menu bar option in a future update. I’m just cautious about going completely headless since the Mac App Store generally prefers visible, user-accessible interfaces.

Blooey

AshX This is very interesting. So even though you’re getting more dither frames with an increased refresh rate, the theory is that perhaps the higher frequency is worth the trade-off. I’d love to hear about your own sensitivities and how this impacts your symptoms.

Yes, pretty much. Though I’d frame the trade-off the other way around: as modulation depth decreases or frequency increases, the potential visual risk decreases. That lines up with the IEEE PAR1789 flicker reference (Miller & Lehman, 2015), which outlines safe combinations of frequency and modulation depth.

I’m not suggesting PAR1789 was written for displays, but its math describes the same kind of amplitude–frequency tradeoff that could apply here. Temporal dithering is just another form of modulation.

For example, an 8-bit + FRC signal has a modulation depth of about 0.4 percent (1 / 2⁸ × 100). On the PAR1789 chart, that level corresponds to a no-effect minimum frequency of about 40 Hz.

In a four-frame temporal pattern, the modulation frequency is the refresh rate divided by four. At 24 Hz, the pattern repeats six times per second, while at 120 Hz, it repeats thirty times per second. 30 Hz is still below the 40 Hz no-effect threshold, but it moves the behavior from the high-risk to the low-risk region of the chart, which is a significant improvement.

The math provides useful context even if we don’t attempt to directly measure the modulation frequency of dithering:

6-bit + FRC = 1.6% modulation depth, 100 Hz no-effect minimum
8-bit + FRC = 0.4% modulation depth, 40 Hz no-effect minimum
10-bit (native) = 0.1% modulation depth, 10 Hz no-effect minimum

By holding 120 Hz, HzHold moves a four-frame pattern from 6 Hz to 30 Hz, placing it inside the low-risk zone where temporal changes are much less noticeable. The higher the native bit depth of the panel, the lower the modulation depth and the less visible the temporal behavior becomes.

AshX Have you noticed a marked difference between the GPU dithering and the TCON FRC dithering? Given how interconnected these two processes are, I wonder if disabling GPU dithering destabilizes the display at all?

Mathematically, one high-precision-to-native dither is cleaner than truncating to 10-bit and letting the panel’s FRC finish the job, since it avoids a second quantization step. My hunch is that I’d prefer the look and feel of OS-level dithering for that reason.

AshX In terms of symptoms, GPU dithering feels immediately worse on all MacBooks. The panel FRC seems to be tolerable for slightly longer.

That’s got me thinking. Most modern Mac panels receive a 10-bit signal from the OS, even when the panel itself is 8-bit with FRC. The OS and GPU render internally at higher precision, often 16-bit per channel, then quantize that to 10-bit before sending it to the display controller. From there, the panel’s timing controller applies its own FRC to approximate the missing steps.

So if OS-level dithering is disabled and the signal is truncated to 10-bit, about one quarter of those 10-bit values would align perfectly with 8-bit boundaries and could pass through unchanged, while the rest would still require the panel’s FRC. That might explain why some setups look a little steadier but not completely stable.

Blooey HzHold works at the last stage in the pipeline, keeping the refresh cadence fast and steady so any temporal patterns remain consistent regardless of their source.

Interesting. I would have assumed it would be utilized earlier in the chain as the refresh rate is affecting how many dither frames are processed.

I probably didn’t explain that very well. What I mean is that there isn’t really another process further down the chain from what HzHold affects. It doesn’t touch the image pipeline directly but influences temporal stability by maintaining frequency rather than changing modulation depth. Modulation can occur at several layers, but the refresh cadence itself sits at the foundation, so keeping that steady helps all temporal effects stay consistent.

And as described in PAR1789, frequency is just as important as modulation depth in determining the visual impact of temporal modulation, and to a large extent, higher frequency can compensate for greater modulation depth.

AshX I’m curious if from a theoretical perspective you can chime in on the differences between the older Retina screens cited as being capable of “millions of colors” on the M1 MacBook Air and the M1/M2 13” Touchbar MacBook Pros. There is a clear difference between the M2-M4 MacBook Airs that use the newer Liquid Retina LCD screens.

These are all 60Hz screens, of course, but it seems that the older Retina displays use much less processing on the internal panel compared to the later devices. My guess is that those internal panels are 8-bit and the new Liquid Retina, 14”/16” MiniLED, and Studio Display Macs are 8-bit+FRC. And if the former are 8-bit+FRC, they don’t seem quite as aggressive as the MiniLED or MBA Macs.

I don’t really have an explanation for that. I’d expect a display marketed as showing "millions of colors" to be 6-bit with FRC, and those listed as "billions of colors" to be 8-bit with FRC or 10-bit native. It does seem backwards that a 6-bit panel could feel more temporally stable than an 8-bit one. Interesting!

asus389

Blooey I think some of the “millions” of colors displays on some models are/have been true 8 bit. But I don’t have the receipts to prove it.

There are quite a few true 8 bit panels (no FRC) out there, whereas true 10 bit seems a lot more rare.

The question we’ve been pondering for a while is what Mac OS does on a “true 8 bit display”, does it try to make it 10 bit by dithering at the GPU or does it leave the 8 bit signal alone - sending a stable image with no temporal dithering?

AshX

Blooey By holding 120 Hz, HzHold moves a four-frame pattern from 6 Hz to 30 Hz, placing it inside the low-risk zone where temporal changes are much less noticeable. The higher the native bit depth of the panel, the lower the modulation depth and the less visible the temporal behavior becomes.

Thanks so much for responding! This is very interesting. I’d be interested if @aiaf could lend his perspective. Up to this point, it seems the focus has been on eliminating the amount of frames or dithering entirely rather than boosting the frequency. It reminds me of some videos shared here of users testing the dithering of Intel and Apple Silicon Macs with external high refresh rate monitors and as the refresh rate increased, it seemed to “disappear.”

Blooey Mathematically, one high-precision-to-native dither is cleaner than truncating to 10-bit and letting the panel’s FRC finish the job, since it avoids a second quantization step. My hunch is that I’d prefer the look and feel of OS-level dithering for that reason.

I’m one of the unique ones here who has an underlying health condition (POTS and dysautonomia) that interacts with flicker. I’ve done tests on Intel and Apple Silicon Macs where I enable/disable GPU dithering and with Apple Silicon dithering, I get tachycardia which is tracked via a pulse oximeter. As soon as it is disabled the tachycardia goes away.

I’ve tried to unofficially track how different sources and frequencies of flicker affect me. Dithering has been difficult to nail down because of how hard it is on Macs to get a truly clean signal. FRC seems to be affecting the eyes more directly whereas GPU dithering affects the nervous system, for me at least. So I wonder what the differentiating factor is.

*I should also clarify I’ve only tested the M1 MBA and M1/M2 13” MBPs because the other MacBooks have too many sources of flicker (PWM) that I can’t disable well enough to differentiate.

Blooey It doesn’t touch the image pipeline directly but influences temporal stability by maintaining frequency rather than changing modulation depth. Modulation can occur at several layers, but the refresh cadence itself sits at the foundation, so keeping that steady helps all temporal effects stay consistent.

And as described in PAR1789, frequency is just as important as modulation depth in determining the visual impact of temporal modulation, and to a large extent, higher frequency can compensate for greater modulation depth.

This is very intriguing. I’m also the odd man out here in that I can use an iPhone 13 with no problems. The initial 2021/2022 runs had very stable modulation and a high frequency so this makes perfect sense to me.

Blooey I don’t really have an explanation for that. I’d expect a display marketed as showing "millions of colors" to be 6-bit with FRC, and those listed as "billions of colors" to be 8-bit with FRC or 10-bit native. It does seem backwards that a 6-bit panel could feel more temporally stable than an 8-bit one. Interesting!

I would be horrified if the 13” and 15” MacBook Pros from 2018-2022 were 6-bit+FRC for the premium we pay. I wouldn’t be surprised, though.

asus389 I think some of the “millions” of colors displays on some models are/have been true 8 bit. But I don’t have the receipts to prove it.

There are quite a few true 8 bit panels out there, whereas true 10 bit seems a lot more rare.

Yeah…if Apple was selling $1500+ laptops in the late 2010s/2020s that weren’t at least 8-bit then yikes. I know they were caught using 6-bit+FRC before but that was in 2007/2008.

It does make me wonder if some of the panels are 6-bit+FRC and that’s why they’re so awful…but they would be a supplier issue.

asus389 The question we’ve been pondering for a while is what Mac OS does on a “true 8 bit display”, does it try to make it 10 bit by dithering at the GPU or does it leave the 8 bit signal alone - sending a stable image with no temporal dithering?

To piggy back on asus’ question, a theory I’ve often wondered about is to what degree the TCON of the internal panel plays, if any, in the output to an external display.

We know Intel Macs had limitations driving certain resolutions at certain color bit depths. Apple Silicon doesn’t seem to have that issue, but we have heard several anecdotal reports of older Retina screen Apple Silicon Macs being very usable on external displays but Mac Minis or MiniLED Macs not, even with identical settings.

I’m very intrigued to try this app, if I can borrow a MiniLED MBP. I also wonder if @Blooey you can share your personal setup. I know there is a variance between the different generations of MiniLED MBP’s as far as PWM and KSF vs QD backlighting goes.

Blooey

asus389 The question we’ve been pondering for a while is what Mac OS does on a “true 8 bit display”, does it try to make it 10 bit by dithering at the GPU or does it leave the 8 bit signal alone - sending a stable image with no temporal dithering?

Gotcha. Thanks for the clarification. Unfortunately I'd only be guessing. Yes, I think you’re right that by 2022 a panel is extremely likely to be native 8-bit, not native 6-bit, and also not yet native 10-bit. That probably still holds true today. My hunch is that regardless of what the marketing or tech specs say, it doesn’t necessarily mean that no temporal noise exists somewhere in the chain.

For example, the Pro Display XDR is the only display where Apple explicitly states:
Color: P3 wide color gamut, 10-bit depth for 1.073 billion colors.

And in marketing:
With true 10-bit color, Pro Display XDR can produce more than a billion colors.

That seems to be Apple distinguishing a native 10-bit panel from others that reach the same color depth through different means. But we still couldn’t assert, even with that setup, that no temporal noise exists in the chain.

Blooey

AshX I’m very intrigued to try this app, if I can borrow a MiniLED MBP.

I’d be interested to hear your impressions if you get a chance to try it. Just to clarify, HzHold doesn’t interact with the display pipeline or hardware; it simply keeps macOS refreshing steadily at the system’s maximum available rate.

AshX I also wonder if @Blooey you can share your personal setup.

M1 16-inch MacBook Pro Apple specs.

photon78s

I'm adding a link to Blooey's modern 8bit + FRC and higher testing image. I'm trying to collate a list of testing tools in one place over here.

https://ledstrain.org/d/2686-i-disabled-dithering-on-apple-silicon-introducing-stillcolor-macos-m1m2m3/330

asus389

There are some external displays that advertise very high hz rates (like 300+) in the gaming space. I wonder if that’s why some threads here have pointed out they can be more comfortable. Would that effectively increase the hz rate of the temporal noise beyond the limit of detection for more people vs say a 60hz display?

Blooey

asus389 There are some external displays that advertise very high hz rates (like 300+) in the gaming space. I wonder if that’s why some threads here have pointed out they can be more comfortable. Would that effectively increase the hz rate of the temporal noise beyond the limit of detection for more people vs say a 60hz display?

Exactly. As refresh rate goes up, any frame-based temporal modulation such as pixel inversion, FRC or temporal dithering, and even the motion of scrolling text, moves further into the low-perceptibility range described in IEEE PAR1789. The science is straightforward: higher frequency or lower modulation depth reduces how noticeable those changes are.

Backlight PWM behaves a bit differently. On LCDs it is independent of refresh rate, while on OLEDs the drive pattern can be linked to frame timing. Still, all of these mechanisms fit the same science described in that paper. Each is a form of temporal modulation whose perceptibility falls as frequency rises or depth decreases.

For frame-based effects like FRC, the effective modulation frequency is the refresh rate divided by the pattern length. With a four-frame pattern, 120 Hz yields about 30 Hz, which by my read of the PAR1789 chart moves from the high-risk region into the low-risk region at typical FRC depths. The no-effect (green) region begins around 40 Hz for this modulation depth, which would require a refresh rate of roughly 160 Hz for a four-frame pattern. Even so, 120 Hz is a clear improvement over 24 Hz, where the same pattern repeats around 6 Hz.

HzHold simply applies that principle by keeping macOS refreshing at its maximum available rate, so frame-based effects in particular run faster and average out more smoothly. Looking across all sources of temporal change, I think the 120 Hz MacBook Pro could be the strongest option in Apple’s lineup for keeping those effects least perceptible, provided the display is continuously driven at its highest available rate. On my unit, the backlight PWM measures around 16 kHz at 100 percent modulation depth, which places it well within the "no-effect" region defined in the paper.

It makes perfect sense to pass every display parameter through the lens of that paper, because it provides a consistent, measurable way to understand how temporal changes translate to perceptibility.

AshX

Blooey Backlight PWM behaves a bit differently. On LCDs it is independent of refresh rate, while on OLEDs the drive pattern can be linked to frame timing. Still, all of these mechanisms fit the same science described in that paper. Each is a form of temporal modulation whose perceptibility falls as frequency rises or depth decreases.

This is fascinating. So would a 60Hz LCD with a 105kHz PWM frequency like the 13” LCD MacBook Pro behave differently to a 60Hz base model OLED iPhone with 500Hz PWM or even the MiniLED MacBook Pros with 15KHz PWM? We’d also have to factor in the response time of the displays compared to OLED.

This is all very interesting and relevant. Your posts are exactly what we should be honing in on. I think there are two methodologies or strategies that we can employ:

Eliminate flicker (PWM, dither, pixel inversion, etc) completely through brute force methods like forcing 8-bit and finding DC dimmed screens with minimal flicker

Reduce the impact of flicker through strategies like you have shared here

The former strategy is very taxing and ultimately can be undone by any sort of software update. It’s obviously getting harder as companies rely on temporal flicker methods and PWM to make devices look richer and brighter while extending battery life. So it would be great if HzHold along with Stillcolor/BetterDisplay could be proven to mitigate issues for some users.

Blooey For frame-based effects like FRC, the effective modulation frequency is the refresh rate divided by the pattern length. With a four-frame pattern, 120 Hz yields about 30 Hz, which by my read of the PAR1789 chart moves from the high-risk region into the low-risk region at typical FRC depths. The no-effect (green) region begins around 40 Hz for this modulation depth, which would require a refresh rate of roughly 160 Hz for a four-frame pattern. Even so, 120 Hz is a clear improvement over 24 Hz, where the same pattern repeats around 6 Hz.

This makes sense. I’ve often relied on established epilepsy research and it is generally accepted that 15-30Hz is the “danger zone” for seizures. The 15” M4 MacBook Air triggered one for me on setup, but we can assume based on testing that it was dithering at approximately 15Hz at its 60Hz refresh rate.

Blooey On my unit, the backlight PWM measures around 16 kHz at 100 percent modulation depth, which places it well within the "no-effect" region defined in the paper.

This makes me wonder if the discomfort many feel is the variable refresh rate of Pro Motion rather than the PWM itself. I owned a 14” M1 MacBook Pro running Monterey back in summer/fall 2022 and I remember remarking how it was the most comfortable Mac screen I had ever used. My issues started with a July 2022 COVID infection - prior to this I had no problem tolerating temporal noise or PWM. But I sold that device long before I discovered what was driving my issues (flicker).

I have theorized that my critical fusion flicker threshold has been lowered by long COVID and therefore while not having full-blown epilepsy, I can no longer tolerate devices I used to, other than my iPhone 13 with a very stable modulation PWM. This definitely intrigues me if stabilizing the refresh rate would have a similarly positive effect.

Am I correct in assuming FRC would be applying a similar 30Hz flicker on the MiniLED MBPs at 120Hz? I wonder if there’s a way to tease out how GPU and FRC dither interact.

I’m also curious why you chose to not go the route of Stillcolor and offer HzHold outside of the App Store? I would assume this would be easier for us to test on older OS’s, because to be honest, I think you’re going to find fewer people willing to use it because I don’t know anyone on this forum who wants to update to MacOS Tahoe because of the legibility problems of Liquid Glass, irrespective of whatever additional flicker-based processing Apple may have also introduced. Just food for thought because I don’t think anyone here has had success with the M5 MBP either when checking it out in store.

Blooey

AshX I’m also curious why you chose to not go the route of Stillcolor and offer HzHold outside of the App Store?

I appreciate you asking this. It really connects to how I’ve been trying to approach this whole topic.

The process of publishing an app through the App Store has some real advantages. But the App Store also comes with rules that I actually appreciate. One of those rules, which I fully agree with, is not positioning anything as a medical or comfort product. That is why I try to keep the focus on perception. What we can see, measure, or record is a solid way to talk about these topics, rather than how someone might feel physically. And I think that is to everyone’s advantage. Once health enters the discussion, companies have to go quiet, and it becomes harder to have an open conversation. But there is still a huge amount we can talk about if we keep it centered on perception.

There is plenty to study in areas like PWM, inversion, dithering, and how all of these relate to refresh cadence. That is where HzHold fits in. Even beyond this community, HzHold is meant as a simple general toggle for anyone doing macro filming, or using sensors or instruments that may not have interacted temporally as smoothly as they wanted. It is just a toggle.

I should probably clarify that when I say if a panel uses a four-frame temporal pattern, I really mean if. Apple has not published that level of detail, and until someone measures the signals directly, all we can do is make educated guesses. I do not have any insider information, just what can be observed and compared, particularly when looking at tech specs and marketing.

I think the standards science has not quite caught up with the pace of display technology. Hardware has advanced quickly. From what I have seen, Apple and others have stayed within the boundaries of what is published. What seems to be missing now are modern benchmarks for perception. I am literally referencing a lighting specification to map onto various temporal effects in a display, which shows how far behind the standards are compared with where hardware has gone.

To summarize where I come from on all of this, people often say "Apple does not care," but I really do not believe that. For example, I can see genuine care in how they have handled their transition to OLED. They made decisions that make no sense unless you realize they are working under considerable trade-offs. This might be one of the hottest topics on these sorts of forums, but to me the issue is that perception science has not caught up yet, while display technology has leapt ahead of what I think are missing guidelines. That gap can look like indifference when I do not believe it is. There is also a lot of misinformation about how exactly these displays work, as we all try to make sense of the tech at different paces.

AshX I don’t know anyone on this forum who wants to update to MacOS Tahoe because of the legibility problems of Liquid Glass

For sure, but I have full confidence that if there is a legibility issue, Apple will address it in time. They have always shown attention to those details, even if it takes a few iterations. I don't think any issues are universal. There are people running HzHold on Tahoe.

Maybe I could run a TestFlight build for an older OS at some point. For now, HzHold runs well on Tahoe, and I can easily test it all day myself. Ultimately, everyone will move to Tahoe once they are happy with it, and HzHold will be there when that happens.

AshX Am I correct in assuming FRC would be applying a similar 30Hz flicker on the MiniLED MBPs at 120Hz? I wonder if there’s a way to tease out how GPU and FRC dither interact.

If there is FRC, yes, that is how the math checks out for 120 Hz. I think what you are asking is whether temporal dithering at the display controller would behave differently from an OS-level temporal dither. Or would somehow interact with an OS-level dither. To clarify, a temporal dither is a form of quantization, and a downstream quantization should have no effect on an upstream quantization.

In other words, once a signal is quantized to a native bit depth, it cannot be quantized again in a meaningful way. It is already bit-aligned. For example, if we take a value of 1023 and quantize it to 8 bits temporally, it might look like this:

frame 1: 255
frame 2: 255
frame 3: 255
frame 4: 254

When a further quantization downstream receives those bit-aligned values, it should simply pass them through exactly the same:

frame 1: 255
frame 2: 255
frame 3: 255
frame 4: 254

AshX

Blooey"#p47606 Once health enters the discussion, companies have to go quiet, and it becomes harder to have an open conversation. But there is still a huge amount we can talk about if we keep it centered on perception.

I respectfully disagree. You can have a nuanced conversation as to whether flicker is “safe” or not for different groups. Other documents from the US Department of Energy discuss an interest in studying flicker from LED and fluorescent lighting and how it affects autistic individual, particularly students, for example.

Apple also is no stranger to rolling out Accessibility settings for people with disabilities - after all, the new PWM smoothing setting on iPhone 17s is under Accessibility. There are various other settings for people with visual and auditory disabilities. It’s very easy to incorporate a toggle to disable dithering and TCON FRC because those are entirely software based techniques.

Blooey Even beyond this community, HzHold is meant as a simple general toggle for anyone doing macro filming, or using sensors or instruments that may not have interacted temporally as smoothly as they wanted. It is just a toggle.

I appreciate this perspective and understand it’s not meant to be a health-based program. My suggestion merely is to do what Stillcolor, BetterDisplay, and SwitchResX do by offering it outside of the App Store. If monetization is a concern, the latter two programs require paid licenses.

Blooey Ultimately, everyone will move to Tahoe once they are happy with it, and HzHold will be there when that happens.

Even the dev of Stillcolor has not moved passed Sonoma. Many of us had serious problems with Sequoia. MacRumors is filled with folks without our flicker sensitivities who refuse to upgrade. Tahoe is riddled with bugs.

Obviously, I’m not trying to make more work for you. But the general consensus is that devices and OS’s are getting worse, not better, at Apple.

Blooey That gap can look like indifference when I do not believe it is. There is also a lot of misinformation about how exactly these displays work, as we all try to make sense of the tech at different paces.

I don’t think it’s indifference, but rather profit motive. We are a small minority and frankly a blip on their profits balance sheet. Marketing benchmarks are dictating everything: each iPhone has to be brighter than the last with more vivid colors and a longer battery life in order to justify upgrades. And PWM and dithering are the bedrock techniques for achieving all this. It’s why the further back you go, both in device generation and OS, the more tolerable it seems to be.

I’m sure you’ve read a lot of the analysis on the various subreddits by Top G where he dives into the science and why these issues are worsening over time due to voltage problems and how dithering is even being utilized as an energy conservation method both on the power source level (harmless) and the display level (harmful).

Users here have been hoping for a huge jump in display technology that makes flicker unnecessary, but the opposite seems to be occurring. Hence many users here trying to push for 3rd party plugins and accessibility options to bypass dithering and PWM. OLED iPhones seem to be 10-bit, but dithering is still applied in certain instances, and the lower PWM frequency and worsening modulation negates any benefits.

I think it’s quite odd I can use an iPhone 13 with a 610 PWM frequency with low modulation on iOS 15 with minimal dithering…yet if I upgrade to iOS 26 it’s an unusable nightmare and the iPhone 17 series phones are all operating at 99% modulation at all brightness levels with a lower PWM. The shift to LTPO has been incredibly concerning and regressive from a device comfort standpoint. But when you’re pushing 3,000 nits peak HDR that’s what you’re going to get: unsafe flicker.

Blooey I think what you are asking is whether temporal dithering at the display controller would behave differently from an OS-level temporal dither.

I’m more so trying to tease out how the two interact since in theory it would be redundant to apply dithering at the GPU level and then again at the panel. Symptomatically, all of us can say something else is occurring at the panel level - and we know this after disabling GPU dithering and still having issues. But of course the TCON is essentially a black box and it’s harder to observe dithering at the panel level without a high speed camera.

Appreciate your responses and perspective. I hope HzHold helps some folks.

Blooey

Here’s a slow-motion microscope capture showing how the same pixels behave at 24 Hz and 120 Hz on an M1 MacBook Pro running macOS Tahoe.

⚠️ Contains visible flicker
Watch the video

Safari can add a dark gray overlay to short videos, so it's better to download and watch in QuickTime Player.

Captured through a 250x microscope at 240 fps and played back at 30 fps (1/8 speed).
Left: 24 Hz Right: 120 Hz

You can see how much finer and faster the temporal activity becomes at 120 Hz compared with 24 Hz.

If we assume a four-frame temporal pattern, the effective modulation frequency moves from about 6 Hz (24 / 4) to 30 Hz (120 / 4). According to the IEEE PAR1789, for a modulation depth around 0.4 percent (typical of 8-bit + FRC), the no-effect region begins near 40 Hz.

In other words, holding 120 Hz moves a four-frame pattern from 6 Hz to 30 Hz, out of the high-risk level and into the low-risk level on the PAR1789 chart. At roughly 160 Hz, that same pattern would reach about 40 Hz, where these temporal variations enter the no-effect level and should become visually imperceptible under normal speed viewing.