diff options
author | 2024-03-06 03:09:35 +0000 | |
---|---|---|
committer | 2025-01-29 09:58:34 -0800 | |
commit | c282e18f85c41011ecdf8313aa141398b1cc0400 (patch) | |
tree | 298386271e1bb96bd09ca215f970bab24fde33c2 /libs/gui/LayerState.cpp | |
parent | f74bfe1f7ffd47ee51c046b73a3ff403b95ec939 (diff) |
Set right dimmingRatio for fp16 input layers without metadata
...since 1.0 == SDR white, we can program these layers by sending
SDR/HDR as the dimmingRatio to map the degamma'd value at HDR/SDR
to the max panel lux.
It's a little counter-intuitive at first glance, because we're sending a
dimming ratio < 1.0 for an HDR layer which looks like we're intending to
dim the layer. But it makes sense just from the math: layer_luminance =
panel_luminance * srgb_EOTF(layer_input) * (SDR_white / panel_luminance) =
srgb_EOTF(layer_input) * SDR_white. For an entirely SDR layer, then the
layer luminance is capped by SDR_white as desired, and for a layer that
was rendered with an HDR/SDR ratio then the layer luminance cancels out
to HDR_white == panel_luminance. And, we *are* dimming the layer: since
for a full range layer 1.0 before this infrastructure was in place would
have mapped to the max panel luminance.
Now, the HDR/SDR ratio may have differed by the time we hit the panel
(the layer is slightly in the past), but assuming the ratio changed slowly:
* If HDR/SDR increased, then we dim the layer a bit more than the
application intended, but the user does not notice because the SDR
white point stayed the same; the application just used less headroom
than it could have.
* If HDR/SDR decreased, then we dim the layer less than the application
intended, but the panel can just clip
Bug: 236745178
Flag: com.android.graphics.surfaceflinger.flags.fp16_client_target
Test: builds
Test: courage
Change-Id: I85a0d978f994d495e34dfbdd9dc7b03bd64f293c
Diffstat (limited to 'libs/gui/LayerState.cpp')
0 files changed, 0 insertions, 0 deletions