[01:34] Hm. Keyboard input is not _quite_ correct :) [02:18] RAOF, there's no way in Mir to get a surface to render to that's not visible is there? i.e. surfaces are always mapped [02:19] or duflu ^ [02:20] actually duflu. I was wondering why your Mir client examples render into a malloc'd buffer before copying into the one returned from mir_surface_get_graphics_region [02:20] why not just rendering in mir_surface_get_graphics_region? [02:21] why not just render into mir_surface_get_graphics_region I mean [02:23] robert_ancell: Buffers are not preserved. At least not unless guaranteed by buffer_age semantics. And if you do use buffer age then you still have to track N different buffers yourself in the toolkit/client [02:24] Also, when I wrote fingerpaint, software clients were GPU-backed, not SHM. So reading back from a buffer was slower than it is now. [02:24] duflu, mir_surface_get_graphics_region returns a new buffer right? And that is valid until mir_surface_swap_buffers is called? [02:25] robert_ancell: Sounds right...? [02:25] robert_ancell: Also, fingerpaint does that copy so it can remain dumb and not handle resizing :) [02:25] ok [02:25] .. whilst not deleting your painting [02:26] the names are really confusing - get_backend seems to imply that you're getting some singleton and swap buffers implies there are two buffers [02:26] robert_ancell: Given single-buffering support, fingerpaint wouldn't need that second malloc'd buffer [02:27] duflu, so what happens in swap_buffers when you're single buffered? [02:27] robert_ancell: The latter issue is unfortunately a feature of OpenGL and many other graphics systems [02:27] robert_ancell: It would just tell the server to start displaying a new frame, and you pray (or time it carefully) to minimize client drawing at the same time. It would tear, but in some clients like fingerpaint not visibly [02:28] and there'd be no swapping :) [02:28] On the other hand, fingerpaint would still need the copy/other buffer to resize as well as it does now [02:29] robert_ancell: Yes, "swap" as a verb is misleading in the world of 3 or more buffers. But that's a common misnomer of OpenGL and all modern graphics systems [02:29] in the case of buffers != 2 [02:30] Yes single too [02:30] you should stop propogating the madness via the API... [02:31] duflu, so my initial problem was GTK+ wants to start rendering before it's shown the window - is the only way to do this to rendering into some malloc'd memory (like in fingerpaint) and copy that into the graphics region once the window is shown? [02:31] robert_ancell: It was discussed, but no one has a better verb in mind. Particularly since the word "swap" is already known to graphics programmers [02:31] finish? [02:31] post? [02:31] mark_ready? [02:32] robert_ancell: Actually there is a "hide" flag in the server. We presently lack client API to access it :) [02:32] duflu, any reason not to expose it? [02:32] robert_ancell: Also, the compositor won't show your window till you've finished the frame (swapped)... so no problem? [02:32] ah, ok [02:33] robert_ancell: It's always hidden till one whole frame is finished [02:33] duflu, we're double buffered by default right? [02:33] robert_ancell: Triple, everywhere [02:34] I'm working to re-enable double, but it requires lots of smarts to switch on demand [02:34] so I shouldn't be able to add any flickering [02:34] as long as my buffer contents are correct [02:34] robert_ancell: No, flickering/tearing is impossible (tm) [02:34] I like that [02:35] ... because the client is always drawing to a different buffer to that which is on screen [02:35] duflu, do you get events on a surface before the first frame is drawn? [02:36] duflu, and the triple buffer is so you can swap at any time without getting caught when the CRTC is reading out [02:37] duflu: That's not _strictly_ accurate; misbehaving clients can tear, because they can keep a reference to the buffer they've submitted and continue drawing to it. [02:38] But they need to go to quite some lengths to do that :) [02:38] RAOF, yeah, there's no API to hold onto a reference is there? [02:39] Well, you can get the current buffer package, which contains (among other things) the fd for the current buffer and then use that fd whenever you want. [02:39] yeah, I'm not going to do that [02:39] But you can't easily draw to that fd :) [02:42] It would require a lot of madness, similar to XMir :) [02:43] any ideas on if events get delivered to surfaces that haven't been shown? [02:43] robert_ancell: I think a surface could get events immediately before it is composited. But I'm not sure what events... [02:44] I supose it could get resized [02:44] Yes, the server/shell is free to resize at will. And the client has no choice [02:44] for now [02:47] for ever [02:47] You hope the shell is well behaved but it can do anything right? [03:17] robert_ancell: Maybe forever, don't know. Some clients might want to specify resize hints like "increments of a character" (terminal apps) or "fixed aspect ratio" (video) [03:36] RAOF, is buffer age only supported on some backends? Why is it part of NativeBufferPackage and not in the main client API? [03:36] buffer age should be supported for all backends. [03:36] * RAOF looks. [03:38] I was expecting something like mir_surface_get_buffer_age () [03:38] Hmm, I was assuming that NativeBuffer is not something you'd use for "normal" clients. Is that not the case? [03:39] yes, because it would be something entirely different on Android [03:39] Well, for normal clients you'd use EGL, and we'd expose buffer age that way. [03:40] (Note: We do not yet expose buffer age through EGL_EXT_buffer_age ☺) [03:40] ha! [04:09] Bargh. [04:09] Why is INPUT_RECEIVER_REPORT=log going nowhere? [04:16] See y'all in Malta [04:36] Ok. So, that's correct rendering and inputish, but I need to deal with the “receives swap_complete events for dead surfaces” thing. [04:38] RAOF: Rootless X?! [04:39] racarr__: Indeed. [04:39] yay [04:40] It's hacked up at the moment, so uuugly (and has probably broken rooted mode) [04:40] But I should learn how to mir_screencast [04:40] ;) [05:18] RAOF: I think the actual making video instructions are buried in email threads somewhere [05:19] which I can't access as I am busy transferring to the laptop [05:20] RAOF: https://lists.ubuntu.com/archives/mir-devel/2014-February/000650.html [06:20] Good, good. Making mir_surface_is_valid unconditionally return false does make some tests fail. === fginther` is now known as fginther [09:37] anpok: @unregister-fd-handler, I wonder if using the main loop mechanism to handle the FDs for input is the way to go. Do we need total serialization of the messages? [09:38] anpok: I could imagine using a more focused class for this purpose (but I am not familiar with the details) [09:39] anpok: are these going through the server main loop, or will we have a different object? === marlinc_ is now known as marlinc [12:23] alf_: they do not have to go through the server main loop === ara is now known as Guest58311 [12:55] alf_: https://code.launchpad.net/~andreas-pokorny/mir/unregister-fd-handler/+merge/220571/comments/528020 === jono is now known as Guest70896 [15:16] greyback, got several related branchs for split I would love a review on today: https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718 https://code.launchpad.net/~mterry/qtubuntu/greeter-is-shell/+merge/220543 and https://code.launchpad.net/~mterry/unity-mir/dont-hide-focused-apps/+merge/220130 [15:16] mterry: I'm just about to head to airport, I'll try to review while in the lounge === chihchun is now known as chihchun_afk [21:00] hmm [21:00] the dithering is wrong [21:01] in unity8-mir on my new [21:01] laptop [21:01] or [21:01] something [21:01] insane banding