Because the DisplayAdjustment in Display can be modified it should not
use the reference of the DisplayAdjustment that is passed in to
construct the Display. Copy the members of the DisplayAdjustment
instead.
Fixes bug 9622994
Change-Id: I8201b02eba3ef35af3e01f10402cd5dafec1fb23
Bug #9425270
When a TextureView is detached from its window and immediately
re-attached, the display list is not destroyed but reused as is.
TextureView will however destroy the layer and surface texture
reference by the display list.
The solution is to force TextureView to invalidate its display
list on re-attach if it previously had a surface/layer pair.
Change-Id: I475096ffa7e5709155c4c943bf1bfaaaedbd4a1d
This change adds refcounting of Res_png_9patch instances, the native
data structure used to represent 9-patches. The Dalvik NinePatch class
now holds a native pointer instead of a Dalvik byte[]. This pointer
is used whenever we need to draw the 9-patch (software or hardware.)
Since we are now tracking garbage collection of NinePatch objects
libhwui's PatchCache must keep a list of free blocks in the VBO
used to store the meshes.
This change also removes unnecessary instances tracking from
GLES20DisplayList. Bitmaps and 9-patches are refcounted at the
native level and do not need to be tracked by the Dalvik layer.
Change-Id: Ib8682d573a538aaf1945f8ec5a9bd5da5d16f74b
Bug #9404946
Run another EGL context check after invoking user code to ensure
we have a valid context/surface pair before drawing the display list.
Change-Id: Iefb0ced7900ce0c54eb81b62d24ec00700bdce47
One problem this turned up is, because FastPrintWriter does
its own buffering, a lot of code that used to use PrintWriter
would fail -- if it pointed to a StringWriter, there was no
buffering, so it could just immediately get the result. Now
you need to first flush the FastPrintWriter.
Also added some new constructors to specify the size of buffer
that FastPrintWriter should use.
Change-Id: If48cd28d7be0b6b3278bbb69a8357e6ce88cf54a
First step in adding activity specific information to displays.
Replace CompatibilityInfoHolder with DisplayAdjustmentsHolder that
holds an activity token in addition to the CompatibilityInfo.
Change-Id: Ie113cd8dd9c62e0b5311204e039a4829096bea68
Invalidating a view property (alpha, rotation, etc.) causes an
invalidation process that does not work correctly when the view is
in a ViewOverlay. Specifically, if the view is not directly in the
overlay, but is instead inside a hierarchy which is within the overlay,
then the invalidation process stops at the ViewOverlay itself, because
the ViewOverlay has no "parent" view.
The fix is to override the invalidateChildInParentFast() method, just
like we override invalidateChildInParent(), to forward the invalidation
to the host view.
Issue #9389230 Animations not running for nested views under ViewGroupOverlay
Change-Id: I03fcef10ed1c8a91cb26d5d9d6945634b0b695b5
Bug #9404946
The Calendar app destroys one of its popup windows during a draw
traversal. Without this patch, we end up with no current context
nor surface after we're done gathering display lists. This means
that all of our EGL/GL calls will either fail or have undefined
behaviors. This could explain the PBO crash we are seeing with
the monkeys. Without a proper GL context, the driver returns NULL
when we map the PBO in CPU memory.
Change-Id: I210cf724be73da909a7621f807298a9f4a58e61d
Transitions used to be three phase:
- captureValues(): get all relevant property values in the
affected view targets
- setup(): set appropriate start values for affected views
prior to any transitions being played
- play(): create/play Animators for affected views
Now the second and third phases have been collapsed (and named
"play()"). This single step sets initial values for target views
and creates any Animators that should be played during the transition.
The transition mechanism stores these Animators and then starts
them at the appropriate time in the overall transition.
Issue #9507585 Transitions: Simplify Transition.play() design
Change-Id: I3fc67599b38fe49eee885dc5d32444db90b7703b
Previously, Fade transitions did not work correctly on hirearchies; they
only handled individual views. in particular, they would side-effect all
fading views by removing them from their parent to fade them out in the
overlay of the scene root. This worked for the fade-out transition itself,
but caused problems when those same hierarchies were added back in and
another Fade was run on the hierarchy, because now all of the views inside
that parent node had been removed, so they didn't fade in at all.
The fix was to add logic in Visibility to detect when a disappearing
view was inside a hierarchy that was also disappearing, and to skip the
fade on the views inside that hierarchy, leaving only the top-most
disappearing view to be faded out, thus preserving the hierarchy under
that faded-out group.
Along the way, there were various cleanups, fixes, and refactorings in the
transition code, and slight API modifications.
Issue #9406371 Transitions: Removing view hierarchy not working correctly
Issue #9470255 Transitions: Separate different transitions by Scene Root
Change-Id: I42e80dac6097fee740f651dcc0535f2c57c11ebb
This change enables applications to create a private virtual
display that renders its content to a surface of its own creation.
The display is private in the sense that only the application
that owns the display is allowed to place windows upon it.
Mirroring and blanking is also disabled for these displays.
Bug: 9192512
Change-Id: I852ea07f0c7df1d244e354e3daca3a6960285ca0
We fire view subtree mutation events every X amount of time.
It was possible that the runnable that fires an event to be
scheduled more than once while this should not happen. As
a result there was a crash since we did not expect to have
a second run and nullified a reference.
bug:9422804
Change-Id: I914e163b026cd217e1536ab0ed3a6b11113c2c73
This change adds several traits and properties to AccessibilityNodeInfo
aiming to allow better description of native Android components to
accessibility services as well as mapping web content to native Android
node info tree.
Change-Id: I36b893cbaa6213c9d02d805e9dc36b6d792b4961
If WindowManager.addView() is called soon after
WindowManager.removeView() then the MSG_DIE in the ViewRootImpl
mHandler queue may not have had time to execute. This will cause
WindowManagerGlobal to throw an exception since the DecorView
is being added before it has been removed.
This fix detects that situation by saving all Views that are queued
up for ViewRootImpl.doDie(). If addView() is called for one of these
Views then doDie() is called immediately and not called when MSG_DIE
eventually makes its way through the queue.
This change also makes doDie() non-reentrant by only allowing it to
carry out its functions the first time it is called. This keeps
dispatchDetachedWindows() from causing destruction by recursively
calling back into doDie(). This is usually caused by calling
dismissDialog() from within dispatchDetachedWindow().
Fixes bug 9404689.
Fixes bug 9406261.
Change-Id: Id4fc8054e273215d82366428fef51b9ba98385fe
Implement all system level InputEvent monitors as new
InputEventListeners. Only one InputChannel required and monitoring
can be enabled or disabled by registering with WindowManagerService.
Change-Id: I64714ab858342ed183c62b421098478ffb6637bc
