This reverts commit a4dfaaa4.

pjgowtham authored 5 months ago and Simão Gomes Viana committed 2 months ago

Change-Id: I367b2c395aeb8cb7cb9e3cc38eca98477befe007
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

Pierre-Hugues Husson authored 4 years ago and Simão Gomes Viana committed 2 months ago

 * Supports changed z Udfps order
 * Supports changed Udfps usage bits

TheScarastic: Adapt to extension lib and support 12 BiometricPrompt
ArianK16a: Adapt layer name to UdfpsControllerOverlay for Android 13
    and only compare the prefix. Drop the BufferQueueLayer change
    because it seems unnecessary.

Co-authored-by: TheScarastic <warabhishek@gmail.com>
Change-Id: Id95aa73e06b4223a6b4f05c69fa2fc494f9a97b1
Signed-off-by: Simão Gomes Viana <devel@superboring.dev>

X-axis activity transitions require the translation of the surfaces
involved. As this movement would create unwanted see-through, we would
have added side windows anchored to the moving activities, and textured
them by clamping their parents.

We are replacing the additional windows with the extension of the
surfaces, and filling the area without buffer with a shader.

See go/edge-extension-sksl for more info.

Bug: 322036393
Test: LayerSnapshotTest
Flag: EXEMPT (calls will be protected by wm shell with com.android.window.flags.edge_extension_shader)
Change-Id: I3682efd16a1b311d67a522bb85960f100948b2ea

A container of const T uses std::allocator<const T>, which was an
undocumented libc++ extension that has been removed.

See https://github.com/llvm/llvm-project/pull/96319.

Bug: 349681543
Test: m libcompositionengine
Change-Id: I359350a298fc9a59c0ca925a36f753ac3fb3b64e

Most work from this method can be skipped if the display is not enabled.
However, uncaching buffers should still occur. If the display is
disabled and there are buffers to uncache, still flush pending commands.
They should only contain commands that are meaningful for a disabled
display, like bufferSlotsToClear.

Bug: 330806421
Test: libcompositionengine_test
Flag: flush_buffer_slots_to_uncache
Change-Id: I7baa3e76af86329fb266395e63e92a0ba38967f4
(cherry picked from commit a3ba7fa4)
Merged-In: I7baa3e76af86329fb266395e63e92a0ba38967f4

Most work from this method can be skipped if the display is not enabled.
However, uncaching buffers should still occur. If the display is
disabled and there are buffers to uncache, still flush pending commands.
They should only contain commands that are meaningful for a disabled
display, like bufferSlotsToClear.

Bug: 330806421
Test: libcompositionengine_test
Flag: flush_buffer_slots_to_uncache
Change-Id: I7baa3e76af86329fb266395e63e92a0ba38967f4

These layers, typically screen rotation layers, disable dimming because
the dimming result is baked into the layer (in the case of a screen
rotation, it's a screenshot of potentially-dimmed layers).

But cached layers are always rendered without the constituent layers
being dimmed, with the possibility of the entirety of the rendered
result being dimmed later. This means that layers that disable dimming
canot be cached. Otherwise, you have the following scenario:

1. HDR video is playing on an app like Youtube, with the surrounding UI
   dimmed.
2. Screen rotation starts. A screenshot is captured and replacing the
   screen contents.
3. The screen rotation animation takes a long time, so the screenshot is
   cached with another layer, such as a screen decoration layer. That
   whole cached set is *dimmed*, which means that the UI is doubly-dimmed and
   the HDR video is transiently dimmed, both of which causes a
   user-visible flicker during screen rotation.

There is an alternative approach of cleaning up this concept of
disabling dimming and rendering the screenshot as an extended sRGB
image, similar to HDR UI, but that requires changes to the screenshot
api to commmunicate the dimming ratio as well as changes to the screen
rotation code, and it's easier to fix the bug in caching instead :)

Bug: 325557704
Test: libcompositionengine_test
Test: Rotate the screen a lot during HDR playback
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:f45ad66b536dddf01adef6613680360a5286b87b)
Merged-In: I184e221fa4431e4751002c7304bf89d2fe98fe20
Change-Id: I184e221fa4431e4751002c7304bf89d2fe98fe20

Bug: 334974544
Test: atest libcompositionengine_test PowerAdvisorTest
Change-Id: I3523b8af04a1e9354e8212addf1c826dbe37a35b

These layers, typically screen rotation layers, disable dimming because
the dimming result is baked into the layer (in the case of a screen
rotation, it's a screenshot of potentially-dimmed layers).

But cached layers are always rendered without the constituent layers
being dimmed, with the possibility of the entirety of the rendered
result being dimmed later. This means that layers that disable dimming
canot be cached. Otherwise, you have the following scenario:

1. HDR video is playing on an app like Youtube, with the surrounding UI
   dimmed.
2. Screen rotation starts. A screenshot is captured and replacing the
   screen contents.
3. The screen rotation animation takes a long time, so the screenshot is
   cached with another layer, such as a screen decoration layer. That
   whole cached set is *dimmed*, which means that the UI is doubly-dimmed and
   the HDR video is transiently dimmed, both of which causes a
   user-visible flicker during screen rotation.

There is an alternative approach of cleaning up this concept of
disabling dimming and rendering the screenshot as an extended sRGB
image, similar to HDR UI, but that requires changes to the screenshot
api to commmunicate the dimming ratio as well as changes to the screen
rotation code, and it's easier to fix the bug in caching instead :)

Bug: 325557704
Test: libcompositionengine_test
Test: Rotate the screen a lot during HDR playback
Change-Id: I184e221fa4431e4751002c7304bf89d2fe98fe20

Gated the new GPU implementation behind the adpf_gpu_sf
flag. Changes below are not gated:

Changed to check if RenderEngine is used instead of
client composition as the latter doesn't always
trigger GPU composition (cache). And we should not set
the flag early in chooseCompositionStrategy, since if
HWC fails, it will get reset and still run on GPU.

Fixed PowerAdvisor::setGpuFenceTime code to truely
respect other displays' delay on start time

Bug: 284324521
Test: atest libcompositionengine_test PowerAdvisorTest
Change-Id: I498401d18d9886cda5c6e82243fe7cdad46e091f

Removed code is never used and drawing borders is done instead
by Window Manager Service. Changes revert ag/16980603 and
ag/17496275.

Bug: b/227656283
Test: presubmit
Test: SurfaceFlinger_test
Change-Id: Ib5c8bf74ad6764d65536dc60cc3c458edde86b3f

Buffers can only be released when a release fence fires.
Instead of tracking and waiting for each layer's Futures to
complete, LayerFE can keep track of its own Future via a
promise of a fence. This cleans up the shared futures that
are currently being tracked and allow us to setup for
eventual goals to reduce the number of screenshot calls to
the main thread.

Tests using a virtual display are modified to use the
mirrorDisplay API with a unique layerstack.

Bug: b/294936197, b/285553970
Test: manual (screenshot, camera, rotation, picture-in-picture)
Test: presubmit
Test: atest CompositionEnginePostCompositionTest
Test: atest SurfaceFlinger_test
Change-Id: I3a0af2cd02d3d010a1ea7c860c5cb0bc20837ec2

refreshStartTime is keeps track of frame refreshes for
stats and can be set from SurfaceFlinger. This makes
subsequent changes in refactoring
SurfaceFlinger#composite cleaner and makes tracking the
metric more consistent between changes.

The refreshStartTime field can be removed entirely from
LayerFE's CompositionResult and removed as an argument
in LayerFE#onPreComposition.

Bug: b/294936197, b/329275965
Test: presubmit
Change-Id: I97988315f8982d05aec4b2684d4f5f1826a0fefa

This reverts commit 7a8dc174.

Reason for revert: b/240653315

Test: YouTube PIP at home screen

Change-Id: I6979d1693356623d46349e9de33610731b420973

Generalize SF::initializeDisplays (called on boot and restart) to:
    - Apply the transaction that clears DisplayState to all displays.
    - Power on all displays.

The first change removes a special case for the primary display, setting
the stage for multi-display boot animation. Each display is assigned its
own LayerStack, and set up with a projection to its active resolution.

The second change fixes a bug where DisplayCapability::BRIGHTNESS was
not detected for secondary displays present during boot. SF queries
capabilities when a display is first powered on, but DM asks SF about
brightness when the display is hotplugged, regardless of power mode.
The general fix (covering external displays) is for DM to defer its
query, but this stopgap covers internal displays.

Revert I3a2eae4efc4a5c6113700a9ca9e9b261e364a878, which let the initial
power mode be std::nullopt. This effectively forced DM's first request
to setPowerMode(<rear display>, OFF), which would otherwise be ignored
because OFF had been the default power mode on DisplayDevice creation.
However, that special case confusingly took the same branch as the OFF
to ON transition, and is no longer needed now that all displays are ON
(from SF's perspective, not just HWC's) until the boot animation ends.

Fixes: 267633741
Fixes: 150889228
Bug: 269510347
Test: Boot unfolded and folded.
Test: Induce system_server crash.
Test: InitializeDisplaysTest.initializesDisplays
Change-Id: I5277a629f39b3b285452aa84d49ff84e3dc957ca

Calculate presentation timing info (i.e. expected- and earliest-
PresentTime) separately for each display, since they are generally not
in sync. This allows SF to present each display at the proper time,
using tools that are already in use for the pacesetter display.

CompositionRefreshArgs:
- Replace earliest- and expected- PresentTime with a map of
  FrameTargets which hold the times.

Output:
- Retrieve appropriate times from the relevant FrameTarget.
- Note: Since HAL virtual displays do not have a FrameTarget, they now
  are provided with the default expected (0) and earliest (nullopt)
  -PresentTimes. This is fine, since these times are irrelevant for
  a virtual display. Previously, they simply used the pacesetter's
  times.
- Trace the expected present time.

Scheduler:
- Compute the expectedPresentTime aka expectedVsyncTime for follower
  displays via the next VSYNC after the pacesetter's
  expectedPresentTime. TODO (b/256196556): The "followers" should
  follow the frontrunner, not the pacesetter.

SurfaceFlinger:
- Populate CompositionRefreshArgs' map of FrameTargets.

For now, continue using the same scheduledFrameTime for all follower
displays. This is only used as a deadline for determining whether to
render a CachedSet. Adjusting it per follower would make us more likely
to render more CachedSets per frame, and we need a more holistic
approach for caching anyway.

Bug: 255601557
Bug: 256196556
Bug: 259132483
Test: perfetto traces
Change-Id: I2c27dc709afd1f33bddbf9c2ca1cd61dd335f66c

So the secure flag of Display object in Display Manager (DM) can
be set correctly. HWC calls the onSync method as a workaround,
to notify SurfaceFlinger (SF) about hdcp changes, SF in turn sends
an event to DM, DM will then fetch and update display info.

Bug: 280818362
Test: manual
Change-Id: I29ce0337865b51c0fc7bf7c2d7fdd4cd6d66ef46

* Make sure we don't dim SDR in renderengine, and instead map HDR to the
  correct relative luminance above 1.0
* Plumb the HDR/SDR ratio into HWC

Bug: 236745178
Test: builds
Change-Id: I325972a01280d287189d38dd6c5bf7f2d4b776bb

Allow outputs to decide if they want to render protected content, not
just if they support it. The current code checks if the Output is secure
when deciding whether to render protected content. By adding a new flag,
it will allow displays to decide if they want to render secure,
protected, or both.

This code doesn't have a way to create displays with only protected and
will still rely on the isSecure flag to ensure backwards compatibility.

Test: presubmit
Fixes: 285553970
Fixes: 300492271
Change-Id: If5e65388825d37f4ddaea5190259a136cfa89264

 - also add trunk flag to guard it

Bug: 305718400
Test: libcompositionengine_test
Change-Id: I071d3c3610ba8516529621a0b9f56298f0439e0c

Make Output::present() return an ftl::Future. When offloading its
HWC call, present will return a future that can be waited upon.

In CompositionEngine::present, store a vector of futures and wait
upon the results before returning. This allow's HWC's present to run in
parallel with other work; in particular, present on other displays.
Waiting here ensures that post-composition work does not start until
present has completed. Future work may defer this even later.

Reuse HwcAsyncWorker to run present on a separate thread. Add a new
variable for determining whether to run validate in parallel, since the
presence of the HwcAsyncWorker could just mean that we are offloading
present.

Read the new DisplayCapability to determine whether a display can be
offloaded to a worker thread. Only run displays in parallel if they all
have the DisplayCapability. Non HWC-enabled displays without the
capability do not prevent other displays from being offloaded. They also
run last, since they can run in parallel with HWC-enabled displays.
(The ordering is now set by SurfaceFlinger, which places physical
displays at the start of the list of outputs.)

When telling a display to offload its present call, make it only last
for a single frame. This simplifies the code while ensuring we do not
leave it enabled unnecessarily.

Leave a single present call on the main thread. This saves a thread-hop,
while still allowing it to run in parallel with other HWC work.

Only attempt to offload present if the appropriate trunk stable flag (or
debug sysprop, "debug.sf.multithreaded_present") is set.

Bug: 241285491
Bug: 259132483
Test: manual: perfetto trace
Test: libcompositionengine_test
Change-Id: Ib9d074671e32c95875ef7e0791dd95d6e595e47a

1. Remove first initiation of dataspace in the constructor of
   RequestedLayerState;
2. snapshot->stretchEffect has been set in the approach of
   prepareBasicGeometryCompositionState(), so remove the second call.

Change-Id: I784223ddce80756dc88ec78e8f0deb042e6389db
Signed-off-by: jiayongqiang <jiayongqiang@xiaomi.com>

BUG: 284845445
Test: Manual
Change-Id: I2d7be3b8e43b2ef93d74bca0cc366a34342210ba

The "post" in "postFramebuffer" can be read as a preposition or a verb,
making the name less easy to understand. Furthermore, "framebuffer" is
typically used in the context of GPU composition, but this function
involves DPU composition.

Rename to "presentFrameAndReleaseLayers" to better describe what it
does. While we're at it, shorten "presentAndGetFrameFences" to simply
"presentFrame".

Splitting out from original motivating discussion in
Ib9d074671e32c95875ef7e0791dd95d6e595e47a.

Bug: 241285491
Bug: 259132483
Test: No new behavior; no new tests
Change-Id: I41df1d0b98c34eaffe44c5c29006356964c555a6

The shadow length is currently tracked in both the LayerFE
CompositionState and the shadow settings, which are used by the
RenderEngine. We can consolidate these fields and track shadow
settings in the LayerFE CompositionState. This makes sense because
we want the LayerFE CompositionState to contain all relevant
information that it can pass to the RenderEngine without calling
back into the frontend.

Bug: 302551905
Test: presubmit

Change-Id: I583c43993cf73784c6fec9ec2d40f2c76d21adeb

This reverts commit bfcc6102.

Reason for revert: b/294998861

Change-Id: Ia626dc3e65914781f178e52ab5d43721f0723167

This reverts commit 56866118.

Reason for revert: b/294998861

Change-Id: I8616665f69be8e827529ed3a76b337606b900dfc

This improves performance by moving allocateHelper to a different
thread, which is launched early so that the allocation is ready when
it is needed. In addition, each display will only need at most one
additional texture per frame, so replace the idea of a minimum pool
with making sure there is either at least one texture in the pool
or a future which will generate one.

Bug: 256184546
Test: atest libcompositionengine_test
Change-Id: Icb92a85c07b9f2911d1365aa9bbc8d0750a8c116
Merged-In: Icb92a85c07b9f2911d1365aa9bbc8d0750a8c116

This is only needed for configuring colorspace agnostic dataspaces, but
no device does that. For colorspace agnostic layers, it's sufficient to
just use the colormode dataspace, with the possible exception of HDR
where we can preserve some bespoke logic, so we can just get rid of
target dataspaces and any associated plumbing.

Bug: 292162273
Test: builds
Test: libsurfaceflinger_unittest
Test: libcompositionengine_test
Change-Id: I319bb354e80e3ad1eaaacd896b897e6696f96588

This improves performance by moving allocateHelper to a different
thread, which is launched early so that the allocation is ready when
it is needed. In addition, each display will only need at most one
additional texture per frame, so replace the idea of a minimum pool
with making sure there is either at least one texture in the pool
or a future which will generate one.

Bug: 256184546
Test: atest libcompositionengine_test
Change-Id: Icb92a85c07b9f2911d1365aa9bbc8d0750a8c116

cache buffer rendering supposes to utilize the cpu gap after current
frame finised and before the next frame. But it could take long and
delay the next frame start time and cause jank eventually.
Sending CPU LOAD UP hint to prevent stealing time from the next frame.

Bug: 285991802
Test: PtsUiBench QHD
Change-Id: Id619a8166ae253fef815a25a35fc4b82066144a9

with null

Fixes a regression introduced in T which ignores a setBuffer call
with a null buffer. The expected behavior should be to release the
currently presented buffer from surfaceflinger. The subsequent frame
will not present this layer so the region behind the layer will be
composited instead.

Bug: 241271897
Test: presubmit
Change-Id: Ie06025c59c58cc75a267b783729996a3cbceef45

When the next expected presentation time is not allocated for
the previous frame, SF needs to wait before submitting it to HWC
to prevent early presentation.

Bug: 273419557
Test: tested by partner
Test: atest ASurfaceControlTest
Change-Id: Ia83755bbc71968369fd9176944b9a85135d8a04a

Bug: 267350616
Test: builds
Change-Id: I75bb485f01ae2358c77133767f01cb63f8eda6f1

- disable caching if hdr/sdr ratio > 1.01f, which we uses the extended
  brightness api.

Bug: 273624686
Test: play HDR video in silkFX and make sure no overdimming obeserved;
atest libcompositionengine_test

Change-Id: Iae53c5928e4f91b4b73f9e4ee9dd7bb052e86090

- separate color and bgcolor in layer state so we don't set a color
 on a layer without a buffer
 - avoid using legacy layer state when latching a buffer
 - fix callback issue where invisible or offscreen layers were not invoking
 the callbacks
 - pass in layer snapshot for trusted presentation state
 - fix a screenshot issue where the root layer was skipped
 - pass in framerate changes to layer history

Test: presubmit
Test: atest SurfaceFlinger_test with new fe
Bug: 238781169

Change-Id: Id9ff8a036dc283e21a05985c1c01ebd070b1df24

Some system layers may need to be excluded from surfaceflinger caching
for a variety of reasons, including power or image quality
considerations. This provides a mechanism for those system layers to
never be cached on the GPU.

Bug: 259311918
Test: libcompositionengine_test
Test: run test app and inspect planner state
Change-Id: I35418ad5a41cb2546e3b27b0af290bf3c31a0180

1. Ignore display overlays since we don't want screen decorations
   included in the occlusion

2. Handle occluded region as separate Rects to ensure that disconnected
   Rects in a Region are not considered occluding in the disconnected
   area.

Test: LayerTrustedPresentationListenerTest
Bug: 256993331
Change-Id: Ib0a4b850e2aafb42e206b8728fcc9b6013171f3f

* Removes redundant logic for determining whether or not SurfaceFlinger should request texture filtering.
* Fixes an issue where ScreenCaptureOutput was using incorrect values for its layer stack projection space.

Bug: 238348307
Test: atest TextureFilteringTest

Change-Id: I4ece87321ee73d10b86a2c01d53717d337c11926