[galad87]

That's a bug in Intel GPUs Drivers. Windows Server can use an optimized display mode when there is only a Core Animation Layer that covers the entire screen. Unfortunately on Intel GPUs color management is not correct if the layer bit depth 8-bit. Every time a subtitles line appears, the Windows Server switches out of the optimized mode, and so the color management corrects itself, and when the subtitles line disappears, it goes back to the optimized and buggy mode.

The good news is that Intel GPUs are not used anymore on recent Macs, the bad news is that Intel GPUs drivers will never be fixed.

Probably the enlarged cursor prevents the usage of the optimized Windows Server mode.

[ddtaylor]

> the bad news is that Intel GPUs drivers will never be fixed.

What's the reason for this? Also, does this happen on Linux since I know much of the driver stack for Intel GPUs is open.

[galad87]

Just my guess. But it's been introduced at least 6 years ago, and Apple switched to its own CPU and GPU three years ago, so each passing year there are fewer chances of it getting fixed, and relatively soon macOS will require and Apple GPU.

[brigade]

iPads also desaturate when there's similarly no overlay on top of fullscreen video, so it's not just an Intel bug...

[derefr]

Is that not just "adaptive gamut" or whatever it's called — where a display capable of HDR (like the recent miniLED-driven iPad displays) will still be driven with an SDR signal most of the time to save power (as SDR content has a lower contrast ratio, and so is less demanding of peak brightness), but will switch into HDR mode when displaying HDR content (and so "desaturate" — i.e. bring down the black level, lowering the seeming contrast level for darker content — in order to display bright lights as really really white)?

It's maybe strange that compositing HDR + SDR together results in SDR rather than HDR, of course. You might consider that to be the bug.

But I could see that being an intentional choice by Apple (though one that's maybe not thought out in the context of an iPad-as-consumption-device.)

In most situations where you're staring at a composited HDR+SDR signal for a long time — e.g. a video editor editing an HDR video timeline/preview, inside an otherwise-SDR UI — the SDR content exists both before the HDR content is opened, continues to exist after it closes, and takes up the majority of the screen. So you don't want the SDR content changing its gamut just because some HDR content shows up. You want the HDR content to be squashed down to SDR for preview. If you want to check how the video looks in HDR, you'll preview the video fullscreen for a bit. (Or, if you want to always be seeing the video in HDR, then you'll use a dedicated second display that the video is always fullscreen on — as any color-grading software expects you to do.)

The scrubber widget being composited on top of HDR content is an exception to this, of course. That widget should be brought into HDR, not the other way around. But maybe this is a very low-level compositor thing, that's hard for something all the way up at the app level to signal down to to say "hey, don't mind me, we're watching a fullscreen video up here, just make me HDR!"

[galad87]

That could be a totally unrelated bug, iOS is still running many different software pieces. On macOS I saw no issue on Nvidia, AMD, and Apple GPUs.