Requirements for replacing Mir BufferQueue

	A	B	C
1	Needs and wants, for future work aimed at replacing Mir's BufferQueue.
2
3	Title	Description	Mir/BufferQueue has this already?
4	Swap interval 1	Simple clients are throttled to the compositor/display refresh rate by default.	Yes
5	Swap interval 0	Clients that request frame dropping are not throttled, and can produce new frames as fast as they can render.	Yes
6	Drop safely	When frame dropping is enabled (swap interval 0), the newest buffer produced by the client is never dropped. Because you never know if or when the client will produce another frame to replace it. Dropping the newest buffer results in freezes, or in the best case stuttering.	Yes
7	Drop efficiently	Frame dropping should occur primarily within the client process so as to not flood the server with extraneous messages that will slow it down. This also maximizes the client frame rate as it doesn't have to wait for RPC on each frame.	No
8	Bypass/overlays	The compositor is allowed to hold two buffers of a surface simultaneously without starving the client from rendering to a third buffer in preparation.	Yes
9	Multi-monitor frame sync	The compositor can feed multiple displays at different refresh rates and/or different phases, only consuming buffers from clients at the rate of the fastest display. Slower and/or secondary displays get the same buffer already visible on the first one. Multi-monitor frame sync has the same kind of compositor-holds-two-different-buffers requirement as bypass/overlays.	Yes
10	Dynamic double buffering	Fast clients only ever see two buffers (so long as they remain fast enough to keep up), in order to keep queue latency limited to one frame.	Yes
11	Minimal buffer allocation	Only the number of buffers really needed is allocated.	Partially implemented somewhat by accident. Slow clients (e.g. 1Hz) only ever see one buffer ID but start with 2-3 buffers allocated so are wasting memory right now.
12	Frame notification	Clients can wait for notification of physical frames output so that they can synchronize with the compositor and never get ahead of it (seen as lag). If paired with swap interval 0 this can be used to eliminate the nested server latency penalty. Such a notification would also help us to achieve the optimal input resampling rate.	No
13	No unwanted wakeups	Clients that are idle (i.e. maybe waiting for input but not waiting in swap buffers) never get woken up by any messages from the server that they don't care about. This means only input/resizing messages wake the client but there is no frame notification unless the client is in swap buffers already. Minimizing wakeups is key to efficient power management.	Yes?
14	Clients just work	Mir apps don't need any modification to work in the new architecture. As far as any app is concerned, it just calls swap buffers exactly as before.	Yes
15	Nested bypass	A client buffer under a nested server can be bypassed/overlayed on the physical display (system compositor) so as to avoid all GL rendering/compositing. For maximum speed and efficiency when it's safe to do so.	No
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100