This configuration uses 64 bits per pixel. Heach component is stored as a
half precision float value (16 bits). Half floats can be decoded/encoded
using android.util.Half.
RGBA_F16 bitmaps are used to decode wide-gamut images stored in 16 bit
formats (PNG 16 bit for instance). aapt is currently not aware of PNG
16 bits so such files must be placed in raw/ resource directories.
This first pass provides only partial drawing support with hardware
acceleration. RGBA_F16 bitmaps are stored in linear space and need
to be encoded to gamma space with the appropriate OETF to be rendered
properly on Android's current surfaces. They are however suitable for
linear blending. Full rendering support will be provided in a future
CL (BitmapShaders might be a bit tricky to handle properly during
shader generation).
Bug: 32984164
Test: bit CtsGraphicsTestCases:android.graphics.cts.BitmapRGBAF16Test
Change-Id: I328e6b567441a1b9d152a3e7be944a2cf63193bd
CSS Font4 only allows U+0020..U+007E characters for tag string.
Reject outside of this range.
Bug: 33062398
Test: am instrument -w -e class android.graphics.VariationParserTest \
com.android.frameworks.graphicstests/android.test.InstrumentationTestRunner
Change-Id: Ia119151bc67caebfdaacda17aa3ee261a9e5d872
fix:32705240
fix:32683765
fix:32831830
fix:32705244
Test: make offline-sdk-docs and view the HTML file.
Merged-In: I6ae3e5850494f13a241b2e9e4d2c5b95d5199aae
Change-Id: I6ae3e5850494f13a241b2e9e4d2c5b95d5199aae
Introduce a new internal flag MATCH_ANY_USER for genuine uses
of searching through all apps on the device.
Some temporary accommodations for Launchers that reach across
to the work profile until we have a new LauncherApps API to do
that officially.
Bug: 31000380
Test: CTS tests added
Change-Id: I2e43dc49d6c2e11814a8f8d1eb07ef557f31af34
ColorSpace.createRenderer() returns a ColorSpace.Renderer which
can be used to visualize multiple color spaces and colors (each
associated with a specific color space) in the same CIE 1931 xyY
chromaticity diagram. This API was used to generate all the
diagrams shown in the documentation.
Bug: 32984164
Test: ColorSpaceTest in CTS
Change-Id: Ic94d939d5cfd563d826701f5e876b67b47ed56ec
Font variation settings enables developer to specify font axes for
configuring glyph looking. This CL parse Font Variation settings to
make a array of Axis. More work is needed for using parsed axes.
Bug: 33062398
Test: Done by unittests.
Change-Id: I529b98b28df1c738237bee0729d9f479bd656dd3
Some initial cleanup before making changes to either class.
Test: n/a, refactoring only
Bug: 33124798
Change-Id: Idf0328bcc6de72b694ca7b35122ecad845cf1c4b
This class can be used to define color spaces. A color space has a color model
and a profile connection space (CIE XYZ D50). This implementation can be used
to query various properties of RGB color spaces or perform conversions between
various color spaces (RGB, XYZ and Lab).
Refer to the documentation for more details.
Test: cts-tradefed run singleCommand cts-dev --module CtsGraphicsTestCases --test android.graphics.cts.ColorSpaceTest
Bug: 32984164
Change-Id: Ie2117c1212c1375a7d403d3c1afaf73d7c2e0b47
fix:32705240
fix:32683765
fix:32831830
fix:32705244
Test: make offline-sdk-docs and view the HTML file.
Change-Id: I6ae3e5850494f13a241b2e9e4d2c5b95d5199aae
Adds the ability to control word spacing from Java, wiring up the
plumbing to the corresponding change that adds it at the Minikin
level.
Bug: 31707212
Test: ran graphicstests
Change-Id: I568186aca961d51ee5231cb0331f882b7b005e90
update-api orders methods alhabetically by name, but when
there's multiple methods with the same name it falls back to
the ordering within the file.
Re-order the methods in canvas.java to match what's already in
current.txt to avoid unnecessary changes.
Also auto-formatted the draw methods as some were mis-indented.
Test: No behavior change, just method re-ordering
Change-Id: I2a7d313c8e7a6bd9187c4ed7dbde944b88aa32bb
All draw* calls in Canvas are regular JNI
All draw* calls in DisplayListCanvas are FastNative
Unifies Canvas JNI on nMethodName naming
CanvasPerf results before:
INSTRUMENTATION_STATUS: basicViewGroupDraw_min=12492
INSTRUMENTATION_STATUS: recordSimpleBitmapView_min=13912
and after:
INSTRUMENTATION_STATUS: basicViewGroupDraw_min=11945
INSTRUMENTATION_STATUS: recordSimpleBitmapView_min=13318
Test: refactor, makes & boots
Change-Id: I06000df1d125e17d60c6498865be7a7638a4a13e
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
Just the basic cleanup first, will follow-up with a more
comprehensive update later
Test: builds & boots, refactor no behavior change
Change-Id: Ie3a7144b5fefdfda085e2ab50da8b0e627a1ecb8