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