User1: Ok. That's enough thinking about WaitHandles and the madness of force_completion(). Let's instead think about looking up surface coordinates!
User2: Ironically I only started thinking about WaitHandles 30 seconds ago
User2: Still agree though
User1: If it wasn't a huge slog thorough the code I'm *pretty* sure we could just do with invoke ids.
User2: User1 Oh and vmware is thinking about WaitHandles right now too :)   https://bugs.launchpad.net/mir/+bug/1370386
User3: Launchpad bug 1370386 in mir (Ubuntu) "libmirclient7 hang on client startup" [Undecided,New]
User1: Heh.
 * duflu is frustrated (and happy) to see that the current input sampling algorithm apparently cannot be beaten
User2: Despite trying to improve on it for 2 days now
User2: It's a little suspicious though that I can see fingerpaint (which does rendering in software) is much more responsive in a nested server than Unity8 (which is meant to be rendered by hardware)
User2: The software rendering handicap on a phone should be large
User4: User2 you access rgb pixels directly and only those that change due to the finger movement
User4: thats slightly different to dispatching user input through a qml scene
User1: Also, Unity8 /is/ a nested server.
User2: User1 Yes, meaning there's /less/ indirection for Unity8 :)
User4: i would assume fingers paints memory bandwith usage is also below the command submission part of a gles driver redrawing an client application
User4: -"s "
User2: User4 fingerpaint still flips (copies) the whole surface
User4: oh
User2: memcpy
User2: FTW
User1: User2 What? No, there's exactly the same indirection - usc â nested server â fingerpaint vs usc â unity8 â fingerpaint?
User2: User4 The only way to avoid it is to implement a single buffering option
User4: ok i thought we had that by accident with software buffers
User1: Or damage.
User2: User1 USC(Unity8(app))  vs  server_minimal(server_shell(fingerpaint))
User4: that would be so 2010
User2: hence Unity8 is closer to the metal
User4: User2 but you mostly interact with unity8-dash.
User4: or depends on what you look
User2: User4 Ah, yes. So the dash has no advantage.
User1: fingerpaint could avoid flipping memcpying the whole surface *right now* pretty easily.
User2: User1 age?
User1: Yes.
User2: User1 I'm intrigued if it's easy. Can you demo such a proposal?
User1: The Mir side will also handle it better when we add damage support to swap_buffers.
User4: can mesa track damage internally?
User1: Technically? Probably.
User4: and s/can/does?
User4: or would we provide another client api to submit damage with the next buffer switch?
User2: User1 Oh actually, please don't. I think I want to add support for multiple touch samples per frame first (demo client-side resampling as an option)
User1: User4 Does not, would probably be an arse to implement.
User2: Quad-tree madness? :)
User1: eglSwapBuffersWithDamageEXT is the relevant entry point for most clients :)
User4: ah ok
User1: We'd need support in libmirclient for that to actually translate into anything useful, obviously.
User1: And mesa *does* support SwapBuffersWithDamage
User5: where can I find mir logs on the phone?
User5: kgunn_: kdub_ racarr ^
User6: robotfuel, like in unity8 or usc?
User6: or running some of the standalone things
User5: I have a qml app pegging the cpu and the ui is stuck
User6: robotfuel, /var/log/lightdm/unity-system-compositor.log for USC and /home/phablet/.cache/upstart/unity8.log for unity8
User5: User6  it is the warning in the USC log normal? http://pastebin.ubuntu.com/8367234/
User6: robotfuel, those look normal to me
User7: seems normal yeah
ubuntu-mir
Ubuntu IRC