Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit e57f9e4d authored by Alec Mouri's avatar Alec Mouri
Browse files

Rework how SF generates gainmapped screenshots

Previously, SF generated an HDR screenshot by:

* Asking CompositionEngine to composite layers offscreen into SDR
* Asking CompositionEngine _again_ to composite layers offscreen into
  HDR
* Asking RenderEngine to build a gainmap
* Sending the SDR buffer and the gainmap to the client

But, this had some problems:
* This path bit-rot, so the HDR layer list was totally empty :)
* LayerFE now has an assumption that only one *thing* will be consuming
  the layer and emitting a release fence back. So, this fixing the above
  caused ghost images, and undoing that assumption just for screenshots
  is a bit unappetizing.
* If the above assumption *were* undone, then the release fence for the
  layer would be delayed due to rendering to an additional render
  target, which sucks.
* We talk to RenderEngine three times, which involves thread hops, which
  sucks.

So, we solve these problems by:

* Only asking CompositionEngine to composite layers into HDR
* Then, ask RenderEngine _once_ to tonemap the HDR buffer into SDR, and
  generate a gainmap.
* Send the SDR buffer and the gainmap to the client.

And now most things are solved: LayerFE is only used to render to one
render target, so it only gets one release fence back, as expected.
Moreover, compositing into HDR is expected to be very cheap, as the
local tonemapper only has to run when tonemapping from a very large HDR
range (like a PQ video) -- when the application is already adapting to
display conditions then we don't have to do anything. And, we only have
to talk to RenderEngine twice now.

We could optimize this further by moving the gainmap generation into
CompositionEngine, but that seems like adding complexity for the moment.

Note that in theory, screenshot quality for the SDR rendition could be a
little worse, since MouriMap introduces shadowing artifacts that may now
bleed across layers. But it doesn't seem to be noticeable in practice,
and it was a pre-existing issue for application-tonemapped content.

Also, we remove CaptureArgs::attachGainmap, since we don't need it at
all to safely trigger this path.

Bug: 329465218
Flag: com.android.graphics.surfaceflinger.flags.true_hdr_screenshots
Test: Trigger screencapture
Change-Id: I5a274886acb135b21096300a034aadca20eceeb5
parent 17e8bc7f
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment