Bug: 241001465
Test: manual currently, flagged off
Change-Id: I707281b9acaf6ea218f1d9ce888fc7cdbf1cf7c9

This allows the memory for the active buffer to be freed as soon as
possible by purging it from HWC cache as soon as the next buffer is sent
to the layer.

Bug: 258196272
Test: atest OutputLayerUncacheBufferTest
Change-Id: I96c24390de5757ac99b369119e9ba031afb0b042

When an app discards graphic buffers, for example when a MediaCodec
disconnects from a surface, those buffers will be uncached and removed
from HWC buffer slots. The active buffer, however, should still remain
active until the next buffer is queued up.

Bug: 262037933
Bug: 258196272
Test: atest OutputLayerUncacheBufferTest
Test: atest VtsHalGraphicsComposer3_TargetTest
Test: atest VtsHalGraphicsComposerV2_2TargetTest
Change-Id: I7c4eefb17e8bad694d698f9ad6d1d289f4af8d2c

When buffers are discarded by SurfaceFlinger clients, the memory should
be free'd immediately. This includes clearing references to them from
within the implementation of Composer HAL, specifically in cache slots
associated with the layer.

Since there is no HAL API to clear the slot directly, prior to writing
any other buffer to the layer, we set the layer's buffer multiple times
to a placeholder buffer, using each of the slot numbers that need to be
cleared. This replaces the reference to the client-discarded buffer
inside Composer HAL with a reference to the placeholder buffer, causing
the reference count to drop, allowing the buffer memory to be freed.

Bug: 258196272
Test: atest OutputLayerUncacheBufferTest
Change-Id: Id85482e8859490566f0eedbd8d8729c47a7349fb

Stop caching buffers inside SurfaceFlinger and remove the tight coupling
between SurfaceFlinger's ClientCache and the Hardware Composer cache.
This allows a better seperation of responsibility, where buffer cache
management is not split between HwcSlotGenerator and HwcBufferCache, but
is instead solely handled by HwcBufferCache.

Note that FramebufferSurface and VirtualDisplaySurface no longer use
HwcBufferCache, but instead use their own cache slot management that
is solely based on BufferQueue slot numbers.

Also do minor refactoring in FramebufferSurface to simplify code.

Bug: 258196272
Test: started and stopped multiple YouTube videos on adt4 and verified
no change in graphic buffer usage
Test: atest HwcBufferCacheTest
Test: atest OutputPrepareTest

Change-Id: Ica7955ab4bc70e3c70207390e36dff73a2fc4949

Replace Layer::prepareClientCompositionList with
Layer::prepareClientComposition now that at most one layer is returned
for any call. Also changes OutputLayer::getOverrideCompositionList to
return an optional for the same reason.

Output::generateClientCompositionRequest is updated to use buffer ids
instead of strong pointers to buffers when determining whether or not
override settings are redundant. This is done to avoid duplicate checks
on whether or not overrideInfo has a non-null buffer.

Change-Id: I777f6ba8c3ca38ea31773e6fcbacb65fad287b03
Bug: b/188891810
Test: atest libcompositionengine_test

Layers with SOLID_COLOR compostion type may cause fence leaks, and since these layers are not frequently used, skipping them should be ok.
Bug: 230073351
Test: manual, examine logs

Change-Id: I50c2488c4c5b891bf0415f1d4bd29a6e0c49be5b

This reverts commit e30a5850.

Reason for revert: b/230389971

Change-Id: I25e5f8ae18d370340ee218ea5d4ad80783e21fa6

Introduce a debug sysprop, defaulted to false, to allow for rewriting
the transfer function to sRGB when set to true.

This is due to several considerations:

1. SurfaceFlinger has not color managed SMPTE 170M properly ever since
   color management was introduced in Android O, and was only fixed in
   Android 13. This means that some camera -> encoding -> storage ->
   playback flows may be incorrectly calibrated on some devices since
   SMPTE 170M was reinterpreted as sRGB for a long time.
2. BT. 1886 recommends a reference EOTF of gamma 2.4 with tuneable
   parameters to approximate a CRT on a non-CRT display. Because the
   framework doesn't support BT. 1886 and it's too late to add support,
   casting as sRGB is probably okay for now and matches old behavior.
3. Typical Rec. 709 content is graded assuming a dim surround, but phone
   displays are used in a wide range of viewing environments, which
   means that viewing Rec. 709 content in a bright environment may
   appear to have lower contrast. Decoding as sRGB will push the dark
   codes into lower luminance levels, which will improve contrast in
   those scenarios. Note that it's better to adjust contrast based on
   the ambient viewing environment, but again it's too late for Android
   13 to improve the color pipeline in the GPU.

Bug: 229442032
Test: Photos playback after recording a video
Change-Id: I64fc8f2ea77f8e595333de36fb9da2979d8316ca

Source frame and bufferCrop calculations use the
primaryDisplayRotationFlags using the projection space
orientation just for the source crop calculation causes the
unwanted source crop in a situation where bufferCrop and
source frame are in different coordinate system. Using the
same primaryDisplayRotationFlags in Source crop calculation
will make all these calculations in line.

Test: verified manually with provided test apk in the #comment1 on
foldable, tablet and a phone and verified go/wm-smoke
atest libsurfaceflinger_unittest
atest libcompositionengine_test
atest CompositionTest
atest OutputLayerTest

BUG: 204187592
Change-Id: I23c6dcfb39979fd67eb5e1d21c011476c630058b

- Disable dimming for screenshot layer

Bug: 224860402
Test: check HDR vidoes when rotation, atest libcompositionengine_test
Change-Id: Ib07a5af1d4e3e91737b3d5f3e5869c166759563f
Merged-In: Ib07a5af1d4e3e91737b3d5f3e5869c166759563f

- Disable dimming for screenshot layer

Bug: 224860402
Test: check HDR vidoes when rotation, atest libcompositionengine_test
Change-Id: Ib07a5af1d4e3e91737b3d5f3e5869c166759563f

Caching does not perform any dimming operations, which means forcing
cached layers to not dim in composer is not correct. So...dim the cached
layers as if they were SDR layers

Note that because caching does not perform any dimming, then this does
imply that some cached sets may permanently be in GPU composition if the
dimming ratio is large enough that the DPU cannot dim + dither.

If we wanted to resolve the power cost of steady-state dimming by a
large ratio, then a future patch would have to teach caching how to dim.
That approach would have a few potential difficulties:
1. Modulating the dimming ratio of cached SDR layers may cause cache
   evictions when an HDR video comes on screen, since caching will have
   to recomposite those layers due to the change in dimming ratio, which
   can be a power regression.
2. Reusing caching results that take into account dimming may be
   difficult, since dimming can cause crush at lower grey levels, so
   brightening a dimmed cached set may cause degradation in image
   quality.

(1) and (2) aren't impossible to solve, but would either require changes
to the composer interface to communicate a dimming ratio capability,
and/or would introduce complexity into caching to selecttively dim
cached results based on composer capabilities as well as what is
expected to be more efficient. Whereas this patch is pretty
straightforward.

Bug: 217794675
Test: HDR test video
Change-Id: I618a0616f49c6ae3feac5bedbb4f5b0e283f5da7

* Send the dimming ratio over to composer as the HWC api is changing to
  not expose the notion of nits to composer, as the white point nits are
  part of logical SF state that does not map as nicely to display
  hardware
* Fixes an issue where scheduling a recomposite for a frame when
  brightness changes is contingent on the presence of HDR layers, which
  is not valid when an HDR layer exits the scene, but DisplayManager
  animates the display brightness down to the SDR white point.

Bug: 217961164
Test: builds, boots
Test: HDR test videos on youtube
Change-Id: Icc07b00f60859bbd3ee078cd2bb793eda42e7781

Devices that have support for DISPLAY_DECORATION layers may also have
support for a blockingRegion, which will allow the DPU to skip regions
that are known to be transparent, in order to save power.

Use the transparentRegionHint to compute the blockingRegion. It may not
be accurate for all layers, which is why it is only used for
DISPLAY_DECORATION layers.

Add tests.

Bug: 212736475
Test: libcompositionengine_test
Change-Id: I6c5d29614dc8d65d8481150ce717a440192083a0

In HWC3 Color is represented as a float [0.0 - 1.0] to be consistent
across the stack. SF passes the color as float and it gets translated
back to uint8_t for HWC2.

Bug: 207139550
Test: atest SurfaceFlinger_test
Change-Id: I83867eed70bd3baa3292c9cc099d891ba9cc6183

Follow on to I2b7b3b4b5630011323a802908c5a80917bdb86ef, which makes it
so we might pass the overrideInfo's visibleRegion instead of the one on
outputDependentState. If the HWC2::Layer call fails, dump the actual
region passed to it, whether it's the original or the override.

Bug: 183456093
Test: make
Change-Id: I5dbb106f7c855d328b5c72a1e4ccacda20bda2c7

The first time this topic landed, it resulted in b/212402133. We avoid
running into this bug with Ib11d46439db57b90486bad07dd90f2cf0822182a.

Original commit message:

After some discussion, we've decided to always set the ScreenDecorations
to DISPLAY_DECORATION. HWC can decide, based on the format, whether to
truly treat it as DISPLAY_DECORATION, or to change to DEVICE
composition.

Previously we were concerned that SurfaceFlinger couldn't use this
information (if we provided it). Looking to the future, it's possible SF
may use this information to help make a better plan for the next frame.

Bug: 193170859
Test: manual

Change-Id: Ib67f55b11a8c5de8f5763394b00fffee43557ed8

Revert submission 16511727-wm_DISPLAY_DECORATION

Reason for revert: b/211835607
Reverted Changes:
I1da3199ba:Allow changing composition from DISPLAY_DECORATION...
I1fae74b36:Update documentation for DISPLAY_DECORATION
I1da03a88f:Add eLayerIsDisplayDecoration flag
I7f22dfd03:Add/plumb SurfaceControl.DISPLAY_DECORATION

Change-Id: Ifa4d06453b5707626c614aad203c727681e23fed
(cherry picked from commit c3e9a90b)
Merged-In:Ifa4d06453b5707626c614aad203c727681e23fed

Revert submission 16511727-wm_DISPLAY_DECORATION

Reason for revert: b/211835607
Reverted Changes:
I1da3199ba:Allow changing composition from DISPLAY_DECORATION...
I1fae74b36:Update documentation for DISPLAY_DECORATION
I1da03a88f:Add eLayerIsDisplayDecoration flag
I7f22dfd03:Add/plumb SurfaceControl.DISPLAY_DECORATION

Change-Id: Ifa4d06453b5707626c614aad203c727681e23fed

After some discussion, we've decided to always set the ScreenDecorations
to DISPLAY_DECORATION. HWC can decide, based on the format, whether to
truly treat it as DISPLAY_DECORATION, or to change to DEVICE
composition.

Previously we were concerned that SurfaceFlinger couldn't use this
information (if we provided it). Looking to the future, it's possible SF
may use this information to help make a better plan for the next frame.

Bug: 193170859
Test: manual
Change-Id: I1da3199bacf5877e88876249c60c0a33fcd44c1e

I90543850d57323be485a0fa8562f4e965aed28ab in hardware/interfaces
introduces the new Composition type, DISPLAY_DECORATION. Handle this
case when looking at Composition.

Bug: 193170859
Test: TODO
Change-Id: Ic5d5881dbbbaa348bf5ba39c5f8a4fca7b7170b4

In preparation for adding a new Composition type which is only in AIDL.
This change is almost completely mechanical, and should have no impact
on behavior.

Bug: 193170859
Test: existing tests

Change-Id: I1f923fcc8d8e6dff388493a76e31d435638b5255

Model here is:
* HDR luminance is set to the current display brightness
* SDR luminance is set to the current SDR white point reported by
DisplayManager

Ideally we use scene-referred white points instead, so:
* PQ is always 10k nits
* HLG is always 1k nits
* Everything else is 150-200 nits

So relative dimming thresholds are fixed. But right now this is visually
less jarring (otherwise youtube UI will suddenly dim when autoplaying
HDR video).

Bug: 200310158
Test: Verified that plumbing sdr white point is sent to renderengine
Test: librenderengine_test
Test: libcompositionengine_test
Test: DataspaceUtils_test

Change-Id: I5bcea7941935c43e57cd5434e1ec69b41d31f2b4

This reverts commit d486bdf9.

Reason for revert: Crash should be resolved with Ia896419eb699903453f6f69e4b6c3527e62ec270

Change-Id: I0e36dc8093e8e4dcc45ca2ff0f3623114d541bf9

This reverts commit 028676ae.

Reason for revert: Droidfood blocking bug: 209930535

Change-Id: I9e8b4d3c4f61a080d85401aa4a503a7436930a3b
(cherry picked from commit d486bdf9)
Merged-In:I9e8b4d3c4f61a080d85401aa4a503a7436930a3b

This reverts commit 028676ae.

Reason for revert: Droidfood blocking bug: 209930535

Change-Id: I9e8b4d3c4f61a080d85401aa4a503a7436930a3b

This is for letterboxed holepunch: a typical layer stack would be:
1. A solid color letterbox in back
2. A solid color layer for SurfaceView's background protection
3. A game's SurfaceView which has rounded corners

One of the constraints for creating a CachedSet is that it cannot begin
with a solid color layer, under the assumption that if there is an idle
layer on top of a solid color layer, then those two layers should not be
merged into a cached set since displaying the color layer separately is
already cheap. But, for the example layer stack above, this means that
there cannot be a candidate cached set behind the game's SurfaceView,
meaning that there is no hole punch generated, so the game is always in
client composition.

So, let's remove the constraint that a CachedSet cannot start with a solid
color layer for hole punches, which resolves the issue.

Bug: 208780233
Test: Hill Climb Racing with letterboxed rounded corners
Test: libcompositionengine_test
Change-Id: Ia5bcdec363f4401b9b9738c5f6ce335497d6362b

Shrinks the area of the overridebuffer sampled by the dpu to the
boundaries of the layer(s) flattened in that buffer.

Bug: b/192058025

Test: composition unit tests, confirm dpu bandwidth is reduced,
confirm secondary displays are still working.

Change-Id: I46d0401d3a08a9c9019f4e1fef1b301e91e6d241

Bug:186475872
Test: atest ProjectionSpaceTest

Change-Id: Ib633044f637d491a7aca3fdf5f780cbde0ead5b4

Bug: 185799825
Test: manual
Test: libcompositionengine_test

Some HWCs crop to the displayFrame. A shadow layer uses its
geometry.boundaries (possibly cropped by geometry.cropRect) as the
size of the object casting a shadow, so the shadow may not be contained
by the displayFrame. For a shadow, expand the displayFrame out by the
shadowRadius to prevent cropping of the shadow.

Change-Id: I8b6c7953d05718a89bdbc59d57775e52195a8131

Consider a set of five cached layers. Because ComposerResources' caches
are scoped per-layer and does not globally track buffers, the override
buffer for each layer needs to be re-imported, and a previous override
buffer needs to be freed, if the new override buffer changed between
frames. This causes a lot of churn in validate(), up to double CPU time
in the hot path.

Instead, we shouldn't override the buffer if a layer would be skipped.
In the aforementioned example, this would cause 1 buffers-worth of chrun
when importing, rather than 5.

Bug: 190654391
Test: Perfetto trace
Change-Id: I907b0c4c340fd99a0023429a8ad740ecc9208815

Inconsistencies in composer state was arising from a layer exiting layer
caching. Resolve this by:

* If a layer previously had an override buffer, but now does not for the
current frame, set the surface damage region to be the entire buffer.
* If a layer is currently being skipped, then don't update the
composition type, since the validated composition type is no longer
accurate for representing the current composition type of the device.
* If a layer was previously skipped, then update in HWC the new
composition type every time.

The inconsistencies have arised from the layer caching feature
because composer implementations cache the most recent requested
composition type for each layer, but SurfaceFlinger caches the most
recent {requested, validated} type for each layer, whichever
SurfaceFlinger sees last. So if we forced client composition, then
untoggled client composition, and if hwc was device compositing the
layer during validate instead of client compositing because hwc ignored
the layer, then SF caches DEVICE composition, but hwc caches CLIENT
composition internally. SF then doesn't update the layer's composition
type because it cached DEVICE composition, but hwc never displays the
layer because hwc cached CLIENT composition, and typical hwc
implementations never attempt to read from client composited layers.

Bug: 187193705
Test: libcompositionengine_test
Test: enable layer caching and repeatedly enable and disable client
composition when pip is playing

Change-Id: I9b6890bcf3f0612e8f99f5f1642015e53d59f862

By using a special caching slot, this avoids import/freeBuffer churn in
the composer process which can occur when a layer is no longer using an
override buffer. Previously the layer's buffer would have been cached by
a previous setBuffer call, but since the override buffer was clobbering
a caching slot, replacing the override buffer requires re-importing the
buffer.

To resolve this, increase the size of the hwc buffer cache so it's ever
so slightly less tied to buffer queue sizes, which allows for room for
the override buffer which improves caching hit rate. On devices that
don't have layer caching turned on, this is a functional no-op because
those devices will never use the additional caching slot.

Bug: 185570241
Test: libcompositionengine_test
Test: Perfetto trace of opening and closing calculator app shows fewer
import/free buffers in the composer process

Change-Id: I219b1a1f6a31c5405736cb06d4921f300fe4a3ee

Source crop needs to match the buffer dimensions, rather than the
display frame dimensions. Otherwise this causes an error in HWC.

Bug: 185398025
Test: wallpaper picker no longer flickers

Change-Id: Iedf04ed7432b34b1dad9358fd32f293cbe8fe522

Bug: 184729207
Bug: 163076219
Test: TODO

In Id721cd451209ab50e5cd8badf5f3e0917506e728, we started updating
geometry if we had an override buffer, or if the last frame did. Also do
so for a peekThroughLayer, since its blend mode changes. In addition,
the z has changed for layers starting with the peekThroughLayer, so
update geometry for those, too.

Move isPeekingThrough to a local variable and parameter. It does not
need the lifetime of overrideInfo. Add it and zIsOverridden to
writeStateToHWC to ensure we restore the order in HWC when the
peekThroughLayer is no longer needed.

Change-Id: I4b2dda504dc52ec06795a2d2b6236b0472702880

Bug: 163076219
Test: manual
Test: I53fc851eca876d44ba7cb9347f1c62d659c38932

In Layer::preparePerFrameCompositionState, no longer set
forceClientComposition to true based on the presence of rounded corners.
This will be determined later, based on whether the Layer will peek
through a Layer with a hole-punch.

In CachedSet::requiresHolePunch, return false if the layer must be
client composited for reasons other than rounded corners (which no
longer force client composition). While we could still use a hole punch,
it would not provide the desired effect (preventing waking up the GPU).

Add an extra field to overrideInfo, denoting whether this layer will
peek through another layer. Set it on a peekThroughLayer before sending
it to the HWC. If it's not set, and the layer has rounded corners, the
layer must be client composited, as before.

Change-Id: I3b4341d049c0fa5020dfd89ca9e765588a457eb1

Bug: 163076219
Test: manual
Test: I53fc851eca876d44ba7cb9347f1c62d659c38932

Remove OutputLayerCompositionState.z, LayerStateField::ZOrder, and
LayerState::mZOrder. Note that the layers are already stored in the
proper z-order (back to front). When sending them to HWC, specify order
with a local variable. The LayerState and -Field ZOrders were used to
treat layers with different z's as a differing field for comparison. But
in practice, a change in z order will change the geometry, resulting in
recreating all CachedSets. (Add a test to verify this changes the
NonBufferHash.)

Add peekThroughLayer to overrideInfo, which is used by Output to
reorder the layers and to change the blendMode so the peekThroughLayer
can be seen through it.

In Flattener::mergeWithCachedSets, update overrideInfo to include
peekThroughLayer, using a new accessor on CachedSet.

Add more info to CachedSet::dump().

Test updates:
- Remove tests that verify the state of OutputLayerCompositionState.z
and ZOrder.
- In LayerStackTest#getApproximateMatch_doesNotMatchManyDifferences, we
were setting kMaxDifferingFields + 1 fields to be different. Removing z
made these two stacks match, so replace with another (arbitrary) field.
- Fix OutputLayer tests to expect calling the new method
LayerFE::hasRoundedCorners

Latest patch set fixes a rebase error in includesOverrideInfoIfPresent.

Change-Id: I845a0f7016c57652045f6f5a082175304272347f

Revert submission 14199598-revert-14086921-renderengine-external-tex-QJNBWQMQEU

Reason for revert: Prepare for relanding
Reverted Changes:
I01e65a7f4:Revert "Update WaylandRenderSurface to accomodate ...
I7d58118c1:Revert "Update Readback VTS to align with RenderEn...
I1501890f4:Revert "Add ExternalTexture class into RenderEngin...

Added the following fixes:
1. CachedSet renders to intermediate texture variable rather than
mTexture directly, since mTexture is not guaranteed to be nonnull.
2. Add null check when setting new buffer in BLAST.

Bug: 185524947
Bug: 180767535
Test: builds, boots
Test: librenderengine_test
Change-Id: I52ea82e24336b496d996bbe3e445db0affe1abb8

Revert submission 14086921-renderengine-external-tex

Reason for revert: Potential culprit for b/185361988
Reverted Changes:
I7796764e2:Update WaylandRenderSurface to accomodate interfac...
I13904eec4:Update Readback VTS to align with RenderEngine int...
I222c71e6e:Add ExternalTexture class into RenderEngine interf...

Change-Id: I1501890f4861a3df7ce273f1fe2ccdb275e2632c
(cherry picked from commit 617752fa)