[01:36] https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/536/console [01:36] omg... [01:36] :( [01:37] is CI completely destroyed or am I just having the worst luck ever on this branch [01:57] racarr_: Heh. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:02] Erm, what? [07:03] We seem to call MirSurface::create_wait_handle.result_received(), but we never call MirSurface::create_wait_handle.expect_result()? [07:06] How does that not make mir_wait_for() a no-op? === tsdgeos_ is now known as tsdgeos [08:05] Ah, ok. So the answer is: it *is* a no-op. === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [11:13] 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] alan_g: I will ask in the CI channel, perhaps the can recreate the chroot tarball [11:16] alf_: fginther is already on it [11:16] alan_g: great then === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g|lunch is now known as alan_g === dandrader is now known as dandrader|afk [12:59] alan_g: anpok: Thoughts on the name for "Scene::inform_about_rendering_for(CompositorID, RenderableList const& rendered, RenderableList const& not_rendered);" [13:00] alf_: I don't know what it means => it is bad [13:01] alan_g: I wan't to let the scene know which renderables a compositor rendered and which it didn't === dandrader|afk is now known as dandrader [13:04] then use rendered instead [13:04] renderered_renderables :) [13:05] or rendered_elements -typos [13:06] alf_: what's the sequence these days?... [13:06] 1, The scene gives the compositor a list? [13:06] 1.1. The compositor gives the scene two lists? [13:07] Can't the compositor just tag the list items "rendered"? [13:07] Or partition the list? [13:10] Does the scene even need to know what *wasn't* rendered? [13:10] it only needs to know what wasnt rendered at all in any compositor [13:10] so one list could be enough [13:11] 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] Isn't it simpler for each element in the scene to know when it was last rendered [13:12] 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] oh so also the difference between this and last round of drawing [13:14] 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] *two [13:16] ahh nm, you can figure that out through the compositor id [13:16] 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] but you have to wait untill you receive results from all [13:16] and take the most recent maybe.. [13:17] then you also need to know that a compositor is turned off [13:17] 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] .. ok I just thought the interface is too complex.. [13:18] but it needs to be that way .. or the scene does more === dandrader is now known as dandrader|afk [13:18] anpok: you mean passing both rendered and not_rendered? [13:18] We don't want to change everything as soon as there's multiple renderers [13:19] alan_g: we won't [13:19] alf_: well there is a reason for each parameter.. [13:19] then we have to understand cases like multiple renders with overlapping contents [13:22] alf_: it feels like a start rendering / done rendering call required by the compositors [13:22] is rendereable_list_for only called once per frame per compositor [13:22] AFAICS "occlusion" == we have to drop a frame because none of the renderers have drawn recently [13:22] *calls [13:23] 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] alf_: so for each buffer the scene tracks if each compositor was offered it and if it was then rendered? [13:25] alan_g: I tried the FrameDroppingPolicy approach, but it has problems. [13:26] alan_g: I am not sure what you mean with the last comment [13:27] Hmm. maybe I'm overcomplicating [13:31] 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] 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] 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] but scene needs to track all compositions that happen in parallel and with a different rate.. === dandrader|afk is now known as dandrader [13:35] alan_g: anpok: We also need to know when it's being re-rendered after being occluded, to send an "exposed" event. [13:36] alan_g: anpok: that's step (3) above [13:36] why do we use something like a renderablelist at all? [13:37] alf_: understood. I'm trying to understand how the updates are generated from the information provided. [13:38] 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] 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] 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] alan_g: right [13:42] do we have to differ between occluded not offered to any compositor? [13:43] do we have to differ between occluded *and* not offered to any compositor? [13:43] Not offered to any makes "all" trivially satisfied [13:44] 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] We can represent "occluded in compositor X" by an attribute on the thing or as inclusion in a collection. [13:48] the thing is the buffer inside the renderable list or the surface inside the scene [13:48] +? [13:49] Yes, the "thing in the scene that can be rendered" [13:49] alf_: wrt naming, some proposals: compositon_result_for(id, rendered, not_rendered), submit_rendering_result_for(id..) ) [13:50] thing->occluded_in(this); [13:51] and the opposite [13:51] and you need to find a point in time when you evaluate the information per thing [13:53] the point is time is when thing gets any messages adding/removing compositors or adding/removing occlusions. [13:54] Or, using lists: Scene::rendering_result_for(this, RenderableList const& rendered, RenderableList const& occluded); [13:54] ah so removal of compositors is like occluded_in(stopp_compositor) [13:55] *stopped [13:58] 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] 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] otherwise you would never loose occulded informations for removed compositors [13:58] *lose [13:59] OK, I'm getting caught by another discussion. But to answer the original question... [13:59] Scene::rendering_result_for(this, rendered, occluded); === alan_g is now known as alan_g|tea [14:11] alan_g|tea: anpok: Thanks! I will think through the details of both approaches (centralized vs distributed logic) and decide. === alan_g|tea is now known as alan_g [14:26] fginther: Hi! Any update on the corrupted chroot tarball? === dandrader is now known as dandrader|afk [15:18] AlbertA: with the current image the keyboard popups seem to be opaque [15:19] hm no we did not cause that [15:20] anpok: right [15:20] anpok: they are working around it: https://bugs.launchpad.net/mir/+bug/1328952 [15:20] Ubuntu bug 1328952 in Mir "Compositing with invisible surfaces" [High,Fix committed] [15:20] anpok: until the alpha fix lands officially in archive [15:21] alf_: fginther we have some CI successes at last!!! [15:24] ah ok === alan_g is now known as alan_g|EOW === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk