SurfaceControl.closeTransaction() will block until the transaction
takes effect and this happens at the next vsync -- in practice
it means this call blocks for ~15ms.
Immediately after that we ask the choreographer to schedule the
next frame, which will happen at the next vsync. depending the
timing, this would cause the window manager to animate at 30 fps
instead of 60.
This is fixed here by calling the choreographer before we
call closeTransaction().
In the near future, we should be able to fix this by using
an offseted vsync for the window manager and it won't need
closeTransaction() to block at all.
Bug: 10209014
Change-Id: I33d0c5ecfc25154b2859f3023a8cda6e641826bf
Available for retrieval via future APIs if desired. Dumped by dumpsys.
Not added to batterystats or ACTION_BATTERY_CHANGED intents at this point.
Also fixes a formatting problem in the existing dumpsys output for voltage.
Change-Id: I5320b19035914256fb872c13095c09c648dd522a
In order to determine if the topmost activity needs to be moved out
of the way, compare its task to the task of the source activity
rather than compare the activities themeselves.
Fixes bug 10182783.
Change-Id: Idd4542d7ddce8b7586ee47f100366bc47e07d54f
Since the Restrictions feature was removed, some cleanup code was
added to unblock apps. But the cleanup is causing some runtime exceptions
due to happening too early in the boot up sequence. Moved the cleanup
to after boot_completed broadcast is received.
Bug: 10212758
Change-Id: Id42eff16b54c24ea48cf8b3a81f77ea801264edd
1. Update the transition between the print job edit dialog and the
generating print job dialog. Now the former shrinks into the
latter.
2. Added most of the notification assets.
Change-Id: I84f35df5cb4f71b86a103c16ab87fd4d108b055b
it's probably not strictly needed, but it guarantees
that the app won't deadlock itself while using a
TextureView -- this could happen if it blocked
in View.onDraw() waiting for the producer
this mimics the behavior TextureView always had.
Change-Id: I453339237a48dea91a10840b8cc0f5d2d84d1520
Bug #10185769
The assets atlas contains assets that need to be blended and assets
that do not need to be blended. With a single merge id, currently
set to be the pointer to the atlas itself, draw ops merging could
generate batches of commands containing both opaque and translucent
assets. The blend state was chosen from only one of the assets in
the batch, leading either to inefficiencies (blending large opaque
assets) or incorrect behaviors (not blending translucent assets.)
This change introduces two new merge ids in the atlas: an opaque
key and a blend key. These keys are simple booleans set to false
and true respectively (the values do not matter really.) Their
memory addresses are used as the merge ids when createing draw ops
batches, allowing all opaque ops to be batched together and all
translucent ops to be batched together.
Change-Id: I114dba0533c44987e53864b471ccb28c811f2025
