Bug #7146141
When non-rectangular clipping occurs in a layer the render buffer
used as the stencil buffer is not cached. If this happens on a
View's hardware layer the render buffer will live for as long
as the layer is bound to the view. When a stencil buffer is
required because of a call to Canvas.saveLayer() it will be allocated
on every frame. A future change will address this problem.
If "show GPU overdraw" is enabled, non-rectangular clips are not
supported anymore and we fall back to rectangular clips instead.
This is a limitation imposed by OpenGL ES that cannot be worked
around at this time.
This change also improves the Matrix4 implementation to easily
detect when a rect remains a rect after transform.
Change-Id: I0e69fb901792d38bc0c4ca1bf9fdb02d7db415b9
* commit 'cfa979b200a016dd24e851e0da0ce956aa932e2e':
Fix image processing test to include all benchmark tests -- each test case can be excuted separately -- add a test case to run all benchmarks.
* commit 'd1a18011a68b2cac907d080d9044d527fd4c5853':
Fix image processing test to include all benchmark tests -- each test case can be excuted separately -- add a test case to run all benchmarks.
Region clipping, using Canvas.clipPath or Canvas.clipRegion, requires
a stencil buffer to be always present. In addition, extra wiring is
required in JNI and display lists.
This change only adds the necessary JNI/C++ APIs and some extra
plumbing to start the real work on properly supporting region
clipping.
A new debug define called DEBUG_CLIP_REGIONS can be used to draw
the current clip region. It is off by default, as is region
clipping.
The default implementation of clipPath() and clipRegion(), now
in native, mimics the previous Dalvik implementation to prevent
regressions.
Change-Id: I7903e7cfd7412b9b9b622566d4dbfce7bdcec00c
-- each test case can be excuted separately
-- add a test case to run all benchmarks.
DO NOT MERGE
Change-Id: I3c61dfe50267a6db11bc1895a4f37ed618a9103b
Bug #7970966
The bug described in #7970966 should normally never happen but just in
case, change the detection code to be more robust.
Change-Id: I7040a6087590e34abe8803cb8f83f051d77f3944
Fonts are now described by a transform matrix. This lead to switching
from a vector to a hashmap. This change therefore adds new comparators
and hash computations to Font.
Change-Id: I2daffa7d6287c18554c606b8bfa06640d28b4530
Due to our new bitmap storage optimization, we can't reuse the same
bitmap as input and output safely (since we modify the output directly).
This change updates ImageProcessing to appropriately create a distinct
output Bitmap Allocation and actually use it.
Change-Id: Iecf6c2d203bd1c370b8d0a9fb7e69b419d2eb69b
to get closer to the previous harness:
* sleep 750ms after launch then press HOME
* force close app after launch
* sleep 2s then move to next app
Change-Id: I70fefa7f3e87c637ed8b4cb2981c26d665c94319
There are two things going on here:
(1) In secondary users, some times theme information such as whether
the window is full screen opaque was not being retrieved, so the window
manager didn't know that it could hide the windows behind the app.
This would just be a performance problem, except that:
(2) There appear to be a number of applications that declare that they
are full screen opaque, when in fact they are not. Instead they are
using window surfaces with an alpha channel, and setting some pixels
in their window to a non-opaque alpha level. This will allow you to
see whatever is behind the app. If the system happens to completely
remove the windows behind the app, and somebody is filling the frame
buffer with black, then you will see what the app intends -- those
parts of its UI blended with black. If one of those cases doesn't
hold (and though we have never guaranteed they would, in practice this
is generally what happens), then you will see something else.
At any rate, if nothing else than for performance reasons, we need to
fix issue #1.
It turns out what is happening here is that the AttributeCache used
by the activity manager and window manager to retreive theme and other
information about applications has not yet been updated for multi-user.
One of the things we retrieve from this is the theme information telling
the window manager whether an application's window should be treated
as full screen opaque, allowing it to hide any windows behind it. In
the current implementation, the AttributeCache always retrieves this
information about the application as the primary user (user 0).
So, if you have an application that is installed on a secondary user but
not installed on the primary user, when the AttributeCache tries to retrieve
the requested information for it, then from the perspective of the primary user
it considers the application not installed, and is not able to retrieve that
info.
The change here makes AttributeCache multi-user aware, keeping all of its
data separately per-user, and requiring that callers now provide the user
they want to retrieve information for. Activity manager and window manager
are updated to be able to pass in the user when needed. This required some
fiddling of the window manager to have that information available -- in
particular it needs to be associated with the AppWindowToken.
Change-Id: I4b50b4b3a41bab9d4689e61f3584778e451343c8
