dd671599bed9d3ca28e2c744e8c224e1e15bc914 |
|
19-Apr-2013 |
Chet Haase <chet@google.com> |
Fix quickReject logic to account for setClipChildren() setting The rendering code optimizes by rejecting drawing operations that lie outside of the bounds of their views. This works in most situations, but breaks down when containers have called setClipChildren(false), because we reject drawing that is outside of that container, but which should be drawn anyway. Fix is to pass in the value of that flag to the DisplayList drawing routines which take that flag into account when deciding whether to quickReject any particular operation. Issue #8659277 animation clipping Change-Id: Ief568e4db01b533a97b3c5ea5ad777c03c0eea71
/frameworks/base/core/jni/android_view_GLES20DisplayList.cpp
|
52036b19a5f82bc4d75cfcbff99c65df8d25a99b |
|
15-Feb-2013 |
Romain Guy <romainguy@google.com> |
Expose display list APIs The exposed APIs are slightly simpler than the full APIs used internally. Only APIs useful to applications are exposed. Change-Id: Ie03014628d40ad5ef63dedbc52ce3def84429d54
/frameworks/base/core/jni/android_view_GLES20DisplayList.cpp
|
6a2d17f71342f981c9df1dc5beff33e30eb3ae2b |
|
30-Sep-2012 |
Chet Haase <chet@google.com> |
Fix texture corruption When memory gets low on a device, activities flush everything they can. Hardware-accelerated activites, such as Launcher, flush GL resources and destroy the GL context. However, some resources were still hanging around, due to deferred destruction policies (we don't delete layers until the DisplayLists they are in are finalized, to ensure we don't deref deleted objects). This meant that we were referring to obsolete GL data in these objects. in particular, it meant that we might come around later, after a new GL context was created, and delete a texture object that was incorrect. We use the layer's "texture id" to refer to the texture underlying the layer. But if there's a new GL context, then this texture ID is no longer valid, and we may be deleting the texture that a different object (layer, icon, whatever) is referring to, because the driver may return that same ID under the new GL context. The fix is to more aggressively delete things that we know will not be used again when the GL context is destroyed. In particular, we delete all resources being used by all DisplayLists at GL context destruction time. Issue #7195815 Textures corruption on all devices, in many apps Change-Id: I52d2d208173690dbb794a83402d38f14ea4c6c22
/frameworks/base/core/jni/android_view_GLES20DisplayList.cpp
|
db8c9a6a4d9bf8c39f834b25611926caf21380f6 |
|
22-Mar-2012 |
Chet Haase <chet@google.com> |
Optimization of alpha with DisplayList properties Some views (such as ImageView and TextView) handle non-opaque alpha values directly. This was originally an optimization, but we can handle it faster in many cases without this optimization when DisplayList properties are enabled. Basically, if a view has non-overlapping rendering, we set the alpha value directly on the renderer (the equivalent of setting it on the Paint object) and draw each primitive with that alpha value. Doing it this way avoids re-creating DisplayLists while getting the same speedup that onSetAlpha() used to get pre-DisplayList properties. Change-Id: I0f7827f075d3b35093a882d4adbb300a1063c288
/frameworks/base/core/jni/android_view_GLES20DisplayList.cpp
|
9420abd56a2af7ddbeb70562b79d61b2dca8c5a1 |
|
30-Mar-2012 |
Chet Haase <chet@google.com> |
Re-enable DisplayList properties. Re-enabling DisplayList properties last week caused some app errors due to the way that some transforms were being handled (specifically, those coming from the old Animations and ViewGroup's childStaticTransformation field). This change pushes *all* transform/alpha data from View.draw() into the view's DisplayList, making DisplayLists more encapsulated (and correct). Change-Id: Ia702c6aae050784bb3ed505aa87553113f8a1938
/frameworks/base/core/jni/android_view_GLES20DisplayList.cpp
|
a1cff5043d0fbd78fcf9c48e7658e56a5b0c2de3 |
|
21-Feb-2012 |
Chet Haase <chet@google.com> |
Handle view properties at the native level Basic functionality of handling View properties (transforms, left/right/top/bottom, and alpha) at the native DisplayList level. This logic is disabled for now (via compile-time flags in View.java and DisplayListRenderer.h) as we continue work on it (there is no advantage to the new approach until we optimize invalidation and rendering paths to use the new code path). Change-Id: I370c8d21fbd291be415f55515ab8dced6f6d51a3
/frameworks/base/core/jni/android_view_GLES20DisplayList.cpp
|