com.android.server.cts.GraphicsStatsValidationTest#testDaveyDrawFrame in
modue CtsIncidentHostTestCases failed
This cts case design 20 frames, every 4 frames include 700ms frame and
150ms frame
When activity launched, first 3 frames need allocate buffer during
dequeue buffer, bug some low-end platform took too long (>6ms), so
it will skip the fourth frame(150ms) and post a new draw callback that will cause cts failed
Bug: 78866720
Test: Manual + systrace; existing CTS
Previously, we set hasAnimations to true when the AnimatedImageDrawable,
so that we would get a call to redraw. But if the image does not need to
show its next frame yet, the redraw was unnecessary.
Instead, add a new field to TreeInfo::Out, representing the delay time
until the image will need to be redrawn - i.e. when the duration of the
current frame has passed. Each call to prepareTree will post at most one
message to redraw, in time for the earliest animated image to be
redrawn. Post the message for one rendered frame ahead of time, so that
when it is time to show the next frame, the image has already gotten the
message to update.
On a screen with a single animated image, this drops the number of calls
to dispatchFrameCallbacks to as infrequent as possible. It is called
only when we need to draw a new frame of the image. On a screen with
multiple animated images, the calls may be redundant, but they will not
be more frequent than they would be without this change.
Switch to nsecs_t and systemTime internally, matching the rest of HWUI.
Remove mDidDraw and related. Its purpose was to prevent advancing the
animation while the image is not being drawn. But it isn't really
necessary. If it's not drawn, onDraw is not called, which is where we
trigger decoding. And onDraw already has a defense against getting too
far ahead - if its timer indicates that it should skip a frame or show
it very briefly, it will back up its timer. More importantly, mDidDraw
caused a bug, when combined with less frequent redraws. If the display
list containing the drawable doesn't need to be redrawn for other
reasons, the drawable's timer never advanced, so its animation stopped.
Fix software drawing. Compute the milliseconds in the future to draw the
next frame, and add that to SystemClock.uptimeMillis() to compute the
time to pass to scheduleSelf.
Change-Id: I13aab49922fa300f73b327be25561d7120c09ec4
For periods of time during which latency is less important
allow a client to request a deeper render-ahead pipeline.
The latency tradeoff results in less overall visual jank
Test: none, only used by macrobench
Change-Id: I516203b70bdc75b6415fa08bf9c4fb1b598b0102
Fix crash caused by updating vectordrawable cache for objects
from previous frames, which may have been deleted.
Bug: 67940327
Test: Ran CtsUiRenderingTestCases test
Change-Id: I4466235e78e9b7937a0d4428240574d9e3d0989f
Layers created using View.setLayerType() or Canvas.saveLayer() need
to be RGBA16F/scRGB-nl when within a window that requested wide color
gamut rendering.
Bug: 29940137
Test: CtsUiRenderingTestCases, CtsGraphicsTestCases, hwui_unit_tests
Change-Id: I42fd6355448c92041491a7109e3ac8a153d38bf9
The core of the implementation is complete and provides heuristic
cache sizing based on the size of the surface being used. This CL
will also be used to add the following features in the future...
1) Support Vulkan pipeline reporting on the size of the surface.
2) Complete the VectorDrawableAtlas stub code
3) Automatic purging of stale resources for low memory devices.
Test: hwui_unit_tests (new test added) and CtsUiRendering
Bug: 62260637
Change-Id: Ib85159cca28b646fe249f2190b07f1b7e0f50d8f
When wide color gamut rendering is requested, hwui will now
use an rgba16f scRGB-nl surface for rendering. This change
also fixes the way screenshots are handled in the platform
to behave properly with wide gamut rendering.
This change does not affect hardware layers. They also
need to use rgba16f scRGB-nl; this will be addressed in
another CL.
Bug: 29940137
Test: CtsUiRenderingTestCases, CtsGraphicsTestCases
Change-Id: I68fd96c451652136c566ec48fb0e97c2a7a257c5
Fixes impossible dequeue crash as the wrong
start point of the frame was used. We need
to use the start point for RT, not the start
point for the frame.
Workaround for sysui ANR caused by what appears
to be a driver bug. Drivers with the bug
will have transiently higher memory usage.
Drivers without the bug will be unaffected.
Bug: 62213889
Bug: 62250550
Test: Manual
Change-Id: I9992b224f84bc1c40834bafff7e0013b38270ae0
* LRU cache of recently-used is dead, replaced
disk storage
* ASHMEM size is read from native by the system service,
no longer requires keeping a sizeof() in sync with a
constant in Java
* Supports dumping in proto format by passing --proto
* Rotates logs on a daily basis
* Keeps a history of the most recent 3 days
Bug: 33705836
Test: Manual. Verified log rotating works by setting it up to
rotate every minute instead of day. Confirmed /data/system/graphicsstats
only has the most recent 3 entries after several minutes
Change-Id: Ib84bafb26c58701cc86f123236de4fff01aaa4aa
* Move mValid to native
* Have destroyHardwareResources destroy everything
* Remove flaky mParentCount checks in setStaging
* All tree updates have an internal observer to
ensure onRemovedFromTree() is a reliable signal
* onRemovedFromTree() immediately releases resources
to avoid displaylist "leaks"
Test: Unit tests for validity added & pass, manually
verified that b/34072929 doesn't repro
Bug: 34072929
Change-Id: I856534b4ed1b7f009fc4b7cd13209b97fa42a71c
Implement Skia pipelines for OpenGL and Vulkan:
base SkiaPipeline, SkiaOpenGLPipeline and SkiaVulkanPipeline.
Write unit tests for SkiaPipeline.
Test: Built and run manually on angler-eng.
Change-Id: Ie02583426cb3547541ad9bf91700602a6163ff58
NOTE: Linear blending is currently disabled in this CL as the
feature is still a work in progress
Android currently performs all blending (any kind of linear math
on colors really) on gamma-encoded colors. Since Android assumes
that the default color space is sRGB, all bitmaps and colors
are encoded with the sRGB Opto-Electronic Conversion Function
(OECF, which can be approximated with a power function). Since
the power curve is not linear, our linear math is incorrect.
The result is that we generate colors that tend to be too dark;
this affects blending but also anti-aliasing, gradients, blurs,
etc.
The solution is to convert gamma-encoded colors back to linear
space before doing any math on them, using the sRGB Electo-Optical
Conversion Function (EOCF). This is achieved in different
ways in different parts of the pipeline:
- Using hardware conversions when sampling from OpenGL textures
or writing into OpenGL frame buffers
- Using software conversion functions, to translate app-supplied
colors to and from sRGB
- Using Skia's color spaces
Any type of processing on colors must roughly ollow these steps:
[sRGB input]->EOCF->[linear data]->[processing]->OECF->[sRGB output]
For the sRGB color space, the conversion functions are defined as
follows:
OECF(linear) :=
linear <= 0.0031308 ? linear * 12.92 : (pow(linear, 1/2.4) * 1.055) - 0.055
EOCF(srgb) :=
srgb <= 0.04045 ? srgb / 12.92 : pow((srgb + 0.055) / 1.055, 2.4)
The EOCF is simply the reciprocal of the OECF.
While it is highly recommended to use the exact sRGB conversion
functions everywhere possible, it is sometimes useful or beneficial
to rely on approximations:
- pow(x,2.2) and pow(x,1/2.2)
- x^2 and sqrt(x)
The latter is particularly useful in fragment shaders (for instance
to apply dithering in sRGB space), especially if the sqrt() can be
replaced with an inversesqrt().
Here is a fairly exhaustive list of modifications implemented
in this CL:
- Set TARGET_ENABLE_LINEAR_BLENDING := false in BoardConfig.mk
to disable linear blending. This is only for GLES 2.0 GPUs
with no hardware sRGB support. This flag is currently assumed
to be false (see note above)
- sRGB writes are disabled when entering a functor (WebView).
This will need to be fixed at some point
- Skia bitmaps are created with the sRGB color space
- Bitmaps using a 565 config are expanded to 888
- Linear blending is disabled when entering a functor
- External textures are not properly sampled (see below)
- Gradients are interpolated in linear space
- Texture-based dithering was replaced with analytical dithering
- Dithering is done in the quantization color space, which is
why we must do EOCF(OECF(color)+dither)
- Text is now gamma corrected differently depending on the luminance
of the source pixel. The asumption is that a bright pixel will be
blended on a dark background and the other way around. The source
alpha is gamma corrected to thicken dark on bright and thin
bright on dark to match the intended design of fonts. This also
matches the behavior of popular design/drawing applications
- Removed the asset atlas. It did not contain anything useful and
could not be sampled in sRGB without a yet-to-be-defined GL
extension
- The last column of color matrices is converted to linear space
because its value are added to linear colors
Missing features:
- Resource qualifier?
- Regeneration of goldeng images for automated tests
- Handle alpha8/grey8 properly
- Disable sRGB write for layers with external textures
Test: Manual testing while work in progress
Bug: 29940137
Change-Id: I6a07b15ab49b554377cd33a36b6d9971a15e9a0b
bug:30895941
Prevents a race where frame work could interleave between frames,
causing SurfaceView position updates to be delivered out of order.
Change-Id: I01e4cc557b69dcf33e877a0e16c0d115ec95e4cc
