summaryrefslogtreecommitdiff
path: root/services/surfaceflinger/MessageQueue.cpp
AgeCommit message (Collapse)Author
2018-08-09SF: Move relevant scheduler files into one directory. Ana Krulec
Scheduler (see go/surface-flinger-scheduler) is going to live in its own directory. This CL just moves the relevant files into that directory. No changes to business logic. Test: all SF tests pass. Change-Id: Iff0717f9867316b28e68fd8311bd9fdc4e029951
2018-03-19SF: Separate MessageQueue into interface and impl Lloyd Pique
Test: Builds Bug: 74827900 Change-Id: I906892c00b6cb9adca3fbdd72a03001c2d72cbfc
2018-02-01SF: Cleanup EventThread Part 2 Lloyd Pique
De-refbase EventThread and a bunch of related classes. Convert from usign StrongPointer to std::unique_ptr to hold owned references, or bare pointers for unowned references. I did not see any need for using std::shared_ptr, or anything else, as SurfaceFlinger appeared to own all the objects, and they were created once and not really destroyed afterwards. Test: Things seem to still work on a Pixel XL Bug: None Change-Id: Ifff32118d31bc1bb51e38df695ebe5cf86d2bb6d
2018-01-31SF: Clang format selected sources Lloyd Pique
Bug: None Test: None Change-Id: Icef36ab31252e0e785d1088cbde2aaa0cf356fdf
2017-10-26surfaceflinger: make vsync injection more robust Chia-I Wu
There are more issues than I expected :) - no lock to synchronize enable/disable and injection - Every time injection is diabled and enabled, a new EventThread is created - mCallback might be nullptr - ENABLE_VSYNC_INJECTIONS/INJECT_VSYNC should require special permission - MessageQueue::setEventThread must be called from the main thread - MessageQueue::setEventThread does not handle EventThread switch well Bug: 65483324 Test: manual Change-Id: I7d7b98d1f57afc64af0f2065a9bc7c8ad004ca9f
2017-04-06libgui: Remove RefBase from BitTube Dan Stoza
Removes RefBase from BitTube, since because it is not a Binder object, it doesn't need to be reference-counted in this way. In the process, we rename IDisplayEventConnection::getDataChannel to IDEC::stealReceiveChannel to make it clearer that this is a non-const operation on the remote end that removes its access to the receive channel. This also adds a couple of methods for moving the receive file descriptor out of one BitTube and into another, since this is the essence of the IDisplayEventConnection::stealReceiveChannel method, and now with C++11 move semantics, we can do this without needing to return an sp<> from EventThread's implementation of stealReceiveChannel. Test: m -j + manual testing Change-Id: Ibaaca2a14fb6155052fe5434c14bc3e671b43743
2017-04-06libgui: Normalize IDisplayEventConnection methods Dan Stoza
This change modifies the IDisplayEventConnection API such that every synchronous method returns a status_t (to be able to return transport errors). This required changing getDataChannel to return its channel by output parameter rather than return type. Currently no more error messages are checked than before, but this will both enable calling code to check error messages if it desires and, more importantly, allow the Bp/Bn code to be semi-automatically generated using SafeInterface. Test: libgui_tests + manual testing Change-Id: I8d5bc5ef0475cee07b638a97079b234f0384c022
2017-03-07split libsensor our of libgui Mathias Agopian
Test: compile & run Bug: treble cleanup Change-Id: I5b2c2a14f7d3b364d25695cf0901c5b08cfb0fc9
2016-07-06HWC2: Backpressure missed vsyncs into apps Dan Stoza
Adds a mechanism to detect whether the prior frame SurfaceFlinger presented to hardware composer was actually picked up or not. We then use this mechanism to avoid pushing two frames in the same vsync. This backpressure is passed back to applications by not latching any buffers, which will manifest as dequeueBuffer stalling until SurfaceFlinger releases a buffer on the following vsync. Also makes the former INVALIDATE_ON_VSYNC behavior the only behavior so that this functionality works correctly. Bug: 29413700 Change-Id: Ibde358e45423ee6fea7b5e09ff65e49c4ad67baa
2016-05-16SF: Remove forced transaction on screenshot Dan Stoza
Removes the forced transaction that screenshots used to perform before capturing the screen. This was initially added to prevent screenshot capture from sneaking in between when a transaction is closed and when it is actually applied (at the next vsync), but in the presence of deferred transactions today, forcing a transaction to occur doesn't guarantee that the last transaction that WindowManager pushed has actually been committed yet, since it may be waiting for a buffer with which to synchronize. If WindowManager wants to guarantee some arrangement of windows is present for a screenshot, it needs to set the synchronous flag to true when calling closeGlobalTransaction and wait for the call to return. Bug: 27098060 Change-Id: Iaa36d76df521076cc8ed16576f651543bae419a8
2015-08-05libgui/SF: Fix some code warnings Pablo Ceballos
A couple of fixes to satisfy the Eclipse static code analysis tool. - Initialize all members in constructors - Remove unused forward declarations - Add parentheses when combining logical and bitwise operators - Fix a case statement with no break (it was intentional) Change-Id: Icecb8cc98c6f58b97ab33fffb621f0edc33a7d3c
2014-03-12native frameworks: 64-bit compile issues Mark Salyzyn
- Fix format (print/scanf) - Suppress unused argument warning messages (bonus) Change-Id: I05c7724d2aba6da1e82a86000e11f3a8fef4e728
2013-12-12Track Looper decoupling from ALooper Brian Carlstrom
Change-Id: I612f0de7002e24948a4cbbea7b416b4fbb3929aa
2013-04-10fix another bug where screenshots could end-up all black Mathias Agopian
SF transactions were always handled on VSYNC which allowed the screenshot to sneak-in between closing the transaction and vsync (before it's latched), resulting in a screenshot with the previous state. we now always force transactions to happen immediately before screenhots. Bug: 7552304 Change-Id: I0afc86b7e8366173daff5b9988bbb4d2a0f43860
2012-07-10one more step towards multiple display support Mathias Agopian
- remove dependency on cached state in validateVisibility - get rid of mVertices and mTransformedBounds - get rid of validateVisibility - get rid of unlockPageFlip - handleTransaction now returns a dirty region - computevisibileregion now uses window-manager space
2012-04-11Revert "handle surfaces posts independently from composition" Mathias Agopian
This reverts commit 562f4b2c1e555b853997113bb54b21303d642bc6. Change-Id: I96efe11c2f0494ed2d57fc580e49c598d913830e
2012-04-11handle surfaces posts independently from composition Mathias Agopian
surfaceflinger will now handle each surface post as soon as possible and handle the composition itself at VSYNC time as usual. Change-Id: I6b1ae33fd56062d86e5419ebab8def0ca5803fbf
2012-02-05ui freeze workaround: reenable triple buffering mode Mathias Agopian
we're seeing UI freezes when window updates and composition are separated. for now we workaround this by always doing a composition after window updates on vsync. triple buffering is reenabled for performance. Change-Id: I693d705000b7452489bb0b4918fbeadb9879315c
2012-02-01separate transactions from updates Mathias Agopian
with this changes, SF transactions are handled as soon as possible but do not trigger updates. the update is delayed until the next vsync. this allows us to work much better without requiring triple-buffering. Change-Id: I1fa10794d0cf742129f0877698b7b1e1f2ec7401
2012-01-30SF now synchronizes to VSYNC Mathias Agopian
Change-Id: Ic5e4f2ea9927ce133eef9499c03161325e9d02c5
2012-01-08Rename (IF_)LOGE(_IF) to (IF_)ALOGE(_IF) DO NOT MERGE Steve Block
See https://android-git.corp.google.com/g/#/c/157220 Bug: 5449033 Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
2011-12-03fix an issue where invalidate/transactions could be missed Mathias Agopian
Change-Id: I84a1fcba1317b2631f5441de7b7ecd12af5ad022
2011-12-02fix an issue where updates could starve transactions Mathias Agopian
Bug: 5700586 Change-Id: Iaa4adc1a6aea1db6e2943efe4caca1f6cbebfa72
2011-11-28rewrite SF's message loop on top of Looper Mathias Agopian
Change-Id: Ib56139f87a5c0b124e34da5c8151207219b2577b
2010-10-11deliver invalidate messages AFTER other messages Mathias Agopian
because invalidate messages were always handled first, they could prevent other messages to get through entirely. there is no real reason to handle invalidate messages first because the other messages are very uncommon and won't interfer with updates. Change-Id: Ib95cdf35a91407bd2f4d69dd082c5f546e1e0071
2010-10-11fix a bug where timeouts would only be handled when a message was delivered Mathias Agopian
Change-Id: I98c69b129e75e065e61f47e54f0f855d9401b0dc
2010-07-14move native services under services/ Mathias Agopian
moved surfaceflinger, audioflinger, cameraservice all native services should now reside in this location. Change-Id: Iee42b83dd2a94c3bf5107ab0895fe2dfcd5337a8