Some of the code in latchBuffer was calling invalidateHwcGeometry,
but that didn't cause the SurfaceFlinger visible region code to
re-evaluate the layer's visibility. Set the recomputeVisibleRegions
"out" parameter instead.
Bug 7235797
Change-Id: If6ba33fbd1a594cd64cc5253aebf752d6ceda1c9
The transparent region hint is computed only from view layout
locations, ignoring post-layout translation. If a SurfaceView is layed
out with no other views above it, but a view is moved above it
post-layout, that view's layout bounds would be subtracted from the
window's transparent region instead of its drawing bounds. Prior to
this change, the view would not be visible (except where its layout
bounds and drawing bounds overlap).
With this change, composition uses visible regions computed without
regard to the transparent regions. However, if all of a layer's
visible region is transparent, it will be removed from the list of
layers to composite. This doesn't fix the root problem of incorrect
transparent regions, and doesn't prevent bad composition in all cases.
But it does avoid it for some existing apps, whiel still allowing the
transparent region hint to save power in the important
fullscreen-video-in-a-SurfaceView case.
Bug: 7179570
Change-Id: I47cf939e12129b167afa344b8b036e8827103ac8
we now try first with EGL_FRAMEBUFFER_TARGET_ANDROID, and
pick the first config we find. Otherwise, we revert to
the old algorithm.
Bug: 7232584
Change-Id: I8d5c5a4ce48420832c2e2828718a8f53325effb0
MemoryHeapBase::getBase() returns MAP_FAILED in case or
OOM, not null which is what SF was checking against.
This addresses one of the issues of bug 7230543.
Bug: 7230543
Change-Id: I763a88f64a2f9ff75eb139cfbaf9a1a9746c5577
This adds a line to the "dumpsys SurfaceFlinger" output that shows
build-time configuration values.
Example:
Build configuration: [sf HAS_CONTEXT_PRIORITY] [libui] \
[libgui USE_FENCE_SYNC]
Bug 7206633
Change-Id: Ibe1856b459d34a4be6ee83a4ebfd2807e6cc68a0
this call is not needed and misleading on HWC 1.1; it can also have
a negative performance impact when multiple displays are used.
Bug: 7124069
Change-Id: I47cd25c9d6e69abcc9333b9ecd5044e8fb1919ec
getDisplayInfo() now returns proper information for
HWC managed displays.
hotplug is sitll not supported; so this is not fully correct
as the information returned will be bogus if the HDMI screen
is not plugged in.
Bug: 7191563
Change-Id: If55d8e829fae0443571548155007f486cdf9bc9f
This change makes updateTexImage default to performing the necessary
synchronization and adds an argument for SurfaceFlinger to disable that
synchronization so that it can be performed lazily.
Change-Id: I7c20923cc786634126fbf7021c9d2541aa77be5d
Bug: 6991805
The Surface createDisplay() call takes a display name for debugging.
This change carries it through SurfaceFlinger and displays it in
the "dumpsys SurfaceFlinger" output.
Bug 7058158
Change-Id: I79f3474a8656ff1beb7b478e0dbf2c5de666118a
we were not calling eglSwapBuffers() on external displays
because they can't use HWC which caused us to think they
didn't have GLES composition.
Change-Id: I6cef4ae40b138412d2e6f2acda33c9d222b03a83
- decouple GL and main display initialization
- ensure that each "supported" display has its own FramebufferSurface
- onScreenAcquired/Released now takes a display
Change-Id: If34a05f3dea40f6c79db77f4dde283a2580daac4
The hints were being set a little too late, so the pre-rotation stuff
wasn't quite working.
Bug 7054997
Change-Id: Id8d5c626db7a76f768ba762a145b315878ee08e6
There are two different translations to apply in the logical
orientation, one before scaling and one after.
So translate, scale, translate then rotate.
Bug: 7139798
Change-Id: I0726991cadb62988390e77503dbbaed54f07bfe3
we now make sure to take the blanked state of a display into
account when we build its list of visible layers, this ensures
that we won't call prepare/set with a non-empty list when the
display is blanked.
Possibly fixes 7075380, 7103553, 7130187, 7016215
Bug: 7075380
Change-Id: I9fdd2e73d1b7621eaeca3d4ac2ae60d9fb1b3631
This adds a trivial workaround for a one-shot boot time crash, plus
an explicit check and abort for a failure condition that currently
presents as a less obvious failure.
Bug: 7145521, 7147557
Change-Id: I548f6a9caa9f0bd5710aaecea0e1c6c7c8f2f281
FramebufferSurface no longer speaks directly to the FB HAL. Now
everything goes through HWComposer (which may or may not be
connected to a hardware composer).
Added display index arg to some query methods.
Change-Id: Id3e157d2d4e3555d33afbb703e518b6e92e2d6d5
This change adds a compile-option to use eglWaitSyncANDROID to ensure that
texturing operations that access the current buffer of a SurfaceTexture do not
occur until the buffer is completely written. It also moves this
synchronization into a new SurfaceTexture method called doGLFenceWait and
changes SurfaceFlinger's Layer class to use that method rather than performing
its own wait on the fence.
Change-Id: I70afa88086ca7ff49a80e3cd03d423767db7cb88
onInitializeDisplays() was posting a transaction with changes
to the display projection. Unfortunately, it only set the
display orientation field and left viewport and frame
uninitialized.
The uninitialized values flowed downstream and found themselves
baked into a bogus DisplayDevice mGlobalTransform. That transform
was then applied to some Rects which were turned into Regions
that were them combined with other Regions.
Under certain situations, the uninitialized data might have
a largish value, resulting in the creation of Regions with
components in excess of the Region max-value limit of 0x7ffffff
(note that this is not INT_MAX). Later when performing a
binary operation using the Region, the Spanner would loop
indefinitely trying to figure out how to stuff a humongous
region inside of a max-value region. Not content to try
just once, the Spanner would continue trying again and
again, pegging the CPU and hanging surface flinger during boot.
Insanity soon followed.
Bug: 7130713
Change-Id: I0016f0c9662185be833474c212a1dd408096ae23
