On 09/07/14 16:39, Kevin Gunn wrote: > First > Not sure we're still on topic necessarily wrt changing from id's to fd's > do we need to conflate that with the double/triple buffering topic ? > let's answer this first... > > Second > while we're at it :) triple buffering isn't always a win. In the case of > small, frequent renders (as an example "8x8 pixel square follow my finger") > you'll have potentially 2 extra buffers that need their 16ms of fame on the > screen in the queue, 1 at session server, 1 at system server. Which can > look a little laggy. I'm willing to say in the same breath though, that > this may be lunatic fringe. The win for the triple buffering case is likely > more common, which is spikey render times (14+ms) amongst more normal > render times (9-12ms) > +1 on giving empty buffers back to the clients to allow them to have a > "queue" of empty buffers at their disposal (i'm not sure if RAOF is correct > or duflu in that its "synchronously waiting for a round trip every swap"...can > we already have an empty buffer queue on the client side ?)
I also want to remind everyone that our default shipping configuration is a root mir server with a nested mir server as a client, and that nested mir server manages most client apps the user will be interacting with. Nesting will increase input latency, as now there's not just 3 buffers in play, but more (5 yeah?). I had thought that the double-buffering idea was to try reduce the number of buffers being used in the nested case. Sounds like Daniel isn't confident that'll work now, which is a pity. Thanks -G
signature.asc
Description: OpenPGP digital signature
-- Mir-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
