Removes mMultipliedAlpha, using the snapshot alpha for all
non-overlapping display list alpha control.
Additionally, fixes opacity issues where children of
hasOverlappingRendering=false displaylists (both hw layer sublists and
other sublists with hasOverlappingRendering=false)
Change-Id: I6adc16da855835f9f518f8967628e5d0135c789b
It is useful, particularly in animations, to be able to add a view, or at
least some graphics, on top of a view. For example, to have a child of a layout
fade away, we might want to remove the child from that layout and then fade it out
gradually. Meanwhile, we have to have a place to put that view where it will be
drawn. We could do this in the content container sometimes, but this is not a
reliable workaround in the general case, and may obscure other siblings/parents of
the layout/view in the hierarchy. A better approach would be to place a view/graphic
temporarily in the layout itself.
This feature adds the ability to add one or more Views and Drawables to an "overlay"
layer, after which the view will handle drawing that extra content when it redraws itself.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I70bf78c46ee3db8bd87ea1cdc2ecb5c0747ccbf9
bug:8037003
A recursive drawDisplayList call is now entirely deferred before
playing back to the screen and issuing GL commands. This way, the
entire stream can be inspected, optimized, and batch work (such as
uploading textures) before issuing commands.
Additionally, this fixes an issue where operations draw could move
across restores corresponding to saveLayer(alpha). Those and other
similar cases (such as complex clipping, requiring the stencil) are
now treated as batching barriers, with the operations that change
renderer state in a way that's difficult to defer are just re-issued
at flush time.
Change-Id: Ie7348166662a5ad89fb9b1e87558334fb826b01e
Seeking an animation after the animator has reverse()'d to the beginning
will result in seeking in reverse. Starting the animation will make it proceed
normally, and calling reverse() will also give expected behavior. But seeking
causes this unexpected behavior because the state of reversing is not reset until
the next time the animation is played (either by start() or reverse()).
Fix is to reset the internal flag when the animator ends.
Issue #8234676 Reversing an Animator Leaves it in A Reversed State Until Explicitly Started
Change-Id: I9d212ae1879aa277d1add7eb4c7ec61432af059e
Different kernels seem to handle ADDR_COMPAT_LAYOUT differently,
sometimes passing it to its children, sometimes not. If it's not
passed to its child successfully, we can end up in a restart loop.
Instead of testing for the presence of ADDR_COMPAT_LAYOUT, use an
environment variable instead, which is handled more predictably.
Bug: 8392487
Change-Id: Ia531dd2abb4e1cd46f3430d844e644f53581f530
For the emulator, we want people to see memory as it
actually is, not how we're hacking around buggy apps. Don't
set ADDR_COMPAT_LAYOUT on the emulator.
For reasons that I don't understand, personality(ADDR_COMPAT_LAYOUT)
does not persist across an exec on the emulator. app_main gets
into a tight loop restarting itself because of this. This change
also works around that bug.
Change-Id: Ia73a7d2d623c25cf39d248145d97307945d554da
