the Mesh object can be part of each Layer (at least currently).
also reworked the Mesh code a bit to make it easier to access
the vertex data.
Change-Id: I0490851ba898f0aa2e55b62958dcd8bdb535e98b
we need too allow this case so that things like the rotation
animation can work.
with this change we only permit these screenshot if the
destination is SurfaceFlinger itself.
Bug: 10235036
Change-Id: I66fea5391e52b0d7f17f25827572b236f2d9eb71
If the implementation eglCreateContext failed, we called
eglGetError(), so we could check that it set the EGL error properly.
But since we'd already called this, when the app called eglGetError()
it would get EGL_SUCCESS!
Bug: 10181333
Change-Id: Ic45d3a8fcb8c4421e04844c6d2f52761790b5948
This prevents slow/malicious virtual display consumers from
backpressuring SurfaceFlinger and preventing it from updating other
displays.
Bug: 10193714
Change-Id: I3e877d97202628d2d9abea24b66576f38299c14d
We've had the extended behavior since Android 4.3, but the extension
hadn't been ratified by Khronos yet so we couldn't add it to the
extension string.
Bug: 9681677
Change-Id: I78842316a3ab7a3f66a0ac1a4742d837de664c4c
this means they only have access to the consumer end of
the interface. we had a lot of code that assumed consumers
where holding a BufferQueue (i.e.: both ends), so most of
this change is untangling in fix that
Bug: 9265647
Change-Id: Ic2e2596ee14c7535f51bf26d9a897a0fc036d22c
generally the last reference to a Layer is released in commitTransaction()
with mStateLock held. Layer itself only holds weak references to Client,
however, ~Layer() briefly promotes this weak reference -- during that time
the all other strong references to that Client go away, ~Layer is left with
the last one... then hell breaks loose as ~Client is called, which in turn
needs to acquire mStateLock.
We fix this by holding a temporary copy of the drawing state during
the transaction so that the side-effects of copying the current
state into the drawing state are seen only after mStateLock has
been released.
Bug: 9106453
Change-Id: Ic5348ac12283500ead87286a37565e8da35f1db2
Disable dropping of frames based on timestamp. Resume auto-
generating timestamps in Surface.
Bug 10151804
Change-Id: I15de26158e1d7ef22a5b150e685a126dc48ae2b4
While currently untested, this should allow to move the
BuffereQueue in the consumer process and have everything
work as usual.
Bug: 9265647
Change-Id: I9ca8f099f7c65b9a27b7e7a3643b46d1b58eacfc
If there are two or more buffers pending that are ready for
immediate presentation, drop all but the last one.
Any code that didn't explicitly specify timestamps for buffers
was using the default value (auto-generated "now"). As a result,
surfaceflinger would drop frames whenever more than one buffer
was queued. We now use zero as the auto-generated timestamp,
and we don't set the timestamp in eglBeginFrame().
Change-Id: I187f42d33de227cd3411ff0dcd3b9ce1961457eb
libutils is being moved from frameworks/native/ to system/core/ in order
to facilitate native C++ platform (non-frameworks) code.
Change-Id: I44089fb960591a40b8a9c30faabb10459d107d71
Fallout from the Flattenable change, update all its uses.
Additionnaly, fix/tighten size checks when (un)flatten()ing
things.
Removed the assumption by some flattenables (e.g.: Fence)
that the size passed to them would be exact (it can
and will be larger in some cases)
The code in Parcel is a bit complicated so that we don't
have to expose the full implementation (and also to
keep the code smallish).
Change-Id: I0bf1c8aca2a3128491b4f45510bc46667e566dde
Making an object Flattenable doesn't force it to
become virtual anymore. For instance, Fence and GraphicBuffer
are now non-virtual classes.
Also change Flatennable protocol a bit so that it updates
its parameters (pointers, sizes) to make it easier
to implement a flattenable in terms of other flattenables.
Change-Id: Ie81dc7637180b3c2cfcbaf644f8987ca804eb891
A recent change to screencapture to have the call to
IGraphicBufferProducer happen on the incoming binder
thread didn't set the result so the result was always
returned as NO_ERROR.
This made screencap fail on some devices (e.g. Wolfie)
which relies on some kind of fallback mechanism to
generate the screencap but the fallback mechanism
doesn't get triggered because the error isn't returned.
Bug: 9989385
Change-Id: I2aee91ea1034869fcbb0f49b9a0087c3cff43bbe
Signed-off-by: Mike J. Chen <mjchen@google.com>
