22 Commits

Author SHA1 Message Date
Mathias Agopian
54643d72f8 make sure to destroy GL objects on the GL thread
Bug: 7195815
Change-Id: I5bcac61cd0b903d1ccca0754fdb9cb1023efbe0f
2012-09-25 21:41:38 -07:00
Dave Burke
56257aff8a Revert "Deleting objects on the wrong thread is a silly idea Bug #7195815"
This reverts commit 8a1374946a928fcba7495c87ff6adda327fdfb9f

Change-Id: I53564a6c531d334afcc1fce0bea1e57ae266aa78
2012-09-25 20:30:09 -07:00
Romain Guy
8a1374946a Deleting objects on the wrong thread is a silly idea
Bug #7195815

Turns out that multi-threading is hard.

Change-Id: Ib0b4bd6dc3caea27f7ced22cbb363bb955fe58ab
2012-09-25 15:49:03 -07:00
Romain Guy
97dc9172b0 Avoid deadlock when deleting layers
Bug #7217459

Change-Id: I12bfa6c30c5030bd1b23ea6a3ce64240ab1dfba3
2012-09-23 17:49:24 -07:00
Chet Haase
603f6de35f Fix occasional crash bug with layers
Launcher occasionally crashes with a stack trace indicating that the memory
of a Layer object is corrupt. It is possible for us to delete a Layer
structure and then, briefly, use it to draw a DisplayList again before
that DisplayList gets recreated (without the layer that got deleted).

When this happens, if the memory got corrupted, it's possible to crash.

The fix is to add Layer to the other objects which we currently refcount
(bitmaps, shaders, etc.). Then instead of deleting a Layer, we decrement the
refcount. We increment when creating it, then increment it again when it's
referenced from a DisplayList. Then we decrement the refcount instead of
deleting it, and decrement when we clear a DisplayList that refers to it.
Then when the refcount reaches 0, we delete it.

Issue #6994632 Native crash in launcher when trying to launch all apps screen

Change-Id: I0627be8d49bb2f9ba8d158a84b764bb4e7df934c
2012-09-17 11:21:34 -07:00
Romain Guy
58ecc204fb Reduce the number of locks acquired by display lists
Change-Id: I1123aae0355de84db705bb75042c7083fc69c9f2
2012-09-07 14:01:09 -07:00
Romain Guy
8dcfd5e836 Clamp gradient textures to max GL texture size
Change-Id: I8ce4e50988f5194fe5ce4bde7945ec01673af3cd
2012-07-20 11:47:57 -07:00
Romain Guy
49c5fc0b9e Avoid unnecessary copy when invoking drawBitmap(int[])
Bug #6483390

Change-Id: I4d2d725ef50c9401b4bd998b6160128102b40745
2012-05-15 11:15:24 -07:00
Steve Block
5baa3a62a9 Rename (IF_)LOGD(_IF) to (IF_)ALOGD(_IF) DO NOT MERGE
See https://android-git.corp.google.com/g/156016

Bug: 5449033
Change-Id: I4c4e33bb9df3e39e11cd985e193e6fbab4635298
2012-01-03 22:38:27 +00:00
Romain Guy
6203f6c814 Reduce the amount of data cached by the gradients cache.
Change-Id: I8546f5a5ecf38031c9a40bdcc434d4c7f22da63d
2011-08-01 18:56:21 -07:00
Romain Guy
d586ad9c9f Fix another memory leak in OpenGLRenderer
Change-Id: I23ed56891452a05cf3ca13f6919c4fef90d5ff4e
2011-06-22 17:10:00 -07:00
Derek Sollenberger
6062c5912d Skia Merge (revision 808)
This is a companion CL to the one found in /external/skia

Change-Id: If81748545435cab20a5d8479329ab333cb973e16
2011-02-22 16:07:36 -05:00
Chet Haase
5a7e828842 Fix crash when Paths are GCd in hw accelerated apps
A recent change to optimize path rendering didn't account for
the destruction of native objects by the VM finalizer. We may be
done with the Java level version before we're done with the native
structure that's used by the display list. For example, a drawing
method on a View that creates a temporary path to render into the
canvas will implicitly create a native structure that is put onto
the GL display list. That temporary path may go away, but the native
version should stick around as long as the display list does.

The fix is to refcount the original native version of the path
and only delete it when the refcoutn reaches zero (which means that
it is no longer needed by any display list). This is a similar mechanism
used for bitmaps and shaders.

Change-Id: I4de1047415066d425d1c689aa60827f97729b470
2011-02-04 12:50:55 -08:00
Romain Guy
43ccf4663c Don't crash Launcher on config change.
Change-Id: Ibbbd7146c5ff69e9639b433f39041053654d808c
2011-01-14 18:51:01 -08:00
Patrick Dubroy
f890fab5a6 Ensure bitmaps aren't freed while referenced from a display list
Also removes the reference queue finalizers. They aren't necessary
anymore now that Bitmaps are allocated in the heap.
2010-12-20 17:02:15 -08:00
Patrick Dubroy
e4ac2d6b57 Allocate bitmap backing buffers in the Java heap.
Change-Id: I60f6ccff13357c1c518e9d56b02fe0171637edd1
2010-12-14 16:50:50 -08:00
Chet Haase
5cafc52fb1 Fix hang in native bitmap recycling due to nested mutex locks
Change-Id: Ic37d5408ddb3f68aba6520fb0c78ffde91dfbe62
2010-11-23 14:11:43 -08:00
Chet Haase
e7d2295c06 make ResourceCache for display lists thread-safe
Change-Id: I41885b4ae249d7d7c000bab17bf32340ba85ab3a
2010-11-11 16:44:46 -08:00
Romain Guy
fe48f65922 Free resources only from the GL context thread.
Bug #3179882

Resources were freed following garbage collections on a worker thread.
This worker thread had no EGL context, which would cause the renderer
to incorrectly assume that the memory was liberated.

Change-Id: Ifdb51f94ddf42641e8654522787bfac532976c7c
2010-11-11 15:36:56 -08:00
Chet Haase
ad93c2bb63 Optimizing ColorFilter in display lists
Change-Id: Ie4d5e5b0bc45e0ce47bba144049303c270762e54
2010-10-26 12:52:03 -07:00
Chet Haase
d98aa2de9a DisplayList optimizations and fixes.
We now use a copy of SkPaint objects to avoid having it changed from under us.
We reuse copies that have not changed. We also copy the SkMatrix every time to
avoid the same problem.

Change-Id: If3fd80698f2d43ea16d23302063e0fd8d0549027
2010-10-26 06:54:55 -07:00
Chet Haase
5c13d89c13 Optimizing display lists by referencing pointers to resources instead of copying them
Change-Id: I81ad3551d74aa1e5bb64d69e33d2eb29a6c1eb6a
2010-10-21 12:02:42 -07:00