Nested servers frame rate

[Daniel van Vugt]

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 canonical.com> 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:
>> https://bugs.launchpad.net/mir/+bug/1253868
>> 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 lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/mir-devel