Previously we hardcode wide color gamut in HWUI as scRGB color space with FP16
pixel format. However, the hardware composer doesn't support this combination.
This patch plumbs wide color gamut composition preference from composer API to
HWUI such that HWUI can now pick the combination of color space and pixel
format for the surface.
BUG: 111436479
Test: Build, flash and boot, verify with a demo app.
Change-Id: I7a8b4d8deca72ef40069dba9d23a3f5e90dbfe5a
This reverts commit dd08224e4d.
Bug: 120097554
Bug: 120342364
Bug: 120421537
Test: verified emulator can boot OK, with no log warnings
Test: verified keyboard works in landscape
Change-Id: Iae2cd1140d81755b126adfb21ec885181f3bc6b6
You won't believe this one weird trick to make
EGL_BAD_ALLOC errors never happen again! libgui
hates it!
Bug: way too many to list
Test: none - there probably should be, though
Change-Id: I8e7fc3e584f90c01e0fd932497604a1d93710ba6
Reason for partially revert: Step back a little bit to think about how we want
to move the view system forward.
This patch removes the legacy mode we have added, as well as move color type
and color space of the surface to SkiaPipeline.
BUG: 111436479
BUG: 113530681
Test: Build, flash, boot and check dumpsys SurfaceFlinger
Change-Id: I1ab7b88d41347284d87649618e5a15f5c6bcf8fe
Remove the need for both Vulkan and EGL managers to initialize
it. Also remove unused code paths.
Test: hwui_unit_tests
Change-Id: I33ad881468eddbf91ec63207f0d82bed8d97f5ad
Need to disable this for SurfaceTexture users specifically
but the quickest is to just disable it globally
Bug: 115311435
Test: builds
Change-Id: I75daddf993c784238593db3d40126af0e9d0ffdc
Previously, HWUI always produces SRGB buffers. We introduced new APIs for
SurfaceFlinger, a.k.a. the composer service to return to composition preference
for data space, and pixel format. This patch makes HWUI query composition
preference from composer service, and creates the corresponding EGL surface
with the correct attributes.
In legacy mode, HWUI will take the pixel value from source color space, and
interpret it as pixel value in destination color space.
BUG: 111436479
BUG: 113530681
Test: Build, flash, boot and check dumpsys SurfaceFlinger
Change-Id: I64562d5ea6f653076c8b448feb56b5e0624bc81c
Fix an issue with incorrect texture matrix, when there is 90/270 rotation.
This happened, because after refactoring SkImage has buffer width/height,
instead of layer width/height.
This reverts commit a683eb3945.
Bug: 113673613
Test: Ran TextureView CTS and lensblur in camera app
Change-Id: If3bcf9cd5195de09fd67a753708568a8e3ca3a9a
Render TextureView as hardware bitmaps, instead of GL textures.
Cache SkImage for each observed GraphicBuffer, which is faster
even for GL.
Implement C++ SurfaceTexture, which allows Java SurfaceTexture
to be used with Vulkan HWUI render thread and application GL.
threads. Delete GLLayer and VkLayer classes and texture code
from old HWUI pipeline.
Test: Ran skiagl and skiavk pipeline with a TextureView app.
Test: TextureView CTS tests pass for GL pipeline.
Test: Ran Android NDK Native codec sample app.
Change-Id: Idc94f864ce2d34fd6ceff4be4fc7d3327e99879c
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
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>
The path renderer bitfield will soon be private (for Skia testing
only), so switch to using the public flag.
Test: Simple refactoring change, still builds
Change-Id: I6715ba8addd0e104a46842f2398320d1904bb187
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
We now have a fix in the driver so we don't need this workaround
any more.
Test: hwuimacro savelayer2 --onscreen
Bug: 31957043
Change-Id: I8d8a4abcfa809d0cdab3bf63d7f8255febf2aa06
To workaround a deadlock caused by bufferqueue locks
we force RenderThread over to use async mode which
we enable via eglSwapInterval(0)
Bug: 38372997
Test: steps in the bug
Change-Id: Ia305f73abbdd64ab0c25d1f7d32792cc6295a0ce
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
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: 27286867
WindowManager has committed to stopped state
controlling the lifecycle of the Surface, so
make that a first-class thing in HWUI as well.
This makes it more resistent to things like
a rogue updateSurface() happening while mStopped=true,
leading to bad things down the line. Instead let
the surface be changed/updated as often as desired,
and just block any attempt to draw on that surface.
Also removes some unnecessary makeCurrent()s, as
EglManager ensures that we *always* have a valid
GL context now (using a pbuffer surface if there is
no window surface set)
Change-Id: Iead78ddebc7997e8fdb0c9534836352f5e54b9bd
Bug: 27286867
If the system/app is slow, it might take too long to
stop drawing. Switch the ordering of destroying stuff so
that we switch to the pbuffer surface first, then do
cleanup
Change-Id: If64a3dbb71bb9fd53567231590436a89b2f1a09e
