| racarr_ | https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/536/console | 01:36 |
|---|---|---|
| racarr_ | omg... | 01:36 |
| racarr_ | :( | 01:36 |
| racarr_ | is CI completely destroyed or am I just having the worst luck ever on this branch | 01:37 |
| RAOF | racarr_: Heh. | 01:57 |
| === 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 | ||
| RAOF | Erm, what? | 07:02 |
| RAOF | We seem to call MirSurface::create_wait_handle.result_received(), but we never call MirSurface::create_wait_handle.expect_result()? | 07:03 |
| RAOF | How does that not make mir_wait_for() a no-op? | 07:06 |
| === tsdgeos_ is now known as tsdgeos | ||
| RAOF | Ah, ok. So the answer is: it *is* a no-op. | 08:05 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alan_g | alf_: today it's "mir-android-utopic-i386" - https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/ | 11:13 |
| * alf_ sighs | 11:15 | |
| alf_ | alan_g: I will ask in the CI channel, perhaps the can recreate the chroot tarball | 11:15 |
| alan_g | alf_: fginther is already on it | 11:16 |
| alf_ | alan_g: great then | 11:16 |
| === 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 | ||
| alf_ | alan_g: anpok: Thoughts on the name for "Scene::inform_about_rendering_for(CompositorID, RenderableList const& rendered, RenderableList const& not_rendered);" | 12:59 |
| alan_g | alf_: I don't know what it means => it is bad | 13:00 |
| alf_ | alan_g: I wan't to let the scene know which renderables a compositor rendered and which it didn't | 13:01 |
| === dandrader|afk is now known as dandrader | ||
| anpok | then use rendered instead | 13:04 |
| anpok | renderered_renderables :) | 13:04 |
| anpok | or rendered_elements -typos | 13:05 |
| 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:06 |
| alan_g | Can't the compositor just tag the list items "rendered"? | 13:07 |
| alan_g | Or partition the list? | 13:07 |
| 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:10 |
| 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:11 |
| 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:12 |
| anpok | oh so also the difference between this and last round of drawing | 13:13 |
| 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:14 |
| 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:16 |
| 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:17 |
| anpok | but it needs to be that way .. or the scene does more | 13:18 |
| === dandrader is now known as dandrader|afk | ||
| 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:18 |
| 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:19 |
| 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:22 |
| 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:23 |
| 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:25 |
| alf_ | alan_g: I am not sure what you mean with the last comment | 13:26 |
| alan_g | Hmm. maybe I'm overcomplicating | 13:27 |
| 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:31 |
| 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:32 |
| 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:33 |
| anpok | but scene needs to track all compositions that happen in parallel and with a different rate.. | 13:34 |
| === dandrader|afk is now known as dandrader | ||
| alf_ | alan_g: anpok: We also need to know when it's being re-rendered after being occluded, to send an "exposed" event. | 13:35 |
| alf_ | alan_g: anpok: that's step (3) above | 13:36 |
| anpok | why do we use something like a renderablelist at all? | 13:36 |
| alan_g | alf_: understood. I'm trying to understand how the updates are generated from the information provided. | 13:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| anpok | do we have to differ between occluded not offered to any compositor? | 13:42 |
| 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:43 |
| 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:44 |
| alan_g | We can represent "occluded in compositor X" by an attribute on the thing or as inclusion in a collection. | 13:46 |
| anpok | the thing is the buffer inside the renderable list or the surface inside the scene | 13:48 |
| anpok | +? | 13:48 |
| 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:49 |
| alan_g | thing->occluded_in(this); | 13:50 |
| anpok | and the opposite | 13:51 |
| anpok | and you need to find a point in time when you evaluate the information per thing | 13:51 |
| alan_g | the point is time is when thing gets any messages adding/removing compositors or adding/removing occlusions. | 13:53 |
| 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:54 |
| anpok | *stopped | 13:55 |
| 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:58 |
| 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); | 13:59 |
| === alan_g is now known as alan_g|tea | ||
| alf_ | alan_g|tea: anpok: Thanks! I will think through the details of both approaches (centralized vs distributed logic) and decide. | 14:11 |
| === alan_g|tea is now known as alan_g | ||
| alf_ | fginther: Hi! Any update on the corrupted chroot tarball? | 14:26 |
| === dandrader is now known as dandrader|afk | ||
| anpok | AlbertA: with the current image the keyboard popups seem to be opaque | 15:18 |
| anpok | hm no we did not cause that | 15:19 |
| AlbertA | anpok: right | 15:20 |
| AlbertA | anpok: they are working around it: https://bugs.launchpad.net/mir/+bug/1328952 | 15:20 |
| ubot5 | Ubuntu bug 1328952 in Mir "Compositing with invisible surfaces" [High,Fix committed] | 15:20 |
| AlbertA | anpok: until the alpha fix lands officially in archive | 15:20 |
| alan_g | alf_: fginther we have some CI successes at last!!! | 15:21 |
| anpok | ah ok | 15:24 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!