bug:30537130
BeginLayerOps were being rejected in a way that allowed the associated
EndLayerOps to still be recorded. This was a violation of DisplayList
content expectations, and caused crashes in FrameBuilder when trying to
play these DisplayLists back.
Change-Id: I531b840aa5c4ffb1ee458da3f4b366978eaeafbe
This CL fixed an integer overflow error caused by using integer literal
when it should be a float literal that defines a double.
BUG:30739855
Change-Id: If2bdb0eb7a2e93d28434bfe72ec11e8f1f2a1eda
Bug: 30587465
Someday maybe the technology will exist to
allow sharing a simple constant between
Java and C++, but today is not that day.
Change-Id: I17694746cb8712058133cd5ea10c47b9909f740b
Bug: 30342017
Upload recents thumbnails in the
dead gaps between frames instead of
at the start of a frame. This eliminates
jank caused by the large texture
upload.
Change-Id: I507cd286d199109c7a9a1511d68ba5ab5d28069f
When we stop scheduling for new frames on RenderThread, we should
put the running animations on pause, rather than purge the list
of the running animations, such that in the next full
sync, the animations that were paused will continue to run.
BUG: 30226711
Change-Id: I36ff6f5d26ffa7999f60ca0ff676a35157577dc2
Bug: 30440166
If we are using HWC2, there's a change in timing
when in triple buffering with the pipelined offsets.
This changes JankTracker to recognize that and silently
erase that from the total duration
Change-Id: Ib1fd4209070f17dbd2baed707c8cf73fb11c3cf2
Bug: 30342762
Frame dropping was too frequent and would trigger
during normal triple buffering steady state. Bump
the threshold to drop from 3ms stall to 6ms stall.
Change-Id: I5c1faeaabf0d02323a28e697a4af4105fbcf1c53
VectorDrawable contains properties that can be mofidied from both
UI thread and RenderThread. The two sets of properties are synced
during prepareTree. Previously VD animations ran before prepareTree,
as a result, during prepareTree the property sync overwrote some
of the animatable properties. In other words, the first frame of
the animation wasn't correct. An example is in battery saver mode
when the animation only has one frame to animate (0-duration), the
end result looked wrong.
This CL moves the VD animation to after prepareTree to solve the
problem mentioned above. Meanwhile, in order to signal which
VD will be animated so as to have them properly damaged, all VDs
with running animators are marked dirty.
Bug: 30226711
Change-Id: I831dae9abb2908876c935b9be4c11dfd09452d5c
bug:29771461
bug:29413700
bug:30181577
Changes frame interval gap detection to look for wider gaps, as they
were incorrectly firing all the time.
Also adds a 500ms minimum gap between frames dropped because of stuffed
swap chain, to prevent dropping too often.
Change-Id: If16ed637d54bf37015704be102c5c2e3731a0824
Also, standardize on a set of possible modes for the displays to
enter and separate the configuration of the color mode from the
configuration of the display mode.
Bug: 29044347
Change-Id: I6af0a7d1f11bc72d4cefc380f115c1fb00788864
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
