| === chihchun_afk is now known as chihchun | ||
| ice9 | how efficient is Mir currently? | 11:47 |
|---|---|---|
| ogra_ | ice9, efficient eough to be the default on all tablet and phone images | 12:12 |
| ice9 | ogra_: I mean the desktop sorry | 12:13 |
| ogra_ | yeah, no idea about that ... | 12:13 |
| ogra_ | (since there is no desktop that could use Mir yet)( | 12:13 |
| mterry | What's the best way for USC to tell a session to "freeze" -- i.e. don't render any frames. I thought it was hide(), but it seems that doesn't stop it from swapping buffers. In 0.1.9, I'm guessing I use lifecycle events. But what about 0.1.8? | 13:25 |
| kgunn | mterry: do you want everyone to freeze ? i would assume yes | 13:36 |
| mterry | kgunn, in this particular instance I want to be able to freeze a whole session -- all its surfaces. So not quite everyone (not all sessions) | 13:36 |
| * mterry goes afk real quick | 13:38 | |
| kgunn | mterry: i would have thought hide as well....is it really about the rendering ? or you just want a still frame ? e.g. the analogy hear would be unity-mir using snapshots i think | 13:38 |
| kgunn | mterry: so out of curiosity i started to poke, wonder if set_lifecycle_state on session is what you'd want to use...altho, good news bad news, the i/f kinda sounds right, but not sure if anything acts on it | 13:47 |
| kgunn | AlbertA: camako ...am i reading the code correct ? ^ do the states of set_lifecycle_state not really get acted on? | 13:48 |
| camako | kgunn: checking | 13:48 |
| kgunn | i see where it makes it to protobuf_life_event and the state gets set, but then i don't really see any action taken on it... | 13:54 |
| camako | kgunn: I don't see set_lifecycle_state being called from anywhere | 13:55 |
| kgunn | camako: right, well...i was thinking it might server mterry's purpose (he's shell like in a sense with the greeter sitting on top of u-s-c) | 13:56 |
| kgunn | u-s-c==unity-system-compositor | 13:56 |
| kgunn | he wanted to halt apps (sessions) from rendering... | 13:56 |
| kgunn | not completely sure why yet...but seemed a sensible thing to want to do as a shell-like-thing | 13:57 |
| kgunn | camako: mterry ...so it's actually called in unity-mir, wonder if its an opaque msg (e.g. mir not acting on it but passed to platform-api) | 14:00 |
| mterry | kgunn, heyo, back. So in 0.1.8, lifecycles don't seem to do much. That might change in 0.1.9? | 14:03 |
| mterry | kgunn, the reason I want this is for split greeter boot animation -- on boot, we don't show the greeter session until both the greeter and user session are ready to go (i.e. we don't want to show the greeter without the user session behind it ready to go) but... | 14:03 |
| mterry | kgunn, the greeter also has a "fade in animation" that we want to have happen when the user sees it -- so ideally when the greeter is ready, I could "freeze" it until the user session is also ready so the user sees the full fade in animation -- as is today, the user may miss the animation because the greeter was running through it while waiting for the user session. Make sense? | 14:04 |
| mterry | kgunn, this may be yet another blocker for split mode from the design side | 14:05 |
| mterry | kgunn, sometimes the user session is ready before the greeter, so there's no problem. But not always. So it's a bit of a race and design prefers the animation always happen, naturally | 14:05 |
| kgunn | mterry: afaik, w 0.1.9, only additional mgmt atm is coming with qtubuntu where the exposeEvent is triggered | 14:07 |
| mterry | kgunn, I really did think hide() did that though. I'd like to hear if it's intended to do that and I'm making some mistake or if that's just not the API I want | 14:07 |
| kgunn | mterry: yeah...makes sense....basically, when the greeter is ready "well before" the user session, there's no fade, and it just looks like a hard switch/hard transition animation ( | 14:08 |
| mterry | Yeah. "well before" can be on the order of just a second though. Fade in animation isn't super long | 14:08 |
| kgunn | mterry: my only fear there, is hide won't "halt renders" in 0.1.9 | 14:09 |
| kgunn | this is the whole point of the non-block swap | 14:09 |
| kgunn | mterry: all this being said....sounds like a sensible control for a shell-like thing to have | 14:09 |
| mterry | kgunn, right. But lifecycle would replace that, eh? | 14:09 |
| mterry | kgunn, or yeah, maybe we need to add a tiny bit of API | 14:10 |
| mterry | kgunn, this seems like a reasonable use case | 14:10 |
| mterry | kgunn, I'll file a feature bug, not sure who can work on it though | 14:10 |
| kgunn | mterry: my worry on life cycle even with 0.1.9...is that, the side channel is racy also... so, you end up getting some "renders you don't see" | 14:10 |
| mterry | kgunn, I see | 14:10 |
| kgunn | mterry: actually...when was the last time you dealt with lifecycle events ?....i do see some handling of it in platform-api as well...ubuntu_application_api_mirclient.cpp | 14:14 |
| mterry | kgunn, I tried to use them for this purpose last Friday | 14:16 |
| mterry | kgunn, didn't seem to do anything that I could see (I still saw swap_buffers being called for the client after I used lifecycle calls) | 14:16 |
| kgunn | hmmm.... | 14:17 |
| mterry | kgunn, bug 1310637 is the feature request, which might just get closed with a "this can already be done" comment | 14:17 |
| kgunn | mterry: wonder if this is a failing of nested ? | 14:17 |
| ubot5 | bug 1310637 in mir (Ubuntu) "Allow a server to halt rendering in a client session" [Undecided,New] https://launchpad.net/bugs/1310637 | 14:17 |
| AlbertA | kgunn: well it's a feature of non-blocking | 15:00 |
| AlbertA | "feature" | 15:00 |
| kgunn | AlbertA: yes yes... | 15:01 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| kgunn | AlbertA: i wouldn't drive yourself too crazy optimizing that 2% out before putting up MP's for the switching bundle change | 15:13 |
| kgunn | e.g. propose 1 set...then you can always propose a subsequent optimizATION SET | 15:14 |
| kgunn | oops...sorry cap lock strike | 15:14 |
| AlbertA | kgunn: o | 15:14 |
| AlbertA | kgunn: ok | 15:14 |
| kgunn | dang it... camako, could you share that acceptance test hit-list you, alan, kdub created ? | 15:18 |
| kgunn | or share the name i can search... | 15:19 |
| racarr__ | Nah. thanks though. | 15:19 |
| racarr__ | err kgunn ^ | 15:19 |
| racarr__ | went in to wrong channel | 15:19 |
| kgunn | i forgot to save the link | 15:19 |
| racarr__ | lol | 15:19 |
| kgunn | racarr__: :) | 15:19 |
| AlbertA | kgunn: should be in e-mail | 15:19 |
| kgunn | duh... | 15:19 |
| camako | kgunn :https://docs.google.com/document/d/17T4H5IhbfIPK3hErFz7VCmXReOywrHQnWwt_dTxe0kI/edit?usp=sharing | 15:20 |
| === chihchun is now known as chihchun_afk | ||
| racarr__ | https://www.youtube.com/watch?v=16EYejUic_0 - Great Code Review music. | 15:22 |
| AlbertA | racarr__: :( | 15:55 |
| AlbertA | racarr__: I mean :) | 15:55 |
| AlbertA | mterry: kgunn: the greeter has to listen to lifecycle events and stop its own rendering loop | 16:00 |
| AlbertA | mterry: kgunn: mir won't do anything to prevent that | 16:01 |
| AlbertA | mterry: kgunn: with the non-block swap behavior | 16:01 |
| kgunn | camako: as and when people start to free up and ask for things todo... i think items #1, #3, #4, #10 in your acceptance test doc make the most sense... | 16:03 |
| kdub | 6 is more of a sub-bullet for 3 | 16:04 |
| mterry | AlbertA, OK... Does 0.1.8 already have the ability for it to do that? | 16:04 |
| AlbertA | mterry: non-blocking? | 16:05 |
| AlbertA | mterry: that will be coming in 0.1.9 | 16:05 |
| mterry | AlbertA, for the greeter to listen to lifecycle events | 16:05 |
| AlbertA | mterry: you could do that now, that's what gerry is using for qtubuntu | 16:05 |
| racarr__ | The QPA is handling that for clients at least. Is it different because greeter is using qtubuntu-mirserver? | 16:05 |
| camako | kgunn: I'll keep that in mind | 16:06 |
| mterry | racarr__, greeter is using unity-mir/mirserver. I guess that makes it different? | 16:06 |
| AlbertA | racarr__: oh it's in-process? | 16:06 |
| racarr__ | Ci | 16:06 |
| racarr__ | But using qtubuntu | 16:06 |
| racarr__ | so the logic should be there, so maybe its just flipped off for in process? not sure hwo the shell | 16:06 |
| racarr__ | is handling render stop | 16:07 |
| AlbertA | mterry: greeter is qml? | 16:07 |
| AlbertA | mterry: the new version? | 16:07 |
| AlbertA | mterry: I mean the new split version of the greeter? | 16:07 |
| mterry | AlbertA, yeah, it basically runs same code as unity8, just different plugins/qml | 16:09 |
| AlbertA | mterry: you probably want to ping greyback then on how he uses the lifecyle to stop rendering | 16:09 |
| AlbertA | https://code.launchpad.net/~gerboland/qtubuntu/surface-visible-hidden-side-channel/+merge/215884 | 16:11 |
| AlbertA | mterry: ^ | 16:11 |
| racarr__ | https://code.launchpad.net/~josharenson/mir/install_glmark2/+merge/216504 | 16:12 |
| racarr__ | jenkins was ignoring | 16:12 |
| racarr__ | this branch...wonder why | 16:12 |
| racarr__ | (I just manually requested a CI review) | 16:12 |
| racarr__ | but there was none pending | 16:12 |
| mterry | AlbertA, thanks, will poke around | 16:14 |
| mterry | AlbertA, oh right. But I remember talking about the side channel for lifecycles and it is too slow -- can't rely on when it stops rendering | 16:28 |
| AlbertA | mterry: oh the 3 sec delay? | 16:29 |
| mterry | AlbertA, greyback's comments greyback's indicate that hide() *should* do what I want. but it doesn't seem to | 16:29 |
| mterry | maybe he's talking about Qt's hide | 16:29 |
| AlbertA | mterry: yeah beginning with 0.1.9 hide means don't show in screen | 16:29 |
| AlbertA | mterry: but apps can still render | 16:29 |
| mterry | AlbertA, 3 seconds? I dunno. I remember hearing it was "racy" in the sense that some frames might be rendered before the client handles lifecycle event | 16:29 |
| mterry | AlbertA, right. So I think I need a new API added -- stop_rendering() or some such that a server can tell a client session | 16:30 |
| mterry | AlbertA, I filed bug 1310637 | 16:30 |
| ubot5 | bug 1310637 in mir (Ubuntu) "Allow a server to halt rendering in a client session" [Undecided,New] https://launchpad.net/bugs/1310637 | 16:30 |
| AlbertA | mterry: and this is for in-process clients right? | 16:31 |
| mterry | AlbertA, i'm not sure about that term. It's USC talking to the greeter. So separate processes? | 16:31 |
| AlbertA | mterry: oh... | 16:32 |
| racarr__ | Yes, greeter is its own | 16:32 |
| racarr__ | mirsrever instance though correct? | 16:32 |
| racarr__ | /it was | 16:32 |
| mterry | racarr__, yes | 16:32 |
| racarr__ | :) | 16:32 |
| mterry | racarr__, but from USC perspective, it doesn't care what the session is, it just wants to stop it from doing anything | 16:33 |
| mterry | maybe I should just send a SIGSTOP... | 16:33 |
| mterry | That actually doesn't sound so dumb... | 16:34 |
| AlbertA | mterry: but that would introduce the same issues we are trying to resolve | 16:34 |
| mterry | Still a bit racy I guess | 16:34 |
| AlbertA | mterry: with non-blocking | 16:34 |
| mterry | AlbertA, this is a specific use case, not a general thing that USC always wants to do | 16:34 |
| mterry | AlbertA, I'm specifically trying to synchronize rendering between two sessions | 16:34 |
| racarr__ | mm...which is making me kind of think there | 16:35 |
| racarr__ | I mean if its literally just a fade | 16:35 |
| racarr__ | then the fade could be done | 16:35 |
| racarr__ | server side | 16:35 |
| racarr__ | with set_alpha | 16:35 |
| AlbertA | mterry: but the problem is the animation will be already over | 16:35 |
| mterry | Not just a fade. Different elements grow and become more opaque, each on their own timer | 16:35 |
| mterry | racarr__, ^ | 16:35 |
| AlbertA | mterry: in the greeter | 16:35 |
| racarr__ | Mm -.- | 16:35 |
| mterry | AlbertA, sorry, how do you mean? | 16:35 |
| AlbertA | mterry: is it just a fade? or some other cutesy stuff? | 16:36 |
| mterry | AlbertA, I mean, that's the problem I have today that I'm trying to solve yeah | 16:36 |
| AlbertA | mterry: I'm thinking more in general terms | 16:36 |
| AlbertA | mterry: that may change in the future | 16:36 |
| mterry | AlbertA, cutesy stuff. Panel drops down from top, clock time grows from 0.8 to 1.0 size and goes from 0 to 1 opacity | 16:36 |
| mterry | clock fades in similarly | 16:36 |
| AlbertA | mterry: yeah that's what I mean, you couldn't do that at the mir server side | 16:36 |
| AlbertA | mterry: qt controls all that | 16:36 |
| AlbertA | mterry: but is it possible for the greeter to start in hide mode (hide in qt sense) | 16:37 |
| mterry | AlbertA, right. But I just want to have USC send a message to the session that says "don't handle any buffers" so that Qt will stop until we unfreeze it | 16:37 |
| AlbertA | mterry: right - but that kinda goes agains the non-blocking decision | 16:37 |
| mterry | AlbertA, I agree as a general thing. But I'm saying there is a specific use case where we do actually want the ability to block | 16:38 |
| racarr__ | this is only in the specific case though, triggered by shell code in USC | 16:38 |
| racarr__ | mm | 16:38 |
| mterry | AlbertA, this isn't about app lifecycle | 16:38 |
| AlbertA | kgunn: mterry: where it was decided that mir would not enforce at all rendering loop behavior implicitly by blocking | 16:38 |
| AlbertA | mterry: I guess if its short lived it should be ok | 16:39 |
| AlbertA | mterry: so you can't tell QT to not render at all when creating the greeter stuff? it always starts rendering no matter what? | 16:40 |
| AlbertA | mterry: just curious | 16:40 |
| mterry | AlbertA, well. I could have the greeter start in frozen mode. But then I'd need a signal to unfreeze it. Which is this same problem, just much more app-specific | 16:41 |
| AlbertA | mterry: plus in any case, it would be hard to do frame level synch transitions to screen | 16:42 |
| mterry | And the problem is really a compositor specific one. Not really greeter-specific. I feel like the abstraction for this belongs in mir compositor code | 16:42 |
| AlbertA | mterry: you most likely would get some black frames at the beginning | 16:42 |
| AlbertA | mterry: maybe if we send transition events to each of the sessions that are transitioning from each other | 16:44 |
| AlbertA | mterry: and we wait until the transition event is acked | 16:44 |
| AlbertA | mterry: like one for being transitioned to | 16:45 |
| AlbertA | mterry: and one for being transitioned out of | 16:45 |
| mterry | AlbertA, it would be useful if a mir client knew it was being transitioned away from (we will eventually want to know this for the tiny boot animation app so it can fade out too) | 16:45 |
| AlbertA | mterry: so we send transition out of - wait until ack - the client receives it | 16:46 |
| mterry | client fades out, acks back | 16:46 |
| AlbertA | mterry: does its cutesy shutdown transition animation, finishes and acks the message | 16:46 |
| mterry | yeah, that would be ideal | 16:46 |
| AlbertA | mterry: and the other client receives transition to | 16:46 |
| AlbertA | mterry: and same deal | 16:46 |
| mterry | AlbertA, except... I'm not sure what we do there. | 16:47 |
| mterry | AlbertA, that seems like a separate problem from being able to freeze it until ready? | 16:47 |
| mterry | AlbertA, the greeter appears before we're ready to transition to it | 16:47 |
| AlbertA | mterry: well maybe we could block until a first ack is received | 16:48 |
| AlbertA | mterry: or something.... | 16:48 |
| AlbertA | mterry: maybe begin transition into | 16:48 |
| AlbertA | mterry: server blocks until begin transition into acks | 16:48 |
| mterry | AlbertA, yeah, we could add a special message for 'freeze' that is part of this set of messages | 16:49 |
| AlbertA | mterry: and only for sessions that have registered for transition notifications | 16:49 |
| tvoss | AlbertA, mterry seems like waiting for the first swap buffers call after the transition has been initiated is the trigger you are looking for here | 17:28 |
| AlbertA | tvoss: yeah that would be more sensible, because waiting for an ack would be "dangerous" for misbehaving clients | 17:30 |
| tvoss | AlbertA, yup, exactly. | 17:30 |
| mterry | tvoss, AlbertA: I do hook into swap_buffers calls. That's how I know a client is ready to display to the screen. But how do I stop the client from doing anything after that point? | 17:37 |
| tvoss | mterry, that would require an occlusion event | 17:38 |
| tvoss | mterry, AlbertA something we would need to add anyway | 17:38 |
| AlbertA | tvoss: yep | 17:40 |
| mterry | tvoss, meaning we don't have that yet, OK | 17:43 |
| tvoss | mterry, yup | 17:43 |
| mterry | tvoss, occlusion being a way to tell a client it isn't actually visible on screen? That sounds exactly the semantics of my situation indded | 17:48 |
| * kdub makes an argument the scene would be the best one to compute occlusion | 17:51 | |
| tvoss | kdub, +1 | 17:57 |
| kdub | i guess though, for max flexibility, the compositor should submit an occlusion scanner or something like that | 17:59 |
| tvoss | mterry, yup, I think we should implement such a fundamental feature "the right way" (tm) :) Out of curiosity: why isn't the usc process lifecycled and thus stopped by usc? | 17:59 |
| mterry | tvoss, you mean why isn't the greeter process lifecycled? | 18:00 |
| mterry | tvoss, I tried using lifecycle events for this, but they didn't do what I wanted. Maybe because I'm still testing with mir 0.1.8 | 18:00 |
| mterry | tvoss, but even if they did do what I wanted, I hear that the sidechannel is 'racy' in the sense that the client may still render some frames before being lifecycled | 18:00 |
| mterry | tvoss, and ideally this would be frame-perfect | 18:01 |
| tvoss | mterry, that is surely the case, but then: we expect clients receiving a lifecycle event to prepare a "final" good rendering | 18:02 |
| mterry | tvoss, but in this case, I'm not sure that makes sense. That would mean having the greeter 'reset' itself to frame zero if it gets a suspend event near the beginning of its lifespan? Seems finicky | 18:16 |
| mterry | or maybe just any suspend event. I suppose we could redo the animation on screen wake too... | 18:17 |
| tvoss | mterry, so is that a viable option for you? | 18:17 |
| mterry | tvoss, I think so...? Let me look into it | 18:20 |
| tvoss | mterry, ack, drop me a mail with your ideas/thoughts, so we can pick up the discussion tomorrow | 18:20 |
| anpok | kdub: +1 - for flexibility you could add an optional - filterfilter that resurrects false negatives.. | 19:13 |
| kdub | i'm always very pleased when I get to do matrix stuff | 20:40 |
| kdub | 'all that math was worth it!' :P | 20:40 |
| racarr__ | You mean like dodging bullets, etc? | 20:41 |
| racarr__ | :p | 20:41 |
| kdub | lol | 20:45 |
| === beidl_ is now known as beidl | ||
| kgunn | interesting...i've been testing xmir w/ non-blocking swap all day...and comparing to good ol' x | 21:13 |
| kgunn | i don't think x today works the way duflu says... | 21:13 |
| kgunn | i find plenty that still renders when occluded and screen blank even in x | 21:13 |
| racarr__ | I agree re: occlusion | 21:18 |
| racarr__ | thought screen off would block swap buffers in composited GLX/compiz but who knows | 21:19 |
| anpok | hmm .oO(X11 terrible times .. years ago when I once messed with xlib - I never managed to properly treat the expose and damage events) | 21:22 |
| racarr__ | lol | 21:26 |
| RAOF | racarr__: Yo! | 23:40 |
| RAOF | racarr__, kgunn_: Whether or not screen off blocks GLX_swap_buffers is driver dependent! | 23:44 |
| RAOF | Yay! | 23:44 |
| racarr__ | RAOF: Morning! | 23:51 |
| RAOF | racarr__: And a fine Easter Monday to you! | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!