GitLab

Documentation of -[CAMetalLayer setWantsExtendedDynamicRangeContent:]
reads as follows.

  If any rendering context on the screen has this enabled, all rendered
  content is clamped to the screen’s
  maximumExtendedDynamicRangeColorComponentValue value rather than 1.0.

This indeed does what it says. The exact incantation under the covers
is unknown. I had previously guessed that setting IOSurface's color
space to an HDR color space would do the same trigger, but it does not.

This method privately exists on the CALayer base class.

To ensure that this is triggered appropriately, track whether or not
any IOSurfaces that we are using as CALayer contents are tagged with
an HDR color space. If so, set setWantsExtendedDynamicRangeContent
to YES on the root layer.

Add tests verifying this behavior.

Of note is that if the HDR layer is not promoted to an overlay, then
the buffer that we render it in to will not be appropriately allocated
as HDR-capable, and so the HDR content will end up being clipped.

Bug: 976426
Change-Id: Ib389f1c36d39950ddd06beea5320e5f1890b73a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1863689
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#707119}