| racarr_ | wow new chromium worked on the first try | 00:51 |
|---|---|---|
| racarr_ | that never happens :p | 00:52 |
| racarr_ | it seems a little more responsivice perhaps...but it was never bad | 00:52 |
| RAOF | Oh, great. | 02:42 |
| RAOF | Looks like glibc's now using Haswell's fancy lock elision instructions. | 02:43 |
| RAOF | Making valgrind confusinated. | 02:47 |
| racarr_ | just read alittle about the implementation | 03:16 |
| racarr_ | that is really...fancy | 03:16 |
| racarr_ | if someone told me to implement that I would probably just cry | 03:17 |
| RAOF | racarr_: Oh, re: vsync conversation above - we can pull whatever vsync related information you need out of drm. | 03:26 |
| racarr_ | :) cool | 03:27 |
| racarr_ | ill doa littlestudy of how chromiumis usingit and see what we should expose | 03:28 |
| RAOF | racarr_: Specifically, the infrastructure to support GLX_sync_control is there, so we can get the frame time and such. | 03:28 |
| * RAOF goes babywards | 03:28 | |
| racarr_ | :) ttyl | 03:29 |
| RAOF | So, um... how does this _ever_ fail to leak? | 05:59 |
| RAOF | Ok, new question. | 06:01 |
| RAOF | Why does is the leak only *fatal* on *some* of the CI infrastructure? | 06:01 |
| RAOF | tvoss: Good morning! | 06:02 |
| tvoss | RAOF, good morning :) | 06:02 |
| === chihchun_afk is now known as chihchun | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| anpok | alf__: will you have time to look at the input-sender again today? | 09:43 |
| alf__ | anpok: sure | 09:48 |
| anpok | not urgent, but is anybody else also affected by: https://bugs.launchpad.net/mir/+bug/1294610 | 10:04 |
| ubot5 | Ubuntu bug 1294610 in Mir "client attaching to nested server seems to freeze the VT" [Undecided,New] | 10:04 |
| greyback | Hi folks, a preliminary review for https://code.launchpad.net/~dandrader/mir/expose-android-input/+merge/224335 would be appreciated | 10:09 |
| anpok | oh the ci failure looks interesting - will propose a synchronous timer destruction then. | 10:33 |
| alan_g | In other news: "The Library Evolution Working Group (LEWG) voted to base the Networking TS on Boost.ASIO." | 10:44 |
| anpok | good timing | 10:45 |
| anpok | but there wasnt really an alternative, was there? | 10:46 |
| alan_g | It is a massive change in direction. (But probably a rational one.) | 10:50 |
| === alan_g is now known as alan_g|lunch | ||
| === renato_ is now known as Guest60599 | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === mterry_ is now known as mterry | ||
| === dandrader is now known as dandrader|afk | ||
| === chihchun_afk is now known as chihchun | ||
| === olli_ is now known as olli | ||
| === dandrader|afk is now known as dandrader | ||
| anpok | alan_g: wrt to https://code.launchpad.net/~alan-griffiths/mir/fix-1334287/+merge/224457/comments/538943 I want to use the action queue to sequentialize the timer callbacks and the canceling operations.. then either cancel happens before asio decides to schedule the timer or the other way round, and synchronous_server_action waits till the canceling completes.. | 15:49 |
| anpok | so in the bad case, the callback is called during cancel waits that the server action queue executes the actual cancel operation | 15:51 |
| anpok | but i just messed up my solution .. need to clear my head .. and look again what I missed.. or if you want to look I could push it somewhere.. | 15:52 |
| alan_g | anpok: ack - I'm halfway through fixing my fix, so I won't look right now. Tomorrow am? | 15:53 |
| anpok | yes | 15:57 |
| kgunn | davmor2: is there any way you could perform some smoke testing on silo20 ? this is the same silo you tested 2 days ago.... | 15:58 |
| kgunn | we had some packaging isssues, so mostly just a rebuild | 15:58 |
| kgunn | but we'd like to get some external eyes on it | 15:58 |
| davmor2 | kgunn: I can have a look after I'm just trying to trace an issue currently. | 15:58 |
| kgunn | rsalveti: ^ if you would like to help with testing silo20 that'd be awesome (its the display blank policy move from powerd to usc) | 15:59 |
| dandrader | is anyone working on getting unity-system-compositor updated against latest lp:mir/devel? | 16:22 |
| dandrader | I mean unity-system-compositor/devel-mir-next | 16:23 |
| === dandrader is now known as dandrader|lunch | ||
| rsalveti | kgunn: I tested it already, also replied to that thread giving +1 | 16:24 |
| kgunn | rsalveti: thanks! | 16:24 |
| kgunn | dandrader|lunch: i think alf__ might have been, but got sucked into a regression/critical bug investigation | 16:25 |
| alf__ | kgunn: dandrader|lunch: exactly | 16:25 |
| davmor2 | kgunn: I'm off early today but when I get back I'll give you a ping with my results | 16:26 |
| kgunn | dandrader|lunch: dednick needs it too...if i can get someone on it today i will | 16:27 |
| kgunn | alf__: btw, any update on that bug ? | 16:27 |
| alf__ | kgunn: not yet, I am trying to track what is going through all the layers | 16:27 |
| kdub_ | which bug? | 16:27 |
| alf__ | kdub_: https://bugs.launchpad.net/mir/+bug/1332632 | 16:29 |
| ubot5 | Ubuntu bug 1332632 in gallery-app "can't display toolbar after dismissing it" [Critical,In progress] | 16:29 |
| kdub_ | kgunn, I've fixed up usc locally here for my overlay work, maybe I s hould dust it up and propose | 16:34 |
| kgunn | kdub_: yeah, please do | 16:35 |
| alf__ | kdub_: problem with usc is that it overrides the scene and returns renderables manually. However with the new changes it can't do that (it doesn't know how to create a SceneElement) | 16:36 |
| kdub_ | alf__, i just wrote a SceneElement impl there | 16:37 |
| kdub_ | that forwards the renderable along | 16:37 |
| alf__ | kdub_: For some reason it wants to only expose surfaces from two sessions (current and next). I was thinking that instead of customizing the scene it could hide the unneeded session. | 16:37 |
| kdub_ | alf__, yes, that seems the better approach | 16:38 |
| alf__ | kdub_: problem is that the new SceneElement doesn't properly handle visibility events | 16:38 |
| alf__ | kdub_: (i guess, unless you managed to do it somehow :)) | 16:38 |
| kdub_ | right, I was just realizing the visibility events in my branch wouldn't work | 16:38 |
| alf__ | kdub_: well, if you have cycles to work on it great, otherwise I am going to pick it up again after I am done with this bug | 16:40 |
| kdub_ | alf__, okay | 16:40 |
| kdub_ | kgunn, so it seems my usc branch was only sufficient for testing out overlay stuff, not for landing | 16:41 |
| kgunn | alf__: kdub_ ack | 16:48 |
| AlbertA | alf__: I believe it does the current and next | 16:48 |
| AlbertA | alf__: so that with the split greeter | 16:48 |
| AlbertA | alf__: alpha transitions can be done | 16:49 |
| AlbertA | alf__: if you hide it, then it will just show a black screen as you slide off the greeter | 16:49 |
| kdub_ | AlbertA, is the sliding not moving the surface? | 16:50 |
| alf__ | AlbertA: I was thinking of hiding every other surface/session besides current and next | 16:50 |
| AlbertA | kdub_: no because this is under nested, they are essentially fullscreen sessions | 16:51 |
| kdub_ | oh, and alpha channel is just arranged to look like its moving | 16:51 |
| AlbertA | kdub_: right | 16:51 |
| AlbertA | alf__: oh ok | 16:51 |
| kdub_ | so... potential optimization | 16:51 |
| alf__ | AlbertA: ...so then the default SceneElementSequence would be what USC wants (hopefully) | 16:52 |
| kgunn | mterry: ^ | 16:52 |
| mterry | mmm, ok... | 16:53 |
| AlbertA | kdub_: right I mean for performance reasons... if the animation could be done in USC then that would be better since you wouldn't need alpha blending then | 16:53 |
| AlbertA | kdub_: it would just be surface movement | 16:53 |
| kdub_ | right | 16:53 |
| * alan_g thinks it is time to get "nested" back under test | 16:57 | |
| kdub_ | indeed | 16:58 |
| alan_g | Something to do tomorrow. | 16:59 |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader|lunch is now known as dandrader | ||
| Davmor3 | kgunn: So this working okay | 18:30 |
| AlbertA | Davmor3: you mean landing-020 looks ok? | 18:34 |
| racarr_ | im still stuck on how to get change notifications to the compositor for cursor-is-a-renderable | 18:42 |
| racarr_ | and I am starting to wonder if maybe cursor is a surface | 18:42 |
| racarr_ | but NOT a frontend::Surface | 18:42 |
| racarr_ | the thing is scene::Surface would have to lose inheritance of frontend::Surface | 18:43 |
| racarr_ | then you add like a | 18:43 |
| racarr_ | ...ClientSurface : scene::Surface, frontend::Surface | 18:44 |
| racarr_ | BasicSurface : ClientSurface (:/, basic surface is really just like clientsurfaceimpl) | 18:44 |
| racarr_ | scene::Surface : input::Surface, SurfaceBufferAccess | 18:44 |
| racarr_ | CursorSurface : scene::Surface | 18:45 |
| racarr_ | the problem with Cursor : Renderable | 18:46 |
| racarr_ | is you need an add_observer API | 18:46 |
| racarr_ | but its desirable not to have RenderableObserver as...basically a parallel class to | 18:47 |
| anpok | racarr_: a SceneElement maybe? | 18:47 |
| racarr_ | SurfaceObserver | 18:47 |
| anpok | with a Renderable inside? | 18:47 |
| racarr_ | but you cant just promote surfaceobserver to renderableobserver | 18:47 |
| racarr_ | because | 18:47 |
| racarr_ | ms::Surface is NOT | 18:47 |
| racarr_ | a renderable | 18:47 |
| racarr_ | so then the shell wouldn't have add_observer | 18:47 |
| racarr_ | anpok: Yes, that part is fine | 18:48 |
| racarr_ | the problem is, the way the compositor gets | 18:48 |
| racarr_ | notifications is by seeing | 18:48 |
| anpok | if the scene changed | 18:48 |
| racarr_ | Observer::surface_added(ms::Surface) | 18:48 |
| anpok | i see | 18:48 |
| racarr_ | and calling ms::Surface->add_observer | 18:48 |
| racarr_ | so if its not a surface observers wont work | 18:48 |
| anpok | that is correct as long as there are only surfaces in a scene | 18:48 |
| anpok | scene::Surface that is | 18:49 |
| racarr_ | but surface is NOT a renderable (it produces renderable snapshots) | 18:49 |
| racarr_ | so you cant just make it Renderable::add_observer | 18:49 |
| racarr_ | yes | 18:49 |
| racarr_ | so either somehow I need to untangle that | 18:49 |
| anpok | yes | 18:49 |
| racarr_ | or! make | 18:49 |
| racarr_ | the Cursor a surface. | 18:49 |
| racarr_ | but its pretty clearly NOT a frontend::Surface | 18:49 |
| racarr_ | so that hierarchy would have to be untangled | 18:49 |
| anpok | and untangling the hierachy is close to untangling scene / surface / renderable | 18:52 |
| racarr_ | Mm | 18:52 |
| anpok | and i think the latter is the one we are aiming for in the long run? | 18:52 |
| anpok | but dont listen to me i am prone to prefere big changes | 18:53 |
| racarr_ | i am just worried it will get so big | 18:54 |
| racarr_ | that I will spend a week | 18:54 |
| racarr_ | porting all the client code and test code and stuff | 18:54 |
| racarr_ | to new interfaces | 18:54 |
| racarr_ | and then...um | 18:54 |
| racarr_ | it will be wrong for some reason lol | 18:55 |
| racarr_ | because im still not confident | 18:55 |
| racarr_ | I kind of like this | 18:58 |
| racarr_ | um | 18:58 |
| racarr_ | scene::Surface : input::Surface, SurfaceBufferAccess { ... add/remove_observer... } | 18:58 |
| racarr_ | i.e. what the two views of the scene require. | 18:59 |
| racarr_ | and Client(/Application?)Surface : scene::Surface, frontend::Surface | 18:59 |
| racarr_ | trying to figure out how much churn its going to cause...who uses implicit cast...from scene::Surface to frontend::Surface or uses the frontend::Surface methods in scene::Surface. | 19:00 |
| racarr_ | i.e. the shell primarily deals with scene::Surface... | 19:03 |
| racarr_ | and you dont want the shell to have to dynamic_cast<frontend::Surface> | 19:03 |
| racarr_ | but the shell does want to call things like mf::Surface::configure(attrib, val) | 19:03 |
| racarr_ | so you end up needing those methods on scene::Surface anyway | 19:03 |
| racarr_ | which. means the cursor has to implement them, but shouldn't | 19:04 |
| racarr_ | potentially the shell could work in terms of | 19:04 |
| racarr_ | ClientSurface. | 19:04 |
| racarr_ | Window : scene::Surface, frontend::Surface? | 19:04 |
| anpok | the shell might want to add other things to the scene | 19:04 |
| racarr_ | ...just throwing that one out there :p | 19:04 |
| anpok | not just the cursor.. or surfaces.. i think some form of type detection will be necessary as soon as it turns into a tree | 19:05 |
| racarr_ | maybe on the view sides | 19:05 |
| racarr_ | but if on the client side, i.e. shell code manipulating surfaces | 19:06 |
| racarr_ | all the code looks like | 19:06 |
| racarr_ | i.e. the wm code | 19:06 |
| racarr_ | "cast to frontend surface/cient surface/whatever, if it is one do stuff, if not return" | 19:06 |
| racarr_ | then that cant be right | 19:06 |
| anpok | hm what is wm code? | 19:07 |
| racarr_ | ill be honest I kind of miss mir::shell::Surface | 19:07 |
| racarr_ | anpok: Wiondow management code | 19:07 |
| anpok | yeah, but what is it? Raof mentioned in malta ... that you would probably have the tree of things that you want to traverse to insert new items or manipulate them.. dispatch input .. draw.. and another set of things which represents the clients and the attached surfaces.. | 19:08 |
| racarr_ | what is it in what sense? | 19:09 |
| racarr_ | I mean its unity-mir | 19:09 |
| racarr_ | but I feel like thats not what you are asking lol | 19:09 |
| anpok | :) | 19:09 |
| racarr_ | but right there is this | 19:09 |
| racarr_ | well there could be | 19:09 |
| racarr_ | this shell side view of the scene v. | 19:09 |
| racarr_ | the compositor side view. | 19:10 |
| racarr_ | but I guess we sort of had something like that and it was wildly unpopular and took a lot of time to consolidate | 19:10 |
| anpok | I think that the view part looks like what you said above .. traverse and figure out the type of elements.. and I think the WM code will interact with actual windows/surfaces partially ignoring the graph in many cases | 19:10 |
| anpok | ah | 19:10 |
| racarr_ | hmm.. | 19:11 |
| racarr_ | I have a whole other tree of thought | 19:12 |
| racarr_ | as a potential fix for the cursor...but im not sure | 19:12 |
| racarr_ | how promising it is | 19:12 |
| racarr_ | that maybe, rather than the compositor observe and then ask for renderable lists on changes | 19:12 |
| racarr_ | the compositor is given the renderable list. | 19:13 |
| greyback | does cursor really have to be part of scene? It might better belong in a layer on top all for itself | 19:13 |
| AlbertA | ummm I seem to remember alan pragmatically suggesting just sending the renderables + cursor | 19:13 |
| AlbertA | a while ago | 19:13 |
| racarr_ | sending the renderables + cursor? | 19:13 |
| racarr_ | greyback: In this branch so far it is in a special layer in the surface stack | 19:13 |
| AlbertA | right to the compositor | 19:13 |
| racarr_ | greyback: The point is its in the "RenderableList" that the compositor sees | 19:13 |
| AlbertA | which can then always put it on top, etc... | 19:14 |
| racarr_ | Oh in the sense of sending them v. the surface stack asking for them | 19:14 |
| greyback | racarr_: sure I get that. But since you're struggling to incorporate cursor into the scene, perhaps it doesn't belong there at all | 19:14 |
| AlbertA | racarr_: basically cursor would not be in RenderableList | 19:15 |
| AlbertA | but separate | 19:15 |
| AlbertA | it seemed to make sense at the time (a few months ago) | 19:15 |
| racarr_ | but then how do you know | 19:15 |
| racarr_ | when to ask for it? | 19:15 |
| racarr_ | when its changed | 19:16 |
| AlbertA | at the same time as when the renderables are obtained | 19:16 |
| racarr_ | but thats in response to callbacks from SurfaceObserver | 19:16 |
| racarr_ | you could add like | 19:16 |
| racarr_ | ms::Observer::cursor_moved() | 19:17 |
| AlbertA | yeah that would make sense to me | 19:17 |
| racarr_ | but its starting to feel kind of clumsy at that point I think...why am I dealing with the cursor so seperately? | 19:17 |
| AlbertA | because it's not a surface? lol | 19:18 |
| racarr_ | everything except mesa with hardware cursor, literally just treats it like any other renderable | 19:18 |
| racarr_ | but | 19:18 |
| racarr_ | the compositor doesnt consume surfaces | 19:18 |
| racarr_ | it consumes | 19:18 |
| racarr_ | renderables | 19:18 |
| racarr_ | it just uses surfaces to know when | 19:18 |
| racarr_ | renderables are ready to be consumed | 19:18 |
| racarr_ | is the problem | 19:18 |
| AlbertA | true...I guess it depends on who is in charge | 19:18 |
| AlbertA | of the z-policy | 19:18 |
| AlbertA | I guess scene is | 19:18 |
| AlbertA | not compositor | 19:18 |
| AlbertA | so yeah it would make sense for it to be in the renderablesList | 19:19 |
| racarr_ | render list generalizes nicer to | 19:19 |
| racarr_ | touch spot visualization as well | 19:19 |
| racarr_ | than cursor_moved() which starts to become | 19:19 |
| racarr_ | increasingly nebulous | 19:19 |
| AlbertA | yep yep | 19:20 |
| racarr_ | maybe...ms::Observer is the wrong interface for the compositor | 19:20 |
| AlbertA | so is the issue that right now you would have to work the cursor into surfacestack? | 19:21 |
| racarr_ | well, that part isn't so bad | 19:21 |
| racarr_ | there I am specializing it, the surface stack has a cursor built in (or perhaps you add/remove_input_visualization(mg::Renderable)) | 19:21 |
| racarr_ | and they show up in generate_renderable_list | 19:21 |
| racarr_ | but not input::for_each, etc | 19:21 |
| racarr_ | the problem is just about the notifications really | 19:22 |
| racarr_ | because, the compositor receives surface_added(ms::Surface) and uses that to install | 19:22 |
| AlbertA | oh I see... | 19:22 |
| AlbertA | like if only the cursor moves | 19:22 |
| racarr_ | a SurfaceObserver | 19:22 |
| racarr_ | yeah | 19:22 |
| racarr_ | and then. the SurfaceObserver interface cant be changed | 19:23 |
| racarr_ | to RenderableObserver i.e. renderable_added(mg::Renderable), etc | 19:23 |
| racarr_ | because Unity-Mir uses it | 19:23 |
| racarr_ | and mir::scene::Surface is NOT a renderable | 19:23 |
| racarr_ | it just generates one | 19:23 |
| AlbertA | so what about a generic notification in Scene::Observer | 19:24 |
| AlbertA | like scene_changed... | 19:24 |
| AlbertA | so that it's just opaque enough | 19:25 |
| racarr_ | AlbertA: That's kind of...what im close to giving up and trying...but thats going to make it really hard to implement | 19:25 |
| racarr_ | partial updates right | 19:25 |
| racarr_ | because...what could you do | 19:25 |
| racarr_ | keep around a copy of the old render list | 19:25 |
| racarr_ | then generate a new one | 19:25 |
| racarr_ | and diff them?! | 19:25 |
| racarr_ | it's kind of painful | 19:26 |
| AlbertA | you mean partial updates by the compositor? or just a general observer | 19:26 |
| racarr_ | by the compositor | 19:26 |
| racarr_ | i.e. the cursor is moving around just paint | 19:27 |
| racarr_ | tiny regions | 19:27 |
| AlbertA | ummm but that's not our compositor architecture | 19:27 |
| AlbertA | we do full frame updates | 19:27 |
| AlbertA | I mean I envision | 19:28 |
| racarr_ | I guess I thought we were going to make it smarter and that was part of hte motivation | 19:28 |
| AlbertA | once we have a tree | 19:28 |
| racarr_ | behind | 19:28 |
| racarr_ | ms::Observer | 19:28 |
| racarr_ | vs the old | 19:28 |
| racarr_ | std::function<void()> notify_change | 19:29 |
| AlbertA | every change we optimize drawing on the current tree... | 19:29 |
| AlbertA | but not damage based composition | 19:29 |
| racarr_ | maybe... | 19:30 |
| racarr_ | hmm so with the generic notification | 19:30 |
| racarr_ | how do prevent double draw. | 19:30 |
| racarr_ | i.e. surface_changed also generates scene_changed | 19:30 |
| racarr_ | or is it not really a | 19:30 |
| racarr_ | "generic" notification but rather like | 19:31 |
| racarr_ | "scene_changed_in_a_way_the_other_callbacks_dont_represent" | 19:31 |
| racarr_ | or | 19:31 |
| AlbertA | right | 19:31 |
| racarr_ | does the | 19:31 |
| racarr_ | compositor just use | 19:31 |
| racarr_ | scene_changed | 19:31 |
| racarr_ | and ignore the | 19:31 |
| racarr_ | sort of damaged based ones | 19:31 |
| racarr_ | SO MANY OPTIONS SO LOW BLOOD SUGAR | 19:31 |
| AlbertA | yeah...good points | 19:32 |
| racarr_ | haha ok lunch...then I think I am going to come back and get something pumped out with the generic callback.. | 19:35 |
| AlbertA | but doesn't SurfaceObserver kinda have the same issue right now? I mean if an observer was listening to say orientation_set_to and transformation_set_to | 19:35 |
| racarr_ | thanks AlbertA anpok :) | 19:35 |
| racarr_ | AlbertA: ? | 19:35 |
| racarr_ | oh | 19:35 |
| racarr_ | yes | 19:35 |
| AlbertA | I mean right now they all get collapsed to one notification | 19:35 |
| racarr_ | but they should be intelligent | 19:35 |
| racarr_ | for example the cursor controller one is | 19:35 |
| racarr_ | and doesnt | 19:35 |
| racarr_ | collapse on | 19:35 |
| racarr_ | surface attribc change, orientation, etc | 19:36 |
| racarr_ | because those by themselves | 19:36 |
| racarr_ | arent enough to | 19:36 |
| racarr_ | change the actual position | 19:36 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| dandrader | kgunn, alf__: FYI: I've started updating unity-system-compositor/devel-mir-next to latest lp:mir/devel myself as this is blocking me anyway | 22:47 |
| kgunn | ack | 22:49 |
| racarr_ | [ OK ] TestTouchspotVisualizations.touch_is_given_to_touchspot_visualizer (12 ms) | 23:59 |
| racarr_ | whee | 23:59 |
| racarr_ | I made...a dumb mistake in all of this | 23:59 |
| RAOF | Heh | 23:59 |
| racarr_ | in that...once I figured out cursor is a renderable...I started thinking about the interface | 23:59 |
| racarr_ | I would want for touchspots | 23:59 |
| racarr_ | and realized that | 23:59 |
| racarr_ | it was exactly the same as the interface that I thought of exposing | 23:59 |
| racarr_ | as a temporary solution | 23:59 |
| racarr_ | tounblock thomi | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!