Nested servers frame rate

Daniel van Vugt daniel.van.vugt at
Wed Dec 18 09:01:49 UTC 2013

The issue is in your response: "almost immediately" :)

At present, "almost immediately" means waiting for a round trip. Whereas 
we can do better than that in theory, by pushing free buffers to the 
client as soon as they're available.

On 18/12/13 16:58, Thomas Voß wrote:
> On Wed, Dec 18, 2013 at 9:43 AM, Daniel van Vugt
> <daniel.van.vugt at> wrote:
>> At first glance, comparing frame rates between direct (single) and nested
>> (double) server configurations reveals nothing unexpected...
>> Full screen
>> Direct (bypass) 2600
>> Direct (bypass off) 2400
>> Nested (bypass) 2450
>> Nested (bypass off) 2330
>> But for surfaces which can't be bypassed, something strange happens; nesting
>> is faster!
>> Windowed
>> Nested 4890
>> Direct 4400
>> My best theory right now is that we're crippling Mir in the single server
>> case due to:
>> and nesting provides a workaround for that problem by supplying extra levels
>> of buffering.
> Not sure I'm following your reasoning here: The bug states exactly the
> opposite, i.e., additional buffering wouldn't help.
> In addition: I do not see how a steady-state update scheme on the
> client-side is a problem here. If there are more than two buffers
> available per surface, the client almost immediately receives a new
> buffer when it calls next_buffer. Sure, there is always only one
> buffer in flight, but I cannot see why this would lead to the numbers
> you are reporting here.
> Cheers,
>    Thomas
>> Can anyone else think why nested would sometimes be faster than not nested?
>> - Daniel
>> --
>> Mir-devel mailing list
>> Mir-devel at
>> Modify settings or unsubscribe at:

More information about the Mir-devel mailing list