[01:34] <RAOF> Hm. Keyboard input is not _quite_ correct :)
[02:18] <robert_ancell> 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] <robert_ancell> or duflu ^
[02:20] <robert_ancell> 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] <robert_ancell> why not just rendering in mir_surface_get_graphics_region?
[02:21] <robert_ancell> why not just render into mir_surface_get_graphics_region I mean
[02:23] <duflu> 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] <duflu> 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] <robert_ancell> duflu, mir_surface_get_graphics_region returns a new buffer right? And that is valid until mir_surface_swap_buffers is called?
[02:25] <duflu> robert_ancell: Sounds right...?
[02:25] <duflu> robert_ancell: Also, fingerpaint does that copy so it can remain dumb and not handle resizing :)
[02:25] <robert_ancell> ok
[02:25] <duflu> .. whilst not deleting your painting
[02:26] <robert_ancell> 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] <duflu> robert_ancell: Given single-buffering support, fingerpaint wouldn't need that second malloc'd buffer
[02:27] <robert_ancell> duflu, so what happens in swap_buffers when you're single buffered?
[02:27] <duflu> robert_ancell: The latter issue is unfortunately a feature of OpenGL and many other graphics systems
[02:27] <duflu> 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] <robert_ancell> and there'd be no swapping :)
[02:28] <duflu> On the other hand, fingerpaint would still need the copy/other buffer to resize as well as it does now
[02:29] <duflu> 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] <robert_ancell> in the case of buffers != 2
[02:30] <duflu> Yes single too
[02:30] <robert_ancell> you should stop propogating the madness via the API...
[02:31] <robert_ancell> 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] <duflu> 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] <robert_ancell> finish?
[02:31] <robert_ancell> post?
[02:31] <robert_ancell> mark_ready?
[02:32] <duflu> robert_ancell: Actually there is a "hide" flag in the server. We presently lack client API to access it :)
[02:32] <robert_ancell> duflu, any reason not to expose it?
[02:32] <duflu> robert_ancell: Also, the compositor won't show your window till you've finished the frame (swapped)... so no problem?
[02:32] <robert_ancell> ah, ok
[02:33] <duflu> robert_ancell: It's always hidden till one whole frame is finished
[02:33] <robert_ancell> duflu, we're double buffered by default right?
[02:33] <duflu> robert_ancell: Triple, everywhere
[02:34] <duflu> I'm working to re-enable double, but it requires lots of smarts to switch on demand
[02:34] <robert_ancell> so I shouldn't be able to add any flickering
[02:34] <robert_ancell> as long as my buffer contents are correct
[02:34] <duflu> robert_ancell: No, flickering/tearing is impossible (tm)
[02:34] <robert_ancell> I like that
[02:35] <duflu> ... because the client is always drawing to a different buffer to that which is on screen
[02:35] <robert_ancell> duflu, do you get events on a surface before the first frame is drawn?
[02:36] <robert_ancell> duflu, and the triple buffer is so you can swap at any time without getting caught when the CRTC is reading out
[02:37] <RAOF> 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] <RAOF> But they need to go to quite some lengths to do that :)
[02:38] <robert_ancell> RAOF, yeah, there's no API to hold onto a reference is there?
[02:39] <RAOF> 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] <robert_ancell> yeah, I'm not going to do that
[02:39] <RAOF> But you can't easily draw to that fd :)
[02:42] <duflu> It would require a lot of madness, similar to XMir :)
[02:43] <robert_ancell> any ideas on if events get delivered to surfaces that haven't been shown?
[02:43] <duflu> robert_ancell: I think a surface could get events immediately before it is composited. But I'm not sure what events...
[02:44] <robert_ancell> I supose it could get resized
[02:44] <duflu> Yes, the server/shell is free to resize at will. And the client has no choice
[02:44] <duflu> for now
[02:47] <robert_ancell> for ever
[02:47] <robert_ancell> You hope the shell is well behaved but it can do anything right?
[03:17] <duflu> 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] <robert_ancell> RAOF, is buffer age only supported on some backends? Why is it part of NativeBufferPackage and not in the main client API?
[03:36] <RAOF> buffer age should be supported for all backends.
[03:36]  * RAOF looks.
[03:38] <robert_ancell> I was expecting something like mir_surface_get_buffer_age ()
[03:38] <robert_ancell> Hmm, I was assuming that NativeBuffer is not something you'd use for "normal" clients. Is that not the case?
[03:39] <robert_ancell> yes, because it would be something entirely different on Android
[03:39] <RAOF> Well, for normal clients you'd use EGL, and we'd expose buffer age that way.
[03:40] <RAOF> (Note: We do not yet expose buffer age through EGL_EXT_buffer_age ☺)
[03:40] <robert_ancell> ha!
[04:09] <RAOF> Bargh.
[04:09] <RAOF> Why is INPUT_RECEIVER_REPORT=log going nowhere?
[04:16] <robert_ancell> See y'all in Malta
[04:36] <RAOF> 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] <racarr__> RAOF: Rootless X?!
[04:39] <RAOF> racarr__: Indeed.
[04:39] <racarr__> yay
[04:40] <RAOF> It's hacked up at the moment, so uuugly (and has probably broken rooted mode)
[04:40] <RAOF> But I should learn how to mir_screencast
[04:40] <RAOF> ;)
[05:18] <duflu> RAOF: I think the actual making video instructions are buried in email threads somewhere
[05:19] <duflu> which I can't access as I am busy transferring to the laptop
[05:20] <duflu> RAOF: https://lists.ubuntu.com/archives/mir-devel/2014-February/000650.html
[06:20] <RAOF> Good, good. Making mir_surface_is_valid unconditionally return false does make some tests fail.
[09:37] <alf_> 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] <alf_> anpok: I could imagine using a more focused class for this purpose (but I am not familiar with the details)
[09:39] <alf_> anpok: are these going through the server main loop, or will we have a different object?
[12:23] <anpok> alf_: they do not have to go through the server main loop
[12:55] <anpok> alf_: https://code.launchpad.net/~andreas-pokorny/mir/unregister-fd-handler/+merge/220571/comments/528020
[15:16] <mterry> 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] <greyback> mterry: I'm just about to head to airport, I'll try to review while in the lounge
[21:00] <racarr__> hmm
[21:00] <racarr__> the dithering is wrong
[21:01] <racarr__> in unity8-mir on my new
[21:01] <racarr__> laptop
[21:01] <racarr__> or
[21:01] <racarr__> something
[21:01] <racarr__> insane banding