| mterry | duflu_, heyo! | 03:14 |
|---|---|---|
| duflu_ | mterry! sup? | 03:14 |
| === duflu_ is now known as duflu | ||
| mterry | duflu_, so maybe I don't understand C++ well enough, but the code in ./include/server/mir/compositor/scene.h doesn't seem to give access to CompositingCriteria... | 03:15 |
| duflu | mterry: It's a bit ugly, but all designed to work with a filter/applicator interface. I think all those are defined in scene.h? | 03:16 |
| * duflu checks | 03:16 | |
| mterry | duflu, it looks like they *take* a criteria, not give one | 03:17 |
| duflu | mterry: All you need is a Scene object. Then... scene->for_each_if(filter, operator) to do your rendering. The instances will be provided by the underlying scene implementation in Mir | 03:18 |
| duflu | That's a bit of an ugly way to iterate though. I'd like to replace it with something else | 03:19 |
| duflu | You will need to create implementations of FilterForScene and OperatorForScene :P | 03:19 |
| mterry | duflu, oh I see. I write a filter, and the for_each_if will call operator() giving a criteria | 03:19 |
| duflu | mterry: Yep. The instances implementing those interfaces are hidden, but you will get called with them | 03:20 |
| mterry | duflu, then I also need to get a Rectangle for the surface to pass the criteria... | 03:20 |
| mterry | this is really roundabout | 03:20 |
| duflu | mterry: Your display_buffer->view_area() is good for that | 03:21 |
| mterry | ah ok | 03:21 |
| duflu | mterry: I know. I found it this way :) | 03:21 |
| duflu | "It was like that when I found it" | 03:21 |
| mterry | duflu, :) | 03:21 |
| duflu | mterry: So a minimal filter would call should_be_rendered_in | 03:22 |
| mterry | duflu, so my Filters get called... But how do I match a filter call to a given surface? | 03:22 |
| duflu | mterry: You can't right now. We all want that fixed up and I think kdub is most likely to do it soonest | 03:23 |
| * mterry is trying to imagine how I use these pieces together | 03:23 | |
| duflu | mterry: Our immediate desire is to replace both the CompositingCriteria and BufferStream parameters with some *Surface interface which implements both. We just need to restructure the Surface class hierarchy | 03:25 |
| mterry | Whoops, disconnected. duflu, don't know where we stopped | 03:30 |
| mterry | <mterry> duflu, yeah, so I can iterate and ask the criteria, but without being able to differentiate between what the various iterate calls *mean* (i.e. what surfaces they match), I don't know how that API is useful to a 3rd party | 03:30 |
| duflu | mterry: You missed nothing | 03:30 |
| mterry | hmm | 03:30 |
| mterry | maybe I'm missing a piece of the puzzle | 03:31 |
| mterry | I guess the Operator sees a BufferStream.. | 03:31 |
| mterry | But that's not super informative | 03:31 |
| mterry | duflu, cool | 03:31 |
| mterry | duflu, so kdub is working in this space? | 03:31 |
| duflu | mterry: Even the built-in renderer treats it as a TODO. I had to use "&criteria" as a dummy surface ID :( | 03:31 |
| duflu | mterry: Better check with kdub. He's always likely to get pulled into more pressing Android work | 03:32 |
| mterry | kdub, if I don't get to you first, poke me tomorrow! | 03:33 |
| mterry | duflu, thanks so much! | 03:33 |
| * mterry is very slowly grokking Mir | 03:33 | |
| duflu | mterry: No problem. Sorry you're stuck on something that we already planned to redesign :/ | 03:33 |
| RAOF | Ok. That should really, truly, absolutely be the last umockdev merge request in a while! | 06:54 |
| === mpt_ is now known as mpt | ||
| mlankhorst | RAOF: erm can you now at a mainloop api like in pulseaudio? :P | 09:45 |
| duflu | So many things I'd like to move around. But the weekend is in the way. | 09:52 |
| duflu | Till next time | 09:52 |
| === lool- is now known as lool | ||
| alan_g | alf_: were you looking at an intermittent failure in MesaDisplayTest recently? https://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/1007/console | 12:20 |
| alf_ | alan_g: yes, but it was a clean failure, no exceptions, and fixed (by all appearances) by r1401 | 12:27 |
| alan_g | alf_: thanks, will try to reproduce this one then | 12:28 |
| * alan_g reproduces intermittent failures in MesaDisplayTest.drm_device_change_event_triggers_handler | 12:37 | |
| alf_ | alan_g: exceptions, or other test failure? | 12:42 |
| alan_g | Segmentation fault (core dumped) | 12:42 |
| alan_g | I'll look deeper after lunch | 12:43 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf_: still happy with the updates to https://code.launchpad.net/~alan-griffiths/mir/make-ConfigurationOptions-a-dependency-of-DefaultServerConfiguration/+merge/206996? | 13:51 |
| alf_ | alan_g: looking | 13:51 |
| === Trevinho_ is now known as Trevinho | ||
| alf_ | rsalveti: Hi! I am trying to run the x86 emulator to get more information about https://bugs.launchpad.net/mir/+bug/1282248 , but all I am getting is a blank screen in the emulator | 15:11 |
| ubot5 | Launchpad bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [High,In progress] | 15:11 |
| alf_ | rsalveti: Any ideas? | 15:11 |
| rsalveti | alf_: hm, getting a black screen with my guide? | 15:15 |
| rsalveti | *blank | 15:15 |
| rsalveti | alf_: are you using it with a proprietary gl driver at your host? | 15:15 |
| alf_ | rsalveti: yes, your guide, free drivers, radeon and intel (tried with both) | 15:21 |
| rsalveti | alf_: weird, trying it again locally | 15:21 |
| alf_ | rsalveti: I do get related errors: http://paste.ubuntu.com/6971401/ | 15:23 |
| rsalveti | oh, alright | 15:24 |
| alf_ | rsalveti: hmm, I think I need to install the i386 mesa drivers (running on amd64)? | 15:26 |
| rsalveti | alf_: yes | 15:26 |
| alf_ | rsalveti: isn't there an amd64 version of this? | 15:27 |
| rsalveti | alf_: not yet | 15:27 |
| rsalveti | there will be sson | 15:28 |
| rsalveti | *soon | 15:28 |
| alf_ | rsalveti: ok | 15:28 |
| alf_ | rsalveti: works now great! | 15:34 |
| rsalveti | alf_: great! | 15:34 |
| alf_ | rsalveti: does the image have persistent storage? | 15:35 |
| rsalveti | alf_: any idea of what might be wrong with that bug? | 15:35 |
| rsalveti | alf_: yes | 15:35 |
| alf_ | rsalveti: I have found the exact commit that introduces it (on a real device at least), but the armhf backtraces I can get are less than helpful... | 15:36 |
| rsalveti | alf_: yeah =\ | 15:36 |
| alf_ | rsalveti: the commit is the one that changes the client platform to be dynamically loaded instead of built-in, not sure why that would cause a failure, though. Running nested tests with mir_demo_* works... | 15:37 |
| alf_ | rsalveti: anyway, hopefully the x86 backtraces will be more helpful | 15:38 |
| rsalveti | alf_: yeah, it's quite weird, at least the x86 image doesn't have any issue with android TLS | 15:39 |
| === dandrader is now known as dandrader|afk | ||
| alf_ | fginther: Thanks for preparing the jobs. I realized that this is something I could by myself in the future if I want to try something, if I branch the hooks, right? | 16:16 |
| === dandrader|afk is now known as dandrader | ||
| fginther | alf_, yes, I did have to configure the job first to allow the hooks, but once they are there you can substitute in your own branch / hooks for testing | 16:17 |
| kdub | mterry, ping | 17:15 |
| mterry | kdub, hello! | 17:15 |
| mterry | kdub, I had some questions for you. Is that what this ping is? | 17:16 |
| kdub | yeah, saw some chatter about the surface stack iteration stuff | 17:16 |
| mterry | kdub, so my ultimate goal is to be able to tell when a session/surface actually has posted their first frame to render. This has been harder than I'd thought | 17:18 |
| mterry | kdub, recently I tried to go down the CompositingCriteria route | 17:18 |
| mterry | kdub, but it isn't exposed in a particularly meaningful way | 17:18 |
| mterry | kdub, but I was told you were working in that space? | 17:18 |
| kdub | well, I have to revise the surface stack to enable android bypass/overlays | 17:19 |
| kdub | the interfaces now have been out-grown by the way they are being used, and need some reassessment | 17:19 |
| mterry | kdub, well. I am highly interested in being able to tell when a (at least first) frame has been rendered | 17:20 |
| mterry | kdub, what is priority of your work? Like, how likely is it to happen soonish? | 17:23 |
| kdub | mterry, that's a bit different area than refactoring the surfacestack/compositingcriteria system | 17:23 |
| mterry | kdub, well, I can probably get what I need from actual access to CompositingCriterias and being able to match them to a surface | 17:24 |
| kdub | let me see if there's a way to do that in the public interfaces | 17:24 |
| kdub | or if there's a quick way to add a fn | 17:24 |
| mterry | kdub, because they have the should_be_rendered_in() call | 17:24 |
| mterry | kdub, and I can iterate over the CompositingCriterias via the Scene object and its for_each_if calls | 17:24 |
| mterry | kdub, but I can't actually tell which Surface they each match with | 17:25 |
| kdub | thats kinda a heavyweight solution though, as we lock the surfacestack during the iteration over the surfaces | 17:26 |
| mterry | kdub, well I'm all for better ways. It's literally the only way to get at Criterias right now though | 17:28 |
| alan_g | kdub: also, that locking is something we plan to rip out - along with the associated code | 17:28 |
| kdub | alan_g, sure | 17:30 |
| kdub | mterry, what is the larger problem? (eg, trying to coordinate some animation or something) | 17:30 |
| alan_g | I've still not understood why waiting for swap_buffers(Not(nullptr)) doesn't work | 17:31 |
| alan_g | duflu found a Mesa bug while looking into this. But mterry is on the android drivers | 17:32 |
| mterry | alan_g, there are internally several buffers posted before the client gets to run | 17:32 |
| mterry | alan_g, so maybe that's just a bug. But it's not usable at the moment | 17:32 |
| mterry | alan_g, that's all in the bug | 17:33 |
| alan_g | mterry: yeah, I don't understand why | 17:33 |
| mterry | alan_g, meaning that you think it's a bug that Mir is swapping buffers so early? | 17:33 |
| mterry | kdub, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1280842 explains my ultimate goal in all this | 17:36 |
| alan_g | mterry: mir should only be getting a buffer once it has been drawn. I don't know exactly what your scenario is doing to send buffers from the client before they are ready. | 17:36 |
| ubot5 | Launchpad bug 1280842 in mir (Ubuntu) "[enhancement] Need a method of hiding surfaces until they are ready to draw themselves" [Medium,Opinion] | 17:36 |
| mterry | alan_g, it's not even *my* scenario. It's just a client calling mir::run_mir | 17:37 |
| mterry | alan_g, something about constructing/running a DisplayServer causes 4 buffers to be swapped | 17:37 |
| alan_g | mterry: so this client is a nested server? | 17:37 |
| mterry | alan_g, yeah | 17:37 |
| mterry | alan_g, (this is all in the context of USC which just deals with nested servers) | 17:38 |
| alan_g | mterry: I strongly suspect a bug in the nested code then | 17:39 |
| alan_g | With a second possibility that the android client code is the cause | 17:40 |
| alan_g | *internal* client | 17:41 |
| mterry | alan_g, would that be work-around-able? | 17:41 |
| alf_ | alan_g: mterry: Hmm, when the compositor starts up it triggers itself, each trigger being 3 compositings. In a nested server, swapping the buffer when compositing means sending the buffer to usc. | 17:43 |
| alan_g | And the 4th could be something like the Mesa "advance_buffer" bug? | 17:46 |
| alf_ | alan_g: yeah | 17:47 |
| mterry | I do only get 3 if I hide() the surface first, FYI | 17:47 |
| alan_g | mterry: that makes sense | 17:47 |
| kdub | iirc, android shouldnt do that 'advance_buffer' | 17:48 |
| kdub | rather, the same sort of bug as the Mesa "advance_buffer". it does request a buffer on eglCreateWindowSurface, but it should get the buffer associated with the surface creation | 17:49 |
| kdub | (nexus 10 does something different) | 17:50 |
| alan_g | kdub: ok, but I'll buy alf_ explanation - we need to something different when compositing in nested mode. | 17:51 |
| alan_g | If no-one else grabs it I can have a go on Monday | 17:52 |
| * mterry hugs alan_g | 17:52 | |
| * alan_g blushes | 17:52 | |
| mterry | alan_g, so the idea would be that USC could call hide(), watch for buffer swaps, and when it gets a non-null one, show() again? | 17:53 |
| mterry | or maybe it wouldn't need to call hide if it weren't getting buffer swaps in the first place | 17:53 |
| alan_g | mterry: yes, nested clients ought to behave like regular ones | 17:54 |
| mterry | alan_g, sounds perfect | 17:54 |
| * alan_g decides to cut & paste the above discussion into the bug | 17:55 | |
| === alan_g is now known as alan_g|EOW | ||
| greyback | why are surfaces visible if client hasn't drawn to them yet? To me makes more sense for mir to tell a shell that a Surface was created, only when that surface was drawn to by the client | 18:06 |
| greyback | not when the surface buffer was allocated for that client | 18:07 |
| greyback | anyway, gotta run, good weekend all! | 18:07 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!