[01:36] <racarr_> https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/536/console
[01:36] <racarr_> omg...
[01:36] <racarr_> :(
[01:37] <racarr_> is CI completely destroyed or am I just having the worst luck ever on this branch
[01:57] <RAOF> racarr_: Heh.
[07:02] <RAOF> Erm, what?
[07:03] <RAOF> We seem to call MirSurface::create_wait_handle.result_received(), but we never call MirSurface::create_wait_handle.expect_result()?
[07:06] <RAOF> How does that not make mir_wait_for() a no-op?
[08:05] <RAOF> Ah, ok. So the answer is: it *is* a no-op.
[11:13] <alan_g> alf_: today it's "mir-android-utopic-i386" - https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/
[11:15]  * alf_ sighs
[11:15] <alf_> alan_g: I will ask in the CI channel, perhaps the can recreate the chroot tarball
[11:16] <alan_g> alf_: fginther is already on it
[11:16] <alf_> alan_g: great then
[12:59] <alf_> alan_g: anpok: Thoughts on the name for "Scene::inform_about_rendering_for(CompositorID, RenderableList const& rendered, RenderableList const& not_rendered);"
[13:00] <alan_g> alf_: I don't know what it means => it is bad
[13:01] <alf_> alan_g: I wan't to let the scene know which renderables a compositor rendered and which it didn't
[13:04] <anpok> then use rendered instead
[13:04] <anpok> renderered_renderables :)
[13:05] <anpok> or rendered_elements -typos
[13:06] <alan_g> alf_: what's the sequence these days?...
[13:06] <alan_g> 1, The scene gives the compositor a list?
[13:06] <alan_g> 1.1. The compositor gives the scene two lists?
[13:07] <alan_g> Can't the compositor just tag the list items "rendered"?
[13:07] <alan_g> Or partition the list?
[13:10] <alan_g> Does the scene even need to know what *wasn't* rendered?
[13:10] <anpok> it only needs to know what wasnt rendered at all in any compositor
[13:10] <anpok> so one list could be enough
[13:11] <anpok> so the scene now gets an explicit - i am done with rendering, and that is what I did call from each compositor (hopefully)
[13:12] <alan_g> Isn't it simpler for each element in the scene to know when it was last rendered
[13:12] <alf_> alan_g: anpok: It needs to know somehow (compositor tells it, or it tries to figure out by itself Rendered = All - NotRendered) what was rendered too, since we need to send both occlusion and exposure events.
[13:13] <anpok> oh so also the difference between this and last round of drawing
[13:14] <anpok> hm what if we have compositors that drive outputs that are side by side.. and that compositor has half the framerate of the other
[13:14] <anpok> *two
[13:16] <anpok> ahh nm, you can figure that out through the compositor id
[13:16] <alf_> anpok: the idea is that the scene knows about all the compositor ids. If all compositors say that we haven't rendered this surface then it is marked as occluded
[13:16] <anpok> but you have to wait untill you receive results from all
[13:16] <anpok> and take the most recent maybe..
[13:17] <anpok> then you also need to know that a compositor is turned off
[13:17] <alf_> anpok: but in any case, I am not concerned with the multi-monitor case right now, I am focusing on the single screen case
[13:17] <anpok> .. ok I just thought the interface is too complex..
[13:18] <anpok> but it needs to be that way .. or the scene does more
[13:18] <alf_> anpok: you mean passing both rendered and not_rendered?
[13:18] <alan_g> We don't want to change everything as soon as there's multiple renderers
[13:19] <alf_> alan_g: we won't
[13:19] <anpok> alf_: well there is a reason for each parameter..
[13:19] <alan_g> then we have to understand cases like multiple renders with overlapping contents
[13:22] <anpok> alf_: it feels like a start rendering / done rendering call required by the compositors
[13:22] <anpok> is rendereable_list_for only called once per frame per compositor
[13:22] <alan_g> AFAICS "occlusion" == we have to drop a frame because none of the renderers have drawn recently
[13:22] <anpok> *calls
[13:23] <alf_> alan_g: We (at least I) think we understand them. I am focusing on the simple case in the implementation side not the API side.
[13:25] <alan_g> alf_: so for each buffer the scene tracks if each compositor was offered it and if it was then rendered?
[13:25] <alf_> alan_g: I tried the FrameDroppingPolicy approach, but it has problems.
[13:26] <alf_> alan_g: I am not sure what you mean with the last comment
[13:27] <alan_g> Hmm. maybe I'm overcomplicating
[13:31] <alan_g> Each "thing in the scene that can be rendered"  needs to know whether all compositors offered the opportunity to render it on their last opportunity declined to do so?
[13:32] <alf_> alan_g: anpok: The current idea is: 1. Each compositor somehow informs the scene (or some other object) which renderables it rendered and which not 2. When a renderable hasn't been marked as not rendered by all compositors, it is considered "occluded" and the client is notified 3. When a renderable is marked as rendered by any compositor it is considered "exposed"
[13:33] <anpok> alan_g: not sure if it needs to know that it was offered - because if it wasnt offered for other reasons (and thus not rendered) it has to treated like occluded. so not rendered should be enough.
[13:34] <anpok> but scene needs to track all compositions that happen in parallel and with a different rate..
[13:35] <alf_> alan_g: anpok: We also need to know when it's being re-rendered after being occluded, to send an "exposed" event.
[13:36] <alf_> alan_g: anpok: that's step (3) above
[13:36] <anpok> why do we use something like a renderablelist at all?
[13:37] <alan_g> alf_: understood. I'm trying to understand how the updates are generated from the information provided.
[13:38] <alf_> alan_g: oops (2) should be, "When a renderable hasn't been marked as not rendered by all compositors, it is considered "occluded" and the client is notified"
[13:39] <alf_> alan_g: double oops, should be, "(2) When a renderable *has* been marked as not rendered by all compositors, it is considered "occluded" and ...
[13:41] <alan_g> when a When a renderable has been marked as "occluded" by *all* compositors then it is considered "occluded". "All" being the compositors to which it was offered.
[13:41] <alf_> alan_g: right
[13:42] <anpok> do we have to differ between occluded not offered to any compositor?
[13:43] <anpok> do we have to differ between occluded *and* not offered to any compositor?
[13:43] <alan_g> Not offered to any makes "all" trivially satisfied
[13:44] <anpok> sure, just since you mentioned it, i wondered if in that case a different event is expected to be sent to the client - but I do not see a reason to do so.
[13:46] <alan_g> We can represent "occluded in compositor X" by an attribute on the thing or as inclusion in a collection.
[13:48] <anpok> the thing is the buffer inside the renderable list or the surface inside the scene
[13:48] <anpok> +?
[13:49] <alan_g> Yes, the "thing in the scene that can be rendered"
[13:49] <anpok> alf_: wrt naming, some proposals: compositon_result_for(id, rendered, not_rendered), submit_rendering_result_for(id..) )
[13:50] <alan_g> thing->occluded_in(this);
[13:51] <anpok> and the opposite
[13:51] <anpok> and you need to find a point in time when you evaluate the information per thing
[13:53] <alan_g> the point is time is when thing gets any messages adding/removing compositors or adding/removing occlusions.
[13:54] <alan_g> Or, using lists: Scene::rendering_result_for(this, RenderableList const& rendered, RenderableList const& occluded);
[13:54] <anpok> ah so removal of compositors is like occluded_in(stopp_compositor)
[13:55] <anpok> *stopped
[13:58] <anpok> alan_g: hm it only needs to store the "rendered by compositor x" information, which is removed on compositor removal, and occlusion, and added on rendering..
[13:58] <alf_> alan_g: anpok: right, so we can either make "thing" smarter (with the caveat that it needs to have more context), or we manage the logic centrally...
[13:58] <anpok> otherwise you would never loose occulded informations for removed compositors
[13:58] <anpok> *lose
[13:59] <alan_g> OK, I'm getting caught by another discussion. But to answer the original question...
[13:59] <alan_g> Scene::rendering_result_for(this, rendered, occluded);
[14:11] <alf_> alan_g|tea: anpok: Thanks! I will think through the details of both approaches (centralized vs distributed logic) and decide.
[14:26] <alf_> fginther: Hi! Any update on the corrupted chroot tarball?
[15:18] <anpok> AlbertA: with the current image the keyboard popups seem to be opaque
[15:19] <anpok> hm no we did not cause that
[15:20] <AlbertA> anpok: right
[15:20] <AlbertA> anpok: they are working around it: https://bugs.launchpad.net/mir/+bug/1328952
[15:20] <AlbertA> anpok: until the alpha fix lands officially in archive
[15:21] <alan_g> alf_: fginther we have some CI successes at last!!!
[15:24] <anpok> ah ok