| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Change-Id: Ibe11a83199f3db1ba6266a1a9e11c7fc24ceb554
related-to-bug: 6732061
|
|
|
|
The desc.txt file can now mark parts as 'must finish cleanly' by using
'c' as the part line prefix rather than 'p'. If so indicated, if the
bootanimation is asked to quit it will do so only after waiting to
finish that part.
I considered either making init.c service killing smarter or promoting
bootanim to be a bindable service with a requestExit method. However,
these changes are probably too big/risky given our ship date. So
I used a property as a mailbox between SurfaceFlinger and bootanim.
Bug: 6679877
Change-Id: Id7dca22caa50b450fff25ca94f7242d971034f41
|
|
|
|
When turning the screen off we could have 2 waiters on the
vsync condition: The main vsync waiter as well as one in
onScreenReleased(). We were only signaling the condition though,
so it it would be possible to wake onScreenReleased() without waking
the main vsync thread which would then be stuck in .wait().
We fix this by just using broadcast() when receiving a vsync event.
We also add a broadcast() to signal when the state of
mUseSoftwareVSync changes. This is important particularly for
the transition from hardware to software vsync because the main
vsync waiter might have observed mUseSoftwareVSync == false
and decided to block indefinitely pending a hardware vsync
signal that will never arrive.
Removed a potentially deadlocking wait for a signal in
onScreenReleased(). The function was trying to wait for the last
vsync event from the hardware to be delivered to clients but there
was no guarantee that another thread would signal it to wake up
again afterwards. (As far as I can tell, the only other other
thread that might wake it up at this point would be a client
application issuing a vsync request.) We don't really need to wait
here anyhow. It's enough to set the mUseSoftwareVSync flag,
wake up the thread loop and go. If there was a pending vsync
timestamp from the hardware, then the thread loop will grab
it and use it then start software vsync on the next iteration.
Bug: 6672102
Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
|
|
into jb-dev
|
|
When turning the screen off we could have 2 waiters on the
vsync condition: The main vsync waiter as well as one in
onScreenReleased(). We were only signaling the condition though,
so it it would be possible to wake onScreenReleased() without waking
the main vsync thread which would then be stuck in .wait().
We fix this by just using broadcast() when receiving a vsync event.
We also add a broadcast() to signal when the state of
mUseSoftwareVSync changes. This is important particularly for
the transition from hardware to software vsync because the main
vsync waiter might have observed mUseSoftwareVSync == false
and decided to block indefinitely pending a hardware vsync
signal that will never arrive.
Removed a potentially deadlocking wait for a signal in
onScreenReleased(). The function was trying to wait for the last
vsync event from the hardware to be delivered to clients but there
was no guarantee that another thread would signal it to wake up
again afterwards. (As far as I can tell, the only other other
thread that might wake it up at this point would be a client
application issuing a vsync request.) We don't really need to wait
here anyhow. It's enough to set the mUseSoftwareVSync flag,
wake up the thread loop and go. If there was a pending vsync
timestamp from the hardware, then the thread loop will grab
it and use it then start software vsync on the next iteration.
Bug: 6672102
Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
|
|
Bug: 6594275
Change-Id: I032b055207d16bfff93ee8a350c0dc52b9102926
|
|
|
|
|
|
|
|
jb-dev
|
|
Let's go with 384 megs, half way between the large heap size on
Xoom and 512.
Change-Id: I4a7f2e5a8b2920b49fa53777725e24811145f5f2
|
|
Bug: 6615693
Change-Id: I64c3b3ce0bba62d9c332a795f7d979fb753dc27b
|
|
|
|
this would happen when a resize was pending (ie: we have received
and processed a resize transaction but have not received a buffer
with the right size) and a new transaction came in that didn't
involve a resize, for instance a translate-only transaction.
in this case, we would incorrectly update the drawing state
with the pending size, eventhough we still don't have a buffer
for it.
the solution is quite simple, we never allow the size to propagate
from current to drawing state during the regular transaction processing
(unless we are in fixed-size mode -- meaning we don't need to have
a matching size buffer), this propagation happens later once we
receive the buffer.
Bug: 6624163
Change-Id: I11a97e4b88a7f3a0571ddcfe99c86cb04ce01a4d
|
|
|
|
|
|
this allows us to enable h/w acceleration on low-end
devices while keeping memory usage down.
Bug: 6557760
Change-Id: I8af2de3038dc2579360b8b73aa452cb7a0e506a9
|
|
Bug: 6576505
Change-Id: I494b7627f2e271a234706bf49a9490f8ac56c77a
|
|
This is for a 7in hdpi/tvdpi tablet with 1G of RAM.
That sounds kind-of familiar. I don't know. Have I seen
such a thing before? Maybe.
Bug: 6576049
Change-Id: Iabc245692d5106feec9199eb2b5a3d06e27a9b83
|
|
|
|
this would happen when a window started with size A, was
resized to B and immediately resized to A. In this situation
the erquested and active size would be the same, and SF
would think a transaction wasn't needed.
we fix this by always comparing the requested sizes.
Also, make sure to set mRefreshPending once we're sure
we have succesfully called updateTexImage().
Bug: 6580962
Change-Id: I2c48b4df7f05fd35c9e1d2dd82095b0f3d5a0b6a
|
|
|
|
|
|
|
|
|
|
Bug: 6559630
Change-Id: I5a667f219f431838638acefbc9fa6afa610971bd
|
|
We don't need this code anymore and it is just in the way.
Bug: 6559630
Change-Id: I1dc9decf85d5ea1feab159c2985da6c20baffdd5
|
|
Bug: 6559630
Change-Id: Iacdf4bb4c1c125c09305cbd8cb443c7c80cfc010
|
|
|
|
this bug introduced recently would happen when the very first
buffer of a surface was rejected for not having the right size
Bug: 6577035
Change-Id: I9fabf20006019f2a6c308be7c7f5c05bdcfd5014
|
|
SurfaceFlinger is using this new feature to reject buffers that
don't have the right size.
Bug: 6498869
Change-Id: I8a7250a47db6c082a357b703feb3b9d0fc8d3443
|
|
here we just shuffle a bit the code inside lockPageFlip(),
we move the code that handles the buffer size closer to the call
to updateTexImage(). no functionality change.
Change-Id: Ie3193cd86cd32cf3c89532449fd747d145ca0ab6
|
|
use a flag instead of pre-committing the "requested" state
to prevent propagation or "requested" to "active", which makes
things a lot clearer when reading the code.
also avoid going through the "resized" code-path when requested
size is equal to "active" size.
Bug: 6498869
Change-Id: I24f893ba0ec5ca06aac5b8da9818989ae7ce4005
|
|
Bug: 6498869
Change-Id: I14d1b4d6960b87b5a7c4d7e20b92538edd9331ff
|
|
|
|
The host-accelerated GL ES driver doesn't do the implicit
synchronization required when fence sync isn't used.
Bug: 6515813
Change-Id: I6a667f2db6b519f3557b5abda78775f767841dae
|
|
Implementing this in libagl allows us to start using it for
SurfaceTexture in emulator builds, which is necessary to avoid
corruption in the Browser when using the host-accelerated GL path.
Bug: 6515813
Change-Id: Icafba8687cb5d010d8d42b3866b298d2be984fc9
|
|
|
|
it should read OpenGL_ES (with an underscore)
Bug: 6529643
Change-Id: I7caf07793bffe5a8dcceaff496a222077486fc87
|
|
|
|
this prevents SurfaceTexture producer to hang in dequeueBuffer()
when something goes wrong in the consumer.
only the consumer gets an error and the current frame is kept
instead of the new one. the producer is unaware of the problem.
Bug: 6476587
Change-Id: Ie6db5526632aabc3e60229b93dfe29c19491ade4
|
|
Bug: 6476587
Change-Id: I4345f1100db02786bb50ad83ca7b559cad301706
|
|
Bug: 6511421
Change-Id: I7a85a55e66a3a8d9937df575e98a5efec01a634f
|
|
|
|
|
|
would happen when vectors are copied and new items is
added in both vectors. we didn't duplicate the underlying
storage when adding items in vectors.
Bug: 6515797
Change-Id: If544c07d96c05821e088d7f2c9b5736f7e306c31
|
|
Bug: 6501151
Change-Id: Ied638bdbe9ed6fbf749a44de8ac1f9d4167829c1
|
