Confirmed users
138
edits
Platform/GFX/Surfaces: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 272: | Line 272: | ||
If the surfaces are being allocated from a "surface pool", then they aren't returned to the pool as long as anything holds a reference to them. Thus, e.g. a "screenshotting" consumer can hold screenshots alive as long as it wants without blocking the swap chain --- as long as the surface pool doesn't run out. | If the surfaces are being allocated from a "surface pool", then they aren't returned to the pool as long as anything holds a reference to them. Thus, e.g. a "screenshotting" consumer can hold screenshots alive as long as it wants without blocking the swap chain --- as long as the surface pool doesn't run out. | ||
Another complicated use case to take into account is that Gecko's media framework does not use the notion of swap chain. Media produces frames that are, if possible, already in shared memory, and present the same frames (so the same underlying MozSurfaces) to several swap chains, without any form of restriction: MozSurfaces can be passed to any number of swap chains in any order, maybe at the same time, maybe not. | |||
*** Figure 6. JeffG and Dan's magic swap chain that allows *** | |||
*** a frame to be in multiple swap chains *** | |||
Producer on | |||
content process | |||
| | |||
| draws into | |||
V | |||
+---------+ | |||
| frame N | | |||
+---------+ | |||
| \ | |||
| \ | |||
| \ | |||
| \ | |||
V V | |||
The swap chain Another Swap chain | |||
+---------------+ +---------------+ | |||
| | | | | |||
| +-----------+ | | +-----------+ | | |||
| | frame N-1 | | | | frame N-1 | | | |||
| +-----------+ | | +-----------+ | | |||
| | | | | |||
| | | | | | | |||
+-------|-------+ +-------|-------+ | |||
| V | | V | | |||
| | | | | |||
| +-----------+ | | +-----------+ | | |||
| | frame N-2 | | | | frame N-2 | | | |||
| +-----------+ | | +-----------+ | | |||
| | | | | |||
+---------------+ +---------------+ | |||
getFrontFrame() is / \ \ | |||
about to pull / \ \ | |||
frame N-2 from / \ \ | |||
the swap chain / \ \ | |||
/ \ \ | |||
V V V | |||
Consumer #1 on Consumer #2 Consumer #3 | |||
compositor process on another process | |||
gets a reference might also get a reference | |||
to frame N-2 to frame N-2; | |||
might also still hold | |||
references to older frames... | |||
Note that Video compositing is a bit particular because we want to queue frames on the compositor side with timestamps, so that AV synchronization can be done at presentation time. Currently AV sync is done on the content side and the compositor just consumes the last frame that was shared over IPC, so we suffer from the latency that comes with IPC. | |||
In the figure below, we use the generic term "stream" rather than swap chain because the implementation of the stream may not require all the features of the swap chains described above, and already differs by the need to queue frames in advance on the compositor side with presentation times. | |||
*** Figure 7. Video compositing with timestamped frames *** | |||
Producer | |||
| | |||
V | |||
+-----------+ | |||
| frame N+1 | | |||
+-----------+ | |||
/ \ | |||
/ \ The frame is put into several | |||
/ \ streams with different presentation | |||
/ \ times. | |||
V V | |||
Stream 1 Stream2 | |||
+------------------+ +------------------+ | |||
| +--------------+ | +-----------+ | +--------------+ | | |||
| | timestamp T1 |-+--->| Frame N |<--+-| timestamp T3 | | | |||
| +--------------+ | +-----------+ | +--------------+ | | |||
| | | | | |||
| +--------------+ | +-----------+ | +--------------+ | | |||
| | timestamp T1 |-+--->| Frame N-1 |<--+-| timestamp T3 | | | |||
| +--------------+ | +-----------+ | +--------------+ | | |||
| | | | | |||
| +--------------+ | +-----------+ | | | |||
| | timestamp T1 |-+--->| Frame N-2 | | | | |||
| +--------------+ | +-----------+ | | | |||
| | | | | |||
+------------------+ +------------------+ | |||