bug: 26562461
fixes: 30109912
SeekBar clips out the area of the thumb when drawing its track. This
creates a clip region, since a rect has been subtracted.
This changes region transform support in computing final clip to
properly support any rect-to-rect transform (such as 90 degree rotation)
when applying a clip region.
Change-Id: Ib3bbc52637e59e00b3a7e7d5c4c40555e26c578b
Added a strong pointer to hold reference to VD in the animation,
so that VD will not be released before animation is finished/destroyed.
BUG: 29438210
Change-Id: I311cd83043f988640de44f637cb474baada9b5ca
Add a new mode, controlled by sys.use_fifo_ui property, that enables the
top app's UI and RenderThread to be SCHED_FIFO. This eliminates almost
all jank due to scheduling competition with non-UI critical
threads. This mode may not be suitable for all devices.
bug 24503801
Change-Id: I7b8a31830ad80f7efa00236928d5476998ed4e00
fixes: 29771171
This is a regression from HWUI_NEW_OPS, a roundOut
was missing in the new path that was in the old one
Change-Id: Ibf223d550bb5525781864dd9b7f7cd6d73adb98b
Bug: 29628138
1: Make windowPositionLost synchronous as that's
what the Java side was expecting
2: Make the listener ref counted as otherwise
there's a race condition with the GC, which could
end up with use-after-frees
3: Ensure that all position updates are invoked
prior to frame completion
Change-Id: Iedbc017f611ba2878a49b4586612f79249ca2fe3
Fixes: 29072773
By using computeFrameTime AnimationContext would
potentially end up modifying the latest vsync if
a very-slow frame was received from the UI thread.
This could potentially desync animations that were
RT & UI thread 'synchronized', but more significantly
it would confuse the swap chain which tries to only
draw one frame per vsync causing unneccessary frame
drops.
Change-Id: Ibd2ec3157ce32fee1eec8d56837c45a35e622895
This allows WebView to add itself to the ResourcesManager and
remain their even after configuration changes and multi-window
changes.
Bug:29112218
Change-Id: I2cb131ae2c61fb58c48babafdd46c1882be96aa9
bug:29127615
Primarily fixes case where 0 dimensioned layers could be
created/updated. Additionally, adds more logging in incomplete
framebuffer cases, if they still occur.
Change-Id: Ib90dbbafd6905aca3c8f46e64064e13a308f713d
This CL changes the target of VD specific animators to VectorDrawable,
instead of RenderNode. The benefit of doing so is that animators can
now detect whether the animation is meaningful by checking whether
their VD target is in the display list. If not, that means the VD is
not drawing for the current frame, in which case we can be smarter
and more power efficient by removing the animator from the list and
posting a delayed onFinished listener callback.
By setting VD as the animation target, when an ImageView decides to
update its drawable from one AVD to something else, we'll be able
to detect that the previous AVD is no longer in the display list,
and stop providing animation pulse to the stale AVD, which is
something we couldn't do previously. This change also
handles the case where one AVD instance could be drawn in two
different views.
Bug: 27441375
Change-Id: Iaad1ed09cfd526276b95db0dd695275c28e074e8
Previous check .isEmpty() is not sufficient, because getWidth() may have
value 0.5, so technically it is not empty, but when this size is passed
to texture calls it is converted to uint_32 and it becomes zero.
bug:28941093
Change-Id: Ia7c2bf0340466d5376f235fb5da54ad2ddfa0a03
When mutating vector drawables, we need to not only copy over
the VD tree structure, but also the properties of the VD tree,
such as alpha.
Bug: 28974071
Change-Id: I265e7e3cb92455b876cae248bcb9811230cb34f9
Bug: 28667141
saveLayer clips the layer to the size it needs to
be and will translate content if necessary, but
the drawLayerOp that results from that was not
translated to handle the shifted draw content.
This fixes that
Change-Id: I3c9ffd5d0282fa1b958bced94c25e9744281e9be
Change the implementation of getLocales() to iterate the set of
configurations using a templated method, instead of using the result
of getConfigurations().
Also remove the check for AndroidManifest.xml when adding an asset path.
This is unneccessary.
Bug:28625993
Change-Id: I16de5da598d0c371421d1dc8eee054dce9baf53a
The underlying implementation needs to be completely rethought. If a
process crashed while you were in pointer capture mode, you were
pretty much stuck in it. If the mouse happened to move outside of
your bounds right before you called the API, you'd never actually get
an event (whatever it was hovering over would). There's no easy way
for the system to tell you when you enter or exit this mode because
it doesn't actually track who the current request is from.
These are all solvable, but not in the N time frame. Maybe next time.
Bug: 26830970
Change-Id: I03efd63c499b86dc278491ca3284566c1965581f
