This patch adds support for drop shadows (setShadowLayer) for
drawPosText in the hwui renderer. In and of itself, it's not very
important, but it's on the critical path for correct mark positioning,
tracked as bug 5443796.
The change itself is fairly straightforward - it basically just adds an
extra "positions" argument to all draw and measure methods on the code
path for drawing drop shadowed text, as well as to the cache key for
cached shadow textures.
Change-Id: Ic1cb63299ba61ccbef31779459ecb82aa4a5e672
Compute the size of the backing textures based on the maximum possible
number of shades in the gradient.
Change-Id: I2d7f20477d31b81e9735f2c1d83ebdd0dbcbe340
To select the gamma correction method, adb shell setprop hwui.text_gamma_correction
with one of the following values:
lookup3
lookup
shader3
shader
See Properties.h for more information about these different methods.
You can also control gamma correction using the following properties:
hwui.text_gamma
hwui.text_gamma.black_threshold
hwui.text_gamma.white_threshold
Change-Id: I47970b804d2c590c37d3da5008db094241579e25
Bug #6836448
External bug: http://code.google.com/p/android/issues/detail?id=34946
DO NOT MERGE
DisplayListRenderer::drawPath was not invoking quickReject() properly,
passing x,y,width,height instead of left,top,right,bottom. A path
could thus get rejected when it should be drawn instead.
While working on this change I found a similar issue with another
drawing command, drawBitmapData().
Change-Id: I8306faf72db14d71b54ecb7de295c9a6957d9494
External bug: http://code.google.com/p/android/issues/detail?id=34946
DisplayListRenderer::drawPath was not invoking quickReject() properly,
passing x,y,width,height instead of left,top,right,bottom. A path
could thus get rejected when it should be drawn instead.
While working on this change I found a similar issue with another
drawing command, drawBitmapData().
Change-Id: I56484e8c101768cde6a78625290872f7849dd5ee
To enable it, the system property ro.hwui.text_gamma_shader must be
set to true. For testing, DEBUG_FONT_RENDERER_FORCE_SHADER_GAMMA
can be set to 1 in libhwui/Debug.h.
Change-Id: If345c6b71b67ecf1ef2e8847b71f30f3ef251a27
This change improves execution of display lists, particularly on
tiled renderers. The goal is to disable the scissor test as
often as possible. Drawing commands are rarely clipped by View
bounds so most of them can be drawn without doing a scissor test.
The speed improvements scale with the number of views and drawing
commands.
Change-Id: Ibd9b5e051a3e4300562463805acc4fd744ba6266
DO NOT MERGE
External bug: http://code.google.com/p/android/issues/detail?id=34879
This is a regression from ICS.
This CL also fixes a bug where a View's alpha would be applied twice.
Change-Id: I13a1546228f44d4c169259414b6fa103a6e4a0fa
When creating a new file using open(..., O_CREAT), it is an error
to fail to specify a creation mode. If a mode is not specified, a
random stack provided value is used as the "mode".
This will become a compile error in a future Android change.
Change-Id: I8635e8b69587ed107253870d991c3fcf563ca876
Bug #6597730
Text would sometimes not appear when rendered with textured content
(BitmapShader, LinearGradientShader, etc.) This was due to a misuse
of OpenGL texture unit in FontRenderer. Textured text normally uses
two texture units:
- texture unit 0 for the font cache
- texture unit 1 for the textured content (gradient, etc.)
Recent changes to the font renderer allow it to bind new textures
while processing the text's geometry (this happens when caches get
full or when switching font size for instance.) The bindings were
done without ensuring the texture unit was the correct one
(unit 0), thus replacing the content of another texture unit
(unit 1).
This lead to text being drawn using the font cache itself as the
content texture, making the text invisible.
Change-Id: I392b4c884f09223305f6cbc6253e2ef9a98944c9
A previous fix made it necessary for a frame to render something to GL
in order to cause a call to eglSwapBuffers(). Besides the calls being
tracked as part of issuing a DisplayList, there is also a potential call
to clear the canvas (via glClear()) on non-opaque surfaces. This call is also
good to track, since a surface that gets cleared without any other drawing operations
is worth flipping to the screen (to erase old contents on that surface).
This fix tracks the status of the pre-draw operations to find out whether
glClear() was called and then sets the drawing status appropriately.
Issue #6606422 QuickContact dismissal is janky again (Tracking)
Change-Id: I5fcaccfdc9293dd46b83f2fc279730a5d2740ebf
For comparison purposes, port the legacy velocity tracker
algorithm as it behaved prior to ICS.
Bug: 6413587
Change-Id: I7e8e56584dcdb1a3c660ca9d8f9c5bd5d868e449
This algorithm better tolerates certain kinds of errors in the
touch input than the least squares strategy but it may underestimate
the velocity of accelerating movements. This algorithm is
mainly of interest as a baseline for testing and comparison with the
least squares algorithm, which remains the default.
Bug: 6413587
Change-Id: I8ddb50084e44875e234717907e5b06d03f59788c
This change is very useful for testing purposes because it makes it
easy to compare different implementations to see how they behave.
There is no change to the current default strategy.
Bug: 6413587
Change-Id: I4d8567aa4160571ba9fa397ce419882cd9366749
