[Wowfunhappy]

> I wonder why anyone would turn ProMotion off considering that 120Hz massively improves responsiveness.

The first reason that comes to mind is battery life. That's probably the most broadly applicable use case.

But also, if I was still doing e.g. frontend web development, I would want to confirm that my css animations looked nice at 60 hz.

Edit: My first use case is likely wrong, thank you to replies for reminding me Apple uses adaptive refresh down to 1 hz.

[jwells89]

macOS is very good at adaptively reducing refresh rate when nothing is happening on screen, with the panel reportedly supporting the full range of 1-120hz so barring badly engineered apps that are permanently pinned at max refresh, the battery impact of keeping ProMotion on is minimal for most use cases.

[londons_explore]

Which raises the question even more why the refresh rate matters during early bootup - surely you could just start with an apple logo and a 1 Hz refresh rate, and then up the rate later during boot when it's time to do some animation...

[lxgr]

Changing the refresh rate makes the screen go blank for a second or so.

GP of this thread links to a post arguing that Apple is going out of their way to avoid just that during the boot sequence.

[londons_explore]

Except it doesn't... because during use the dynamic refresh rate changes between 1Hz and 120Hz...

[lxgr]

Well, I can only tell you what happens when you manually change the resolution from 60 Hz to "ProMotion" in macOS.

Presumably ProMotion is a specific mode that the display/display controller/... first needs to be set to. If you start out in anything other than that and then switch to it later in the boot process, you'd get that blank screen for a second, and Apple avoids that by writing the startup mode to non-volatile memory.

Otherwise they could also just always start out in ProMotion mode – but then you'd get flicker every time you (re)boot into any other mode, like 60 Hz for people who prefer that.

[Wowfunhappy]

...so this is where I'm confused, and where I think GP is confused. Why is there a separate 60 Hz mode that requires blanking the display? Why not just keep dynamic refresh enabled on the panel, and then lock it to updating 60 times per second (which it can do, since it's dynamic) for people who prefer that for whatever reason? What is the difference?

[bscphil]

If I understand correctly, ProMotion is the feature that allows dynamically changing the refresh rate without screen blanking. So the reason refresh rate matters in early bootup is that if ProMotion is not enabled, you get brief screen blanking. Setting the screen to 1 Hz in early bootup and then changing it to the user setting later would require screen blanking.

[TylerE]

That's not a modeset though, that's just the display working as intended. Basically a VSYNC that runs at a variable clock rather than a fixed refresh.

[lxgr]

Pretty sure VRR is a mode as far as the display (controller) is concerned.

There’s very likely still a scan out rate determined by the maximum refresh rate, just that the source can delay the next frame if it’s not ready yet.

In other words, e.g. 120 Hz and 144 Hz of VRR aren’t the same even when displaying a 60 Hz signal at the moment – the faster signal would have more pauses and a higher signal rate.

[Wowfunhappy]

Oops, thank you, I completely forgot they were doing the adaptive refresh thing!

[vvillena]

Isn't battery life a reason to keep it on? The refresh rate will be down to 24hz most of the time.

[beebeepka]

Why would 60 FPS CSS animations look bad on high refresh displays?

[Wowfunhappy]

Well the CSS transition wouldn't run at 60 fps, it would run at 120 fps, no?

An animation that looks slick at 120 fps might look too fast/slow/complex/whatever on a common 60 hz screen. So if I was still doing this sort of development, I'd prefer to be working on a 60 hz monitor.

[beebeepka]

Aren't CSS animations capped at 60, same as requestAnimationFrame?

I've been advocating (and using) high refresh displays for over two decades and I find your reasoning preposterous. Downgrading to crappy 60 Hz monitor for nothing.

[mmis1000]

I am pretty sure they are synchronized to refresh rate (at least on windows).

I made a small experiment about raf https://codepen.io/mmis1000/pen/qBxqgLr and it always looks uniform regardless I am on a 60, 120, 160 fps screen. (It would blink crazily if you put it in the middle of two screen with different refresh rate, because it can't be in two refresh rate at same time)

Erit: okay, it looks non uniform only in safari. Clap, clap, clap, Apple…

[fulafel]

CSS transitions and animations seem to be declared using expressions that are continuous over time so it would make sense that they are just quantized down to whatever refresh rate the system supports.

[Wowfunhappy]

> Aren't CSS animations capped at 60, same as requestAnimationFrame?

Did some quick Googling to make sure I wasn't just out of the loop on this, as far as I can tell they are not the same: https://github.com/whatwg/html/issues/5025

[beebeepka]

Can you point me to the part confirming your claim? If anything, it's confirming mine that they both are stuck at 60 Hz.

[Wowfunhappy]

The link says:

> As such, on their 120hz devices, requestAnimationFrame is throttled to 60hz, whereas CSS animations run at 120hz.

Please let me know if I am misunderstanding, it has been a few years since I've done this type of work.

[c-hendricks]

I'm not even sure CSS animations can go above 60fps, and am unsure why you'd think it would be faster / slower on a different refresh rate screen: CSS transitions are defined by time, not frames.

[Wowfunhappy]

Sorry, I meant the animation might look too fast, psychologically. The frame rate changes how we perceive movement.