Applications sometimes crashed on exit due to the display event
receiver pipe apparently being closed while still a member of the
Looper's epoll fd set.
This patch fixes a few different possible races related to
the display event receiver lifecycle.
1. The receiver used to play a little dance with the Looper,
registering and unregistering its callback after each vsync
request. This code was a holdover from a time before the
surface flinger supported one-shot vsync requests, so we can
get rid of it and make things a lot simpler.
2. When the Choreographer is being accessed from outside the UI
thread, it needs to take great care that it does not touch
the display event receiver. Bad things could happen if the receiver
is handling a vsync event on the Looper and the receiver is
disposed concurrently.
3. It was possible for the Choreographer to attempt to dispose
the receiver while handling a vsync message. Now we defer disposing
the receiver for a little while, which is also nice because we
may be able to avoid disposing the receiver altogether if we find
that we need it again a little while later.
Bug: 5974105
Change-Id: I77a158f51b0b689af34d07aee4245b969e6260d6
this is possible now that we support only a single
EGL implementation. this allows a large code simplification.
Change-Id: I7a6b9db4c5d60f4407c6061e7a68729af63d5242
Improving load time by:
- using window animation for fade-in and not
waiting to create HW layer
- starting loading of thumbnails/icons earlier
- only initially creating views for the first
screenful of items
- recycling views
Change-Id: I529b1085fe35d81aaafeb7433ccaed8e0537f01c
from now on, the system can only have one EGL
implementation. this means the software and h/w renderer
cannot be used at the same time on a device. Of course, the
h/w renderer is always prefered; in its absence we
default to the software renderer.
Change-Id: Ib579f58055dd0ce4c4a99144131efa11c16ca3d3
If config_alwaysUseCdmaRssi is true, the RSSI signal bar only
shows the CDMA value, no matter it connects to EVDO or WiMax .
bug:5941743
Change-Id: I4187571898a9fb47162e1ccf0cc4c59c3136ae0b
This tool lets you visualize the time it took, in ms, to:
- Build display lists ("Draw" phase)
- Process display lists ("Process" phase)
- Swap GL buffers ("Execute" phase)
To use this tool:
- adb shell setprop hwui.profile true
- adb shell dumpsys gfxinfo <process name>
- Copy the profile data and paste it in a spreadsheet
- Generate a graph (stacked graph) and enjoy
Change-Id: I7840c0ea0f153550425aa798e3ada2f357688cf5
Some of the ongoing and upcoming jank work involves having
Views optimize their rendering. For example, it would be more
efficient for native display lists to be able to redraw themselves with
updated transform/alpha properties than it would be to do it the
way we do now, which causes view hierarchy invalidation and display
list recreation.
In order to do this, we need to push more intelligence for view
rendering into the Views themselves, rather than the complicated
mechanism we have now of ViewGroup handling some View properties
(transforms and alpha) and the Views handling the rest of their
rendering.
The first step toward this is to take the current drawChild() method
and push it into a new, package-private method in View that does the
same thing.
Future checkins will refactor the code further, simplifying it and
eventually optimizing around view property changes.
Change-Id: Id44b94536fc3ff80b474db7ef06862f4f51eedce
This change allows layouts to be notified of changes to LayoutParameters that have occurred
between layout operations.
If an assignment is made to the fields of LayoutParams instances that are already in use,
cachced data may become inconsistent with the new values. For complex layouts, like
GridLayout, in which the layout parameters define the structure of the layout, caching
could have caused ArrayOutOfBoundsException to be raised without this change. This case is
rare in normal code as initialisation is typically performed once. Its nevertheless possible
and much more likely in environments like design tools where layout parametrs may be being
edited on the fly.
Prevent errors as follows (belt and braces):
1. Change javadoc to request that changes to the fields of LayoutParams be accompanied with
a call to View.setLayoutParams(). (This calls requestLayout() which was what the previous
javadoc advised.) Provide a (for now, private) hook for layouts with caches to receive notification
of such calls so they can invalidate any relevant internal state.
2. For GridLayout, we cannot clone layout parameters as traditional Java grids do without retaining
two complete copies because of the public getLayoutParameters() method on View. Retaining two
copies is wasteful on constrainted devices. Instead, we keep just one copy and compute a hashCode
for the critical fields of a GridLayout's layoutParams. The hashChode is checked it prior to all
layout operations; clearing the cache and logging a warning when changes are detected, so that
developers can fix their code to provide the call to setLayoutParams() as above.
Change-Id: I819ea65ec0ab82202e2f94fd5cd3ae2723c1a9a0
