[08:59] <duflu> alf_, alan_g : Should it be possible for a client with the default swap interval to submit frames that never make it to composition? That's what I'm seeing in our test framework. If the client starts too quickly then the test server never sees that frame.
[09:00] <duflu> ... which is a problem our acceptance tests don't cope with and they they measure latency wrong
[09:00] <duflu> they then
[09:01] <alf_> duflu: I don't think we should allow that
[09:01] <alf_> duflu: (I mean a frame never making it to composition)
[09:02] <duflu> alf_: yeah losing a frame and only seeing the second and subsequent ones is a problem. I'll have an acceptance test for it soon, but not a fix
[09:02] <coretex__> no frame left behind
[09:02] <duflu> Heh
[09:06] <alan_g> duflu: in a bit of synchronicity I've been puzzling over StaleFrames.are_dropped_when_restarting_compositor which seems to test for that behaviour.
[09:06] <duflu> alan_g: Sounds related, although mine is on startup
[09:07] <duflu> What is a stale frame?
[09:07] <duflu> I forget
[09:07] <alan_g> AFAICS so is the test (despite its name)
[09:07] <duflu> Dropping frames except in the confines of well-planned triple buffers with at least 2 frames ready is usually unsafe
[09:08] <duflu> Because you can drop the newest frame
[09:08] <duflu> With no guarantee anything comes after it
[09:21] <alf_> duflu: when restarting the compositor we want to show only the latest submitted frame, instead of all queued frames (don't forget that even when the compositor is off we allow clients to render at a low rate 10FPS or so). Older frames that we don't want to render, are called 'stale'.
[09:21] <duflu> alf_: Oh, yes. But I'm not restarting :)
[09:22] <alan_g> How is the "re" in restarting significant to that argument?
[09:22] <duflu> alf_: Do we delete stale frames even when there's only one? That would be a problem...
[09:22] <alan_g> By that definition the latest one can't be stale
[09:23] <duflu> Because it might be a slow or simply well-behaved client, and the latest frame could be from before it went to sleep. Not displaying that is a serious problem
[09:23] <duflu> alan_g: Fair point. But we could still mess it up infinite ways...
[09:26] <alf_> alan_g: in theory at least, we can't have a stale frames when first starting the server, since we start the compositor before the client connector
[09:26] <alf_> alan_g: but perhaps we are messing this somehow?
[09:27] <alan_g> alf_: Like I said, I was puzzled by this test at EOW. Maybe it will make sense today.
[09:28] <duflu> Sounds relevant. Maybe skipping a stale frame on start-up is right...
[09:29] <duflu> Gah, I read that backwards. Must be approaching EOD
[09:29]  * duflu continues with the test, regardless of what the bug or fix is...
[09:52] <zzarr> hello duflu :-)
[09:52] <duflu> zzarr: Hi
[09:53] <zzarr> I found a libGLESv2 for my mail 764 GPU, I haven't tested it yet (my package system got broke when installing ofono and urfkill)
[09:54] <zzarr> is there a way I can check if the lib I have is the one needed by Mir?
[10:12] <alan_g> alf_: are your concerns addressed? https://code.launchpad.net/~kdub/mir/refix-1517205/+merge/283861
[11:26] <anpok> vogons: I am thinking about moving MirClientConnection.. from graphics::nested .. to .. hum not sure yet
[11:27]  * alan_g wonders
[11:27] <anpok> *MirClientHostConnection
[11:27] <anpok> I need to forward input device events
[11:28] <anpok> register for changes .. in nested setup
[11:29] <anpok> it currently does graphicse and life cycle events.. so it alreday feels slightly misplaced
[11:29] <anpok> hm or I will just leave it there and wait for complains and suggestions..
[11:32]  * alan_g thinks "nested" is already more than graphics - and is unlikely to complain.
[11:32] <anpok> ah .. I mean it is inside graphics right now..
[11:32] <anpok> mir::nested would make more  sense to me
[11:32] <alan_g> I know that. ;)
[11:32] <anpok> and mir::nested::graphics for related stuff..
[11:32] <anpok> ok
[11:37] <alan_g> anpok: we should revisit nested, the platform ABI (and especially, if we really need create_guest_platform()) after NBS has solidified. It ought to be possible to do things a lot more cleanly.
[11:40] <anpok> aye.. i was close to implementing what I need as a platform.. but turned out that the input subsystem behaves quite different when nested..
[11:40] <anpok> it does not nees any of the interesting state tracking parts to begin with.
[11:40] <anpok> s/nees/need
[16:21] <alan_g> alf_: do you know what this failure is? https://code.launchpad.net/~alan-griffiths/mir/fix-1535894-alt/+merge/285223/comments/725800
[16:22] <alf_> alan_g: yeah, just mentioned that in #mir
[16:22] <alf_> alan_g: it seems to be a package problem
[16:22] <alf_> alan_g: in libuuid1
[16:23] <alan_g> I suspected that, or a the test system configured "incorrectly"
[16:24] <alf_> alan_g: I will try to work around that by updating the chroot (so that we don't need to upgrade the package for each package build). Not sure it will help but let's see...
[16:27] <alan_g> alf_: thanks. (I was mostly concerned that nothing you'd done was causing unexpected failure.)
[16:32] <alf_> alan_g: hmm, not working, same error
=== alan_g is now known as alan_g|EOD