Internal master SHA 1bcacfdcab0eaa0cee92bd7f5a1b5e271dd68e52 reformats
this entire project. To be able to update google-benchmark I need to
make a small change to this file. This is the minimal change that avoids
merge conflicts.
Bug: N/A
Test: builds
Change-Id: If3568a0f59a7c007858435953e127167f5862825
It is valid to advertise EGL_EXT_pixel_format_float, but not have a
the requested EGL config. Instead of aborting, fallback to the default
behavior.
Change-Id: I6c602233b627dc2070364434fece57d3d0aab435
Cc: Romain Guy <romainguy@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
We didn't trace the draw from cache.
Here we add trace for draw into bitmap, which is normally heavy.
fix: 65060698
Bug: 65060698
Test: run test app and get systrace and check
Change-Id: Ia81127c4aa285b3277e9c9edbdf356d85cb28b5e
(cherry picked from commit cf0c41dbc221c2619212c7e25e6d90a9c4d05b05)
This is a test that simulates a standard TV application screen.
The UI elements:
A full screen background bitmap.
Few rows of cards.
Each card has a bitmap and an info area.
Info area has two lines text.
Each card is dimmed, implemented in two modes:
1. adding translucent color RenderNode on top of card
2. applying ColorFilter to bitmap.
Firt card of each row is scaled up and has shadow.
The animations:
Cards are updating translation Y and updating display list
and overlay color alpha or colorfilter.
Test: there are four tests:
tvapp: baseline test, with rounded corner, use Color RenderNode to dim
tvapp_norc: no rounded corner
tvapp_cf: use colorfilter to dim
tvapp_norc_cf: no rounded corner, use colorfilter to dim
Bug: 64990221
Change-Id: I385e349386c41e32b7313180db8c81b8f3e39f88
As graphicsstats can be subjected to data coming
from the disk and is in system_server we want
to bias towards best-effort instead of strict
no-errors that the rest of HWUI typically uses.
So treat any dump/merge of graphics stats as
best effort, ignoring any errors that occur.
Bug: 65652900
Test: verified 'dumpsys graphicsstats' still works
Change-Id: Ia9b91b745c2a9aedad2f22e3087e1d4bf37a1135
Move content bounds into DrawFrameTask. This ensures
that changes in bounds are synchronized with changes in
rendering commands, avoiding potential underdraw.
Bug: 64200212
Test: Repro steps in bug. Drag up/down on resize handle, verify
no flicker.
Change-Id: I3109acf262e23c2a7d8904f1dcbfc8273aaed65b
Bug: 65077146
Test: Manual - uirendering tests don't allow test draw content
to be displayed first.
It's not always valid to disable blending on the first draw to the framebuffer,
since some blend modes affect the framebuffer in different ways. We now only
disable blending if the op is SRC_OVER to be safe.
For example:
canvas.drawColor(0xfeff0000, PorterDuff.Mode.CLEAR);
canvas.drawColor(Color.BLUE, PorterDuff.Mode.DST_OVER);
The BLUE should always be seen - the other draw should just clear the buffer.
Prior to this fix, the above code (put in a window background) would draw black.
In addition, this removes the disable behavior in drawRects(), since that should
never benefit from the optimization - that decoration is always drawn at the end
of a frame.
Change-Id: I34e8d9d62d6e1dfa00e9301f44c277475f2940a8
bug:34809371
In some applications, the first draw is not opaque - either because the
application is misbehaved, or because hwui is not able to reliably tell
whether the layer is opaque or translucent. This is undefined behaviour
in OpenGL ES and has a significant performance and bandwidth impact on
some tiler GPUs as it requires loading the previous frame's color data.
This change disables blending in that case and also for effectively
opaque blend modes (SRC=GL_ONE, DST=GL_ZERO). It increases performance
by ~10% for Leanback CTS on some low-end GPUs (gradient layer that hwui
incorrectly believes to be translucent).
Test: manual - visual inspection on fugu (nexus player)
Change-Id: I2cbf1c76678acae1a36923e72fd18ed55cd89dc2
The main purpose of this CL is reducing font cache size of
low-density device.
The memory usage for the small RGBA texture will be
Nexus 6P: 7,928,856 bytes (1408x1408)
Nexus 5X: 4,734,976 bytes (1088x1088)
These used to be 4,194,304 bytes
Test: manually checked
Bug: 64400885
Change-Id: Ied064a6d59909ad7fbeff74332973206436fbd34
Remove all ro.hwui.* tuning props and instead
calculate them from the screen resolution.
Or just hardcode them to what all devices
were hardcoding them to anyway.
Bug: 63741221
Test: Check cache size results on sailfish
Change-Id: I8b0d210572a246f4fefb076935cf5156a70c274c
Merged-In: I8b0d210572a246f4fefb076935cf5156a70c274c
(cherry picked from commit 8dc02f99d09130ace2ee738c2e689db1b3f33181)
Ensure that RenderNode fitsOnLayer() is true before assigning
it a layer.
Bug: 63814070
Test: repro steps in bug no longer crash
Change-Id: I28bb2cb173a5efde24e2384f2606fea85b394ac8
Since hwui output non-linear scRGB data in wide-gamut, use
the scRGB-nl extension instead of scRGB.
Bug: 62951776
Test: Manual, CtsGraphicsTestCases
Change-Id: Ifdb288e777d12b790b93624ccea9b4f1f6966e52
(cherry picked from commit 26b6a64953f29bbe6b10a5e948d11f47bd0611d6)
This reverts commit 0d253e46aa0b4cb2ea56e220812aeab92de64ae1.
The original CL changed Typeface internal methods and broke
TypefaceCompatApi26Impl in support library which uses reflections.
Ideally, TypefaceCompatApi26Impl must fall back to public API
implementation but due to lack of method availability check, it ended up
crashing the application.
The original patch didn't change any behaviors in MR1, so reverting
that change is the best solution for MR1.
Bug: 64033594
Change-Id: Ie86afeb1b809e57915d62c1db5a70c8d210d2354
Test: N/A
The analyzer assumes that the given `put` operation may fail. This
shouldn't be the case, so mark it with a LOG_ALWAYS_FATAL_IF. Doing so
silences a warning about potential memory leaks originating from
TessellationCache::getRoundRect.
Bug: 27101951
Test: mma. Warning is gone.
Change-Id: I3adeacd6c2c9c03caecd989e2a1267c51e8ef905
Fix drawing of bitmaps with color profiles. This CL is making
ColorSpaceTests and Rgba16fTests CTS tests to pass with Skia
pipeline. Drawing bitmaps withs pixels outside SRGB range
may need more work (ColorSpaceTests#testDrawDisplayP3 test use a
a wider gamut, but the actual pixels fall into the SRGB range).
Test: Ran CtsUiRenderingTestCases with HWUI and Skia pipeline.
Bug: 62347704
Change-Id: I8d318076bb38f7d32bfde7e5492ae7a61f4731a5
