<div dir="ltr">I don't have another theory. I would think its the extra "free" buffer especially with insanely high fps rates.<div>can we get some mobile device based numbers as well ? <div>br, kg</div></div> </div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Dec 18, 2013 at 3:07 AM, Daniel van Vugt <<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll work on getting numbers. In the mean time, any other theories on why nesting is sometimes faster? I think the first logical step is to assume nesting shouldn't be faster. But instead non-nested is being throttled somehow, like already described.<div class="HOEnZb"><div class="h5"> On 18/12/13 17:04, Thomas Voß wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, Dec 18, 2013 at 10:01 AM, Daniel van Vugt <<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote> Fair, but I would like to see numbers on the roundtrip penalty you are suspecting here, first :) Cheers, Thomas <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 18/12/13 16:58, Thomas Voß wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wed, Dec 18, 2013 at 9:43 AM, Daniel van Vugt <<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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: <a href="https://bugs.launchpad.net/mir/+bug/1253868" target="_blank">https://bugs.launchpad.net/mir/+bug/1253868</a> and nesting provides a workaround for that problem by supplying extra levels of buffering. </blockquote> 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 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Can anyone else think why nested would sometimes be faster than not nested? - Daniel -- Mir-devel mailing list <a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a> </blockquote></blockquote></blockquote></blockquote> -- Mir-devel mailing list <a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a> </div></div></blockquote></div> </div>