14e8b01a761180250671f3d6494532d8bd04fa8e |
|
07-Nov-2013 |
Jesse Hall <jessehall@google.com> |
Don't change the framebuffer target until we render a new one Continuing to send the last-rendered framebuffer to HWC on subsequent frames allows the HWC to read partially-composed regions that haven't changed, instead of re-composing from scratch. Bug: 11573910 Change-Id: I8829877d2a06001f1e1b3f168cbba71c7b217b2d
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
497ba0e08503806571b52ebe27cc7eee4c0e71a7 |
|
05-Nov-2013 |
Jesse Hall <jessehall@google.com> |
Don't use implementation-defined format with CPU consumers If the virtual display surface is being consumed by the CPU, it can't be allowed with HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED since there is no way for the CPU consumer to find out what format gralloc chose. So for CPU-consumer surfaces, just use the BufferQueue's default format, which can be set by the consumer. A better but more invasive change would be to let the consumer require a certain format (or set of formats?), and disallow the producer from requesting a different format. Bug: 11479817 Change-Id: I5b20ee6ac1146550e8799b806e14661d279670c0
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
c354effe97be26638618e3bc0da81a3f8b384b20 |
|
25-Oct-2013 |
Jesse Hall <jessehall@google.com> |
Fix handling of undefined TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS related to b/8316155 - Implement HWComposer 1.3 w/ virtual display support Change-Id: I2dc8d65a74174aa833cc491264f97f1f2df49307
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
6a968462f9ce4d93d81fcc13672073e3e6eb2e0f |
|
04-Oct-2013 |
Naseer Ahmed <naseer@codeaurora.org> |
Add a boardconfig to force HWC composition of virtual displays When this boardconfig is defined, even when all virtual display composition is done by GLES, the HWC will be forced to copy from the GLES framebuffer to the output buffer. On some hardware this allows HWC to do format conversions that would otherwise have to be done by the consumer, with worse power and/or performance. Bug: 8316155 Change-Id: If980ecc589f138cef063eafa757f7f748196713e
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
1e27ba234c5bfd4f6535ee221a6c20407a50f868 |
|
27-Sep-2013 |
Jesse Hall <jessehall@google.com> |
Use implementation-defined format when HWC writes to output buffer When GLES isn't writing to the output buffer directly, request an implementation-defined format with minimal usage flags, leaving the format choice up to gralloc. On some hardware this allows HWC to do format conversions during composition that would otherwise need to be done (with worse power and/or performance) by the consumer. Bug: 8316155 Change-Id: Iee6ee8404282036f9fd1833067cfe11dbadbf0bf
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
b716e57048e945d5bceda33c2434c65d06464dba |
|
02-Oct-2013 |
Jesse Hall <jessehall@google.com> |
Set the outbuf acquire fence after we actually have it. In GLES-only mode, we don't have the outbuf acquire fence until after GLES composition is done for the frame. We were setting the fence in HWC's state immediately after dequeueing the buffer from the consumer, before GLES had started. This fence got passed through HWC and on to the consumer, so the consumer was reading the buffer before GLES was done writing to it. Now we update HWC's state just before set(), when we know we have the right fence. Bug: 11000763 Change-Id: Iea9db4c69634c352dc2d600f0bdb6bef2a432636
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
6da15f46f5f8b38e31384d641f8d3db2c3c6ea30 |
|
26-Sep-2013 |
Mathias Agopian <mathias@google.com> |
fix crashers with wifi/virtual displays Bug: 10647742 Change-Id: I4b8ed9da52ef95af3a3b3a04b98514a3776a674d
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
365857df8b94c959dea984a63013f6e7730ef976 |
|
12-Sep-2013 |
Mathias Agopian <mathias@google.com> |
Make sure do disconnect from a BQ when its client dies. Bug: 5679534 Change-Id: If447e8673df83fe0b1d6210641e0a48522501a53
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
8db92553e9e6263cd41eaf1a1ebc9e3f88f92b5f |
|
30-Aug-2013 |
Jesse Hall <jessehall@google.com> |
Force async behavior for the virtual display output BufferQueue Bug: 10551087 Change-Id: I40bbb2b87d64420939a0ea309254f281437dab56
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
028dc8f2d72bc7cd4fbe7808781443125a742f78 |
|
21-Aug-2013 |
Jesse Hall <jessehall@google.com> |
Provide HWC prepare with a valid output buffer We weren't dequeing and setting the output buffer until just before set(). This didn't allow HWC to make decisions in prepare() based on the output buffer format, dimensions, etc. Now we dequeue the output buffer at the beginning of the composition loop and provide it to HWC in prepare. In GLES-only rendering, we may have to cancel the buffer and acquire a new one if GLES requests a buffer with properties different than the one we already dequeued. Bug: 10365313 Change-Id: I96b4b0a851920e4334ef05080d58097d46467ab8
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
3c25621ad7d13f64d3ab95a27fa970fbc9998f73 |
|
16-Aug-2013 |
Andy McFadden <fadden@android.com> |
Re-enable frame dropping for non-auto timestamps This change adds an entire field to note whether the timestamp was auto-generated by Surface or supplied by the application. The value is used when deciding whether or not to drop frames based on buffer presentation timestamps. If a desired presentation time was set explicitly, BufferQueue will use that value to decide if a frame should be dropped. If the timestamp was generated by Surface at the time the buffer was queued, the timestamp is ignored. Bug 10151804 Change-Id: Ibd571a7578351063b813cbdad2ddbeed70655ba5
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
db89edc94bd2a78226b407f9f7261e202e7fa325 |
|
02-Aug-2013 |
Mathias Agopian <mathias@google.com> |
All consumers now take an IGraphicBufferConsumer instead of a BufferQueue 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
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
7cdd786fa80cf03551291ae8feca7b77583be1c5 |
|
19-Jul-2013 |
Mathias Agopian <mathias@google.com> |
Make ANW.setSwapInterval(0) work again we can now queue/dequeue a buffer in asynchrnous mode by using the async parameter to these calls. async mode is only specified with those calls (it is not modal anymore). as a consequence it can only be specified when the buffer count is not overidden, as error is returned otherwise. Change-Id: Ic63f4f96f671cb9d65c4cecbcc192615e09a8b6b
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
595264f1af12e25dce57d7c5b1d52ed86ac0d0c9 |
|
17-Jul-2013 |
Mathias Agopian <mathias@google.com> |
BufferQueue improvements and APIs changes this is the first step of a series of improvements to BufferQueue. A few things happen in this change: - setSynchronousMode() goes away as well as the SynchronousModeAllowed flag - BufferQueue now defaults to (what used to be) synchronous mode - a new "controlled by app" flag is passed when creating consumers and producers those flags are used to put the BufferQueue in a mode where it will never block if both flags are set. This is achieved by: - returning an error from dequeueBuffer() if it would block - making sure a buffer is always available by replacing the previous buffer with the new one in queueBuffer() (note: this is similar to what asynchrnous mode used to be) Note: in this change EGL's swap-interval 0 is broken; this will be fixed in another change. Change-Id: I691f9507d6e2e158287e3039f2a79a4d4434211d
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
bce7611e8e4514026bf12f96baaf9168f6d5894e |
|
16-Jul-2013 |
Jesse Hall <jessehall@google.com> |
Fix build -- update for function signature change Change-Id: I9c2448d5853c69ec7e962847fdaba9a99906cc42
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
38efe86d9459cf5c96a24a34cc5cbf31fdba7e19 |
|
07-Apr-2013 |
Jesse Hall <jessehall@google.com> |
Rewrite VirtualDisplaySurface The previous implementation assumed that the HWC could read and write the same buffer on frames that involved both GLES and HWC composition. It turns out some hardware can't do this. The new implementation maintains a scratch buffer pool to use on these mixed frames, but on GLES-only or HWC-only frames still does composition directly into the output buffer. Bug: 8384764 Change-Id: I7a3addb34fad9bfcbdabbb8b635083e10223df69
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
e737c11cd83a449d9a544c5c6d4e0dfd42250a56 |
|
07-May-2013 |
Jesse Hall <jessehall@google.com> |
Remove experimental HWC virtual display support Bug: 8384764 Change-Id: I97b52ed83ad85466bd91cb9291308994048568a1
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
2ba647e9f5249d9ed97739d29d879064e31ba34a |
|
04-Apr-2013 |
Jesse Hall <jessehall@google.com> |
Actually set the virtual display output buffer. Bug: 8316155 Change-Id: Ida1ac47e5a932fdaad3ec862e121cfe55d255699
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
ffe1f19ca9707f84cb9fdb06209bf36cd8c2ef0a |
|
22-Mar-2013 |
Jesse Hall <jessehall@google.com> |
Fix virtual displays for HWC<=1.1 If we're using a HWC that doesn't support virtual displays, or we have more virtual displays than HWC supports concurrently, the VirtualDisplaySurface should simply be a passthrough from source (GLES) to sink. This change also tries to distinguish between display types and HWC display IDs a little better, though there's more to do here. Probably needs a higher-level rethink; it's too error-prone now. Bug: 8446838 Change-Id: I708d2cf262ec30177042304f174ca5b8da701df1
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
851cfe834295224cd64bdd499872b95b19c4de8c |
|
20-Mar-2013 |
Jesse Hall <jessehall@google.com> |
Isolate knowledge that fb target == output buffer HWComposer didn't allow the virtual display output buffer to be set directly, instead it always used the framebuffer target buffer. DisplayDevice was only providing the framebuffer release fence to DisplaySurfaces after a commit. This change fixes both of these, so both HWComposer and DisplayDevice should continue to work if VirtualDisplaySurface changes to use separate framebuffer and output buffers. It's also more correct since VirtualDisplaySurface uses the correct release fence when queueing the buffer to the sink. Bug: 8384764 Change-Id: I95c71e8d4f67705e23f122259ec8dd5dbce70dcf
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
13f01cbdbd34779a234bc674df79e23672fd5c0b |
|
20-Mar-2013 |
Jesse Hall <jessehall@google.com> |
Pass sp<Fence>s around instead of file descriptors Change-Id: Iac70584a2207940730e8f803a543e4e9a4000c47
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
7414965606f82ac2bcace5d3e2c8a4810517bf1e |
|
20-Mar-2013 |
Jesse Hall <jessehall@google.com> |
Release virtual display buffer immediately after HWC set Previously we only queued a virtual display buffer to the sink when the next frame was about to be displayed. This may delay the "last" frame of an animation indefinitely. Now we queue the buffer as soon as HWC set() returns and gives us the release fence. Bug: 8384764 Change-Id: I3844a188e0f6ef6ff28f3e11477cfa063a924b1a
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
80e0a397a4712666661ecc629a64ec26e7f6aac3 |
|
15-Mar-2013 |
Jesse Hall <jessehall@google.com> |
Add BufferQueueInterposer and use it for virtual displays BufferQueueInterposer allows a client to tap into a IGraphicBufferProducer-based buffer queue, and modify buffers as they pass from producer to consumer. VirtualDisplaySurface uses this to layer HWC composition on top of GLES composition before passing the buffer to the virtual display consumer. Bug: 8384764 Change-Id: I61ae54f3d90de6a35f4f02bb5e64e7cc88e1cb83
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|
99c7dbb24994df2f3e175f7b25dd2c9dd92a72f0 |
|
14-Mar-2013 |
Jesse Hall <jessehall@google.com> |
Add DisplaySurface abstraction DisplayDevice now has a DisplaySurface instead of using FramebufferSurface directly. FramebufferSurface implements DisplaySurface, and so does the new VirtualDisplaySurface class. DisplayDevice now always has a surface, not just for virtual displays. In this change VirtualDisplaySurface is just a stub; buffers still go directly from GLES to the final consumer. Bug: 8384764 Change-Id: I57cb668edbc6c37bfebda90b9222d435bf589f37
/frameworks/native/services/surfaceflinger/DisplayHardware/VirtualDisplaySurface.cpp
|