[00:32] <RAOF> Really, gcc? If you use C++, even if you intend to expose a purely C ABI, you are compelled to expose random std:: detritus too?
[01:46] <RAOF> Why, hello there!
[01:46] <RAOF> Quite clearly nobody actually suse the mir_debug_* symbols, because they're mangled.
[02:08] <duflu> RAOF: Umm, worthy of a bug report maybe
[02:09] <RAOF> Or I'll just fix it.
[02:09] <duflu> Or both at once...
[02:09] <duflu> If it never worked then it's not a regression. If no one ever used it then maybe not important enough to be a bug :)
[07:09] <duflu> Hey gdb understands STL containers now and makes them readable
[07:09] <duflu> that's new
[07:18] <RAOF> Oh, the python support got fixed?
[07:26] <anpok_> @duflu: https://bugs.launchpad.net/mir/+bug/1275398 afaik this is the issue with i915 using a slightly different init code in mesa than the newer intel. so it needs some mir love
[07:26] <duflu> anpok_: Please apply love where appropriate
[07:26] <duflu> Umm.
[07:26] <duflu> You know what I mean
[07:26] <anpok_> :)
[07:27] <anpok_> i am strugling still with qxl
[07:27] <anpok_> it does page flip
[07:27] <anpok_> it seems to drop the page flip event to the event queue
[07:28] <anpok_> user space seems to get woken up but there is no page flip event
[08:07] <alan_g> RAOF: @"we don't want to install these into the global library search path" - if not then how does client code access the symbols in e.g. libmirplatform?
[08:08] <RAOF> Via libmirserver?
[08:08] <RAOF> We currently dlopen them from libmirserver, right?
[08:09] <RAOF> Then the (server) client code never needs to directly link against libmirplatform?
[08:09] <alan_g> Nope. The point of libmirplatform being LGPL is that it doesn't require client code to link against the GPL libmirserver
[08:10] <alan_g> BTW I like the idea of introducing .symbols
[08:11] <RAOF> Ooooh!
[08:11] <alan_g> we do dlopen [mesa|android]/libmirplatformgraphics.so - so it could work for those
[08:11] <RAOF> By “client code” in this case you mean “platform drivers”?
[08:12] <alan_g> For this example, yes
[08:12] <RAOF> What else is going to require symbols from libmirplatform, and not also link with libmirserver?
[08:13] <alan_g> true. But by "client code" I mean drivers, servers, client, etc
[08:13] <RAOF> There's a separate libmircilentplatform, right?
[08:14] <alan_g> There is
[08:15] <RAOF> Anyway, the answer to the question “where would they get their symbols from” is “from the thing that's dlopening() them”
[08:15]  * alan_g is still confused why some things are .so and some are not.
[08:16] <RAOF> I think the state we _want_ to be in is having exactly two SOs - libmirserver.so and libmirclient.so
[08:17] <alan_g> For servers & clients maybe. But drivers introduce a third case
[08:18] <alan_g> And I would prefer to share common code than link it into all three.
[08:20] <alan_g> Or four if there's really a good reason for libmirclientplatform.so being different from libmirplatform.so
[08:20] <RAOF> Drivers don't need to link against anything Mirish; they get dlopen()ed, so they always have the symbols available.
[08:21] <RAOF> Drivers are never useful outside the context of a mirserver instance
[08:21]  * RAOF is somewhat foggy, so may in future disown current statements :/
[08:22]  * alan_g is not going to argue now but doesn't feel quite convinced
[08:23] <RAOF> I'm a bit annoyed that libstdc++ means that libmirclient exports >1000 symbols, rather than the ~10 or so we *actually* want to export.
[08:25] <duflu> RAOF: Yeah I was wondering how you were going to solve the template problem. Particularly since libmirserver needs many of the template instance symbols exported
[08:26] <alan_g> I think it's a lot more than 10 (but a lot more less than 1000)
[08:26] <duflu> I think you will find it will be higher than 1000, I expect
[08:26] <duflu> Templates are evil things
[08:28] <duflu> A tip for counting unique templates: Search for "::~" to identify unique destructors
[08:28] <RAOF> alan_g: Yeah, more like 50, true.
[08:29] <RAOF> duflu: I gave up touching libmirserver. Practically every cpp file is a part of the ABI there.
[08:30]  * RAOF started trying to hide what look like purely internal classes, but it turns out that they're not purely internal.
[08:30] <duflu> RAOF: I think a better place to start on mirserver is search the headers. You can quickly find a bunch of classes/headers that are unreachable by the public interfaces
[08:31] <duflu> "unreachable" meaning we don't provide any APIs for people to access instances of said classes
[08:31] <alan_g> RAOF: my feeling is that libmir[client]platform is already stable (if not pretty) and a better measure for driver compatibility than the volatile server ABI
[08:31] <RAOF> duflu: That's what I did; it's not true that they're unreachable by public interfaces.
[08:32] <duflu> RAOF: Well, some, not all, obviously
[08:32] <RAOF> I don't think any of them are unreachable by public interfaces, actually.
[08:33] <duflu> RAOF: There used to be plenty. But I haven't made a stab at it for a long time
[08:33] <RAOF> At least by my criterion of ‘if I apply visibility=hidden to this class, does everything link?’
[08:33] <duflu> Given the number of headers has increased, I doubt they're all actually needed in public now
[08:34] <alan_g> RAOF: meaning tests that access "internal" classes?
[08:34] <duflu> RAOF: Obviously Mir needs those headers. I'm talking about headers no external project wants/can utilize
[08:34] <RAOF> alan_g: No, meaning mir_demo_server.
[08:34] <anpok_> well we can safely hide those not in include
[08:34] <anpok_> oh
[08:34] <RAOF> anpok_: Ba baw! Incorrect!
[08:35] <anpok_> our examples do that?
[08:35] <duflu> Because we rejected the idea of separating "shared" headers from "public"
[08:35] <alan_g> We should be able to hide those not in include
[08:35] <RAOF> anpok_: Because we expect people to derive from DefaultServerConfiguration, so everything that DefaultServerConfiguration touches needs to be public.
[08:35] <RAOF> And by ‘public’ I mean “linkable to”.
[08:35] <duflu> Ah the ServerConfiguration beast
[08:36] <alan_g> Why?
[08:36] <anpok_> RAOF: sure? but for those forward decls should sufficient
[08:36] <RAOF> Not at link time.
[08:36] <anpok_> +be
[08:36] <duflu> Although public projects only need access to classes used in public methods of *ServerConfiguration
[08:37] <duflu> I mean used in public declarations
[08:37] <alan_g> RAOF: yes, at link time
[08:37] <RAOF> You can't have an object with fields that have visibility less than the object.
[08:37] <alan_g> But the fields only need the forward decls
[08:38] <duflu> Sounds like we may have exposed too much info in *server_configuration.h"
[08:38] <alan_g> Certainly more than I think we do
[08:39] <RAOF> So, empirically, if you stick a bunch of visibility=hidden attributes on classes with headers in src/server, mir_demo_server_* cannot link.
[08:41] <alan_g> We *should* be able to do that. I don't think the root cause is DefaultServerConfiguration - but will need to investigate.
[08:41] <RAOF> Because the class derived from DefaultServerConfiguration needed a bunch of symbols.
[08:41] <duflu> camako: The merge will be instantly redundant if we shuffle the development focus back to 0.5. We can now that 0.5 actually has a branch
[08:41] <RAOF> Yeah, I'll push this branch at some point.
[08:42] <duflu> camako: And then there's no waiting for Jenkins ;)
[08:44] <RAOF> Here we go...
[08:45] <RAOF> CMakeFiles/mir_demo_server_shell.dir/__/server_configuration.cpp.o:(.data.rel.ro._ZTCN3mir8examples19ServerConfigurationE0_NS_26DefaultServerConfigurationE[_ZTVN3mir8examples19ServerConfigurationE]+0x2d0): undefined reference to `mir::DefaultServerConfiguration::the_input_registrar()'
[08:45] <RAOF> And a thousand others.
[08:45] <RAOF> But EOD for me here.
[08:46] <alan_g> RAOF: goodbye. (But that is a function in DefaultServerConfiguration, not something the function "touches".
[08:46] <alan_g> )
[08:55] <camako> duflu, I see your point. However, we have already suffered and are in the final stretch (packages built).
[08:56] <camako> There is an ongoing discussion on configuring jenkins for the rtm.
[08:56] <camako> Meaning two distros..
[08:56]  * camako feels our problems will be addressed soon 
[08:57]  * alan_g admires the optimism of youth
[08:57] <duflu> camako: Well the preferable solution would be for distro to actually use the distro configuration and build from the correct upstream branch  :)  https://launchpad.net/ubuntu/+source/mir
[08:57]  * camako hasn't considered himself as "youth" in a very long time.. But thanks..
[08:57] <duflu> That was previously "nice to have" but with two distros, probably now required
[08:58] <camako> duflu, yes... That's why I'm "optimistic"
[08:58] <camako> dednick, I'm assuming you've seen kgunn's email?
[08:59] <camako> Can we push for landing silo 18, or do you need to fix smth?
[09:00] <dednick> camako: just read now
[09:00] <dednick> camako: give me a sec
[09:01] <camako> sure
[09:01] <sil2100> o/
[09:02] <camako> duflu, thanks for updating the changelog...
[09:05] <dednick> camako: give me a about 15 minutes to give the silo a quick test
[09:05] <camako> dednick, sounds good... Take your time... I've yet to finish testing myself..
[09:23] <greyback> alf_: I'm beginning to suspect that the reason for the slowdown is the fact, while before the job of actual rendering & buffer management was split between a mir compositor and the Qt renderer, now Qt's renderer thread is rendering but also is managing buffers
[09:24] <alf_> greyback: I took some new traces this morning, and one thing I noticed is that at the start rendering the dash takes ~1000 calls, but after visiting "copes" and going back
[09:25] <alf_> greyback: ... "Scopes" scope and going back it increases to over 1500, trying to figure out what the diff is
[09:25] <greyback> alf_: I think that's because the contents of an off-screen scope are still being rendered
[09:26] <greyback> alf_: I've pushed a patch to improve things, it should have landed by now
[09:26] <alf_> greyback: which package?
[09:26] <greyback> alf_: unity8, from the silo6
[09:27] <duflu> That's fun. Callgrind says we make a quarter of a million fread calls to load X cursors
[09:27] <greyback> alf_: Qt's scenegraph renderer does not do off-screen culling
[09:27] <alf_> greyback: :/
[09:27] <anpok> greyback: if we make those buffers opaque?
[09:27] <anpok> then still  no culling?
[09:28] <greyback> well it's a big cost for a large scenegraph, and a good developer can more easily manually manage the visibility of components
[09:29] <greyback> alf_: a nice way to visually see these off-screen things is to run unity8 with QSG_VISUALIZE=overdraw
[09:29] <greyback> anpok: sorry, I didn't follow that. Which buffers opaque? Other apps I guess you mean?
[09:29] <alf_> greyback: also I noticed that even in the best case when things are "smooth", the dash is consistenly above 16ms (20-30ms), and in the worst case (judder) it's about (40-50), so there is some serious work to be done there regardless of this particular issue
[09:30] <greyback> anpok: yeah making them opaque would help
[09:30] <greyback> alf_: yep
[09:30] <greyback> alf_: dash is doing lots of work, and lots of bad things
[09:31] <greyback> and as a result qt isn't able to optimise much
[09:32] <alf_> greyback: "actual rendering & buffer management" how do you mean that?
[09:34] <alf_> greyback: in theory QtCompositor should be more efficient, since it's rendering directly to the mir provided framebuffer instead of on a surface which is then composited by the default mir renderer (which I think was happening before QtComp?)
[09:36] <greyback> alf_: correct. I just had the idea last night that we've taken the jobs of 2 threads and combined them into 1 (removing GLRenderer though)
[09:37] <alf_> greyback: hmmmmm
[09:37] <anpok> the full screen blend blocked the caller for around 2 ms on nexus4
[09:38] <greyback> anpok: the thing is, we see performance drop with zero apps open. So that is Qt rendering directly to the mir provided framebuffer
[09:41] <alf_> greyback: you may be right, in the sense that because we are rendering in the thread that blocks for the page flip, the effect of missing a frame boundary are more pronounced
[09:43] <anpok> wasnt there an option to move eglSwapBuffers to another therad in Qt?
[09:44] <greyback> anpok: that is enabled (the renderer runs in a separate thread per window - per display *I think* - separate to the GUI thread)
[09:44] <alf_> greyback: anpok: it's not that they are in the same thread, it's also that previously because we rendered to a surface first, we had a buffer to ease frame boundary misses
[09:44] <anpok> i thought there was another one that also moves eglswap to a third
[09:46] <alf_> greyback: anpok: but this is just on the top of my head, no hard facts to back it up
[09:46] <alf_> greyback: anpok: off the top ...
[09:53] <alf_> greyback: your new unity8 build is much better in terms of gl calls per frame
[10:00] <greyback> alf_: yeah, but you can still experience jank when switching between apps & scopes scope
[10:01] <greyback> so not perfect
[10:09] <alf_> greyback: you mean while switching between the two, or after switching to scopes and back to apps again
[10:09] <alf_> ?
[10:11] <greyback> alf_: if I just go back & forth between the 2, it seems to slow a bit
[10:11] <greyback> expecially with a certain flick
[10:15] <duflu> Good news. I shall leave you today with nothing new to propose
[10:16] <greyback> \\o/
[10:17] <greyback> duflu: oh to continue our custom to belatedly admit we've not done anything wrt window management: I've not done anything wrt window management recently
[10:17] <duflu> greyback: Awesome-tastic
[10:17] <duflu> greyback: Me too but only because RTM trumps WM
[10:18] <alf_> greyback: hmm, that's to be expected I guess... during the transition we are rendering both scopes. Each scope separately fails to meet the deadline, both scopes together make a complete mess
[10:18]  * duflu has another idea and fails to log off...
[10:18] <greyback> alf_: yep
[10:19] <greyback> alf_: but at least a probably solution is in the pipeline: split Dash out of shell so it is a separate process
[10:19] <greyback> s/probably/probable/
[10:19] <greyback> well "solution"
[10:20] <greyback> it'll still render slowly
[10:20] <alf_> greyback: Has something changed in this area in QtComp? Is nonQtComp somehow convincing QtSG to render only parts of the SG?
[10:20] <greyback> but the frame boundary missing would be more forgiving - if that theory is right (I'm convinced)
[10:21] <duflu> Ah. Input latency reduced ten-fold. If only we could do that on the phone.
[10:21] <alf_> greyback: is split-dash scheduled for rtm?
[10:21] <alf_> duflu: how and what's blocking this on the phone?
[10:22] <duflu> alf_: Framedropping. And the fact that Qt apparently lacks throttling to be able to use it safely
[10:26] <greyback> alf_: yes
[10:28] <greyback> duflu: call me ignoramus: input throttling? Is that compressing a large number of events into a single event, to reduce the amount of events a client has to process? Or something else?
[10:28] <duflu> greyback: Could refer to different things. Where's it written?
[10:29] <greyback> duflu: I dunno, I saw you write it, I wanted to know what you were referring to
[10:30] <duflu> greyback: Oh. I did notice with strong suspicion though that Android-input seems to group and discard input events depending on how fast you consume them. Really fast renders get more events. Slow renderers get less, but at least don't get progressively more behind
[10:31] <greyback> duflu: ok, that's interesting
[10:32] <duflu> greyback: So fingerpaint for example always keeps up with the current pointer location, but a fast renderer (frame dropping) sees many more samples... smoother curves
[10:32] <duflu> I know for a fact my mouse generates around 1000 events per sec. Mir is certainly not getting most of them
[11:10] <camako> dednick, the silo is testing well for me. How is it on your side?
[11:10]  * camako saw some msgs between alan_g and tvoss
[11:10] <camako> and dednick
[11:18] <dednick> camako: silo working for me. tvoss having some issues, but don't think it's directly related.
[12:15] <greyback> alf_: I'm getting more & more convinced by your frame boundary explanation
[12:17] <alf_> greyback: convinced by experiments or by thinking about it? :)
[12:17] <greyback> alf_: I've no proper data, more just thinking about it
[12:19] <alf_> greyback: btw, QSG_VISUALIZE and its various options are very neat... and the dash sucks at batching (33 alpha-enabled batches, 2 opaque) :/
[12:19] <greyback> alf_: I know, it's horrible
[12:20] <greyback> alf_: totally defeating the batching optimisation
[12:20] <greyback> explains why scrolling so severe on CPU and GPU
[12:23] <alf_> greyback: Do you think there is an easy way with the QtComp codebase to test the frame boundary theory?
[12:28] <greyback> alf_: possibly by comparing frame render & frame delta times between QtComp & non-QtComp
[12:28] <greyback> QSG_RENDER_TIMING *might* give enough info, else QSG_RENDERER_DEBUG=render
[12:29] <greyback> would also need to compare the same complex scene for both cases
[14:19] <Saviq> hey guys, got a gift for you - client crash on exit bug #1342694
[14:19] <Saviq> it *could* potentially be qtubuntu, too
[14:37] <AlbertA> Saviq: it's being discussed... I think alan_g just root caused it
[14:37] <Saviq> coolz
[20:04] <racarr__> Would appreciate thoughts on https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242
[20:04] <racarr__> once it or something similar lands can go around and add cursor support to qt, chromium, gtk, etc...
[20:06] <racarr__> + any problem with landing https://code.launchpad.net/~mir-team/mir/improve-attribute-protocol-and-normalize-getters/+merge/225912
[20:11] <racarr__> opinions on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731 probably more important than cursor
[20:15] <racarr__> opinions on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731 probably more important than cursor
[20:15] <racarr__> whoops
[21:00] <racarr__> how to share acceptance tests with unity-mir/qtmir/mirqt/gerry
[21:00] <racarr__> beyond copy pasting code
[21:00] <racarr__> ive been thinking though there are a lot of tests
[21:01] <greyback> racarr__: I'm open to ideas
[21:01] <racarr__> that should be run against
[21:01] <racarr__> the shell server configuration
[21:01] <greyback> racarr__: also note I've not had the time to make any of the changes you suggested yet. So don't be offended if it appears I just ignored you:)
[21:01] <racarr__> no worries I havent done a second pass through yet. um.
[21:02] <racarr__> I dont think any of them are in particular important to prevent landing.
[21:02] <racarr__> i.e. I expect a read through of unity-mir
[21:02] <racarr__> would turn up about just as much
[21:02] <greyback> could you make a gdoc and put your review comments in there please? Easier to deal with than an email thread IMO
[21:02] <racarr__> I kind of tried to identify things that we may want to fix asap though.
[21:02] <greyback> oh sure, most of the same mistakes are probably there :)
[21:02] <racarr__> like...I had kind of forgotten that screencast authorization was never implemented
[21:02] <racarr__> lol
[21:03] <racarr__> ok will
[21:03] <racarr__> google doc it up
[21:03] <greyback> with QtComp, I need to disable it, as it won't work
[21:03] <greyback> until I combine Qt's renderer with Mir's interface properly
[21:04] <racarr__> haha right...
[21:04] <racarr__> we need proper permissions for display config at least
[21:04] <racarr__> or
[21:04] <racarr__> maybe both are just always disabled on the phone
[21:04] <racarr__> and there is
[21:05] <greyback> I've no idea how shell mediates that. We've not had that discussion
[21:05] <racarr__> developer mode :p
[21:05] <racarr__> always disabled + developer mode to always enable
[21:05] <racarr__> is better than
[21:05] <racarr__> always allowed though
[21:06] <greyback> oh apparently I was wrong, we do send clients focus/unfocus events
[21:07] <racarr__> :)
[21:08] <racarr__> https://code.launchpad.net/~mir-team/mir/improve-attribute-protocol-and-normalize-getters/+merge/225912
[21:08] <racarr__> last chance to object pre landing
[21:12] <greyback> racarr__: why does a setter return the type that is set?
[21:12] <greyback> + MirSurfaceType set_type(MirSurfaceType t);
[21:13] <racarr__> greyback: hmm no real reason atm...the exception throw
[21:13] <racarr__> used to be in configure instead of set_*
[21:14] <racarr__> I guess there is some thought that the logic is like
[21:14] <greyback> racarr__: it's a weird api IMO, as when I set something, I've to check if the value returned is actually the one I set. Else I cannot trust it
[21:14] <racarr__> well
[21:14] <racarr__> they are private
[21:14] <racarr__> the public api is
[21:14] <racarr__> int configure(int, int) lol
[21:15] <greyback> that's a crappy API and you know it
[21:15] <racarr__> lol which part
[21:15] <greyback> why not just export these private methods?
[21:15] <greyback> ABI stability?
[21:15] <racarr__> well as it stands the only user is frontend which is
[21:15] <greyback> me
[21:15] <racarr__> happy with the ints.
[21:16] <racarr__> ?
[21:16] <greyback> eh. I'm trying to be a vocal API consumer
[21:16] <racarr__> haha.
[21:16] <greyback> configure(int,int) is an unpleasant way to set properties on something
[21:17] <greyback> aside from that, I like your changes
[21:17] <racarr__> I think, as needed/requested, setters and getters can be added for specific properties....some of them have public getters
[21:17] <racarr__> I guess configure/query is really the API to frontend
[21:17] <racarr__> and the API to shell
[21:17] <racarr__> has been ignored lol
[21:19] <greyback> nice :P
[21:20] <racarr__> I hope I make sense...I may literally be the most tired I have ever been right now
[21:20] <racarr__> the good news. No niccotine in 5 days!
[21:21] <racarr__> and i...enjoyed the whole process this time
[21:21] <racarr__> and am pretty confident that I am over it
[21:21] <racarr__> the bad news. no proper sleep in 5 days!
[21:23] <greyback> keep it up man, you can do it
[21:23] <racarr__> I think tonight is finally my night just due to sheer and total exhaustion.
[21:23] <racarr__> :D Thanks
[21:23] <greyback> I'm not in any hurry for you to do anything (think I'm the bottleneck right now)
[21:24] <greyback> so if you need to snooze, go for it
[21:24] <racarr__> I...none of it makes me want to smoke lol im just so tired atm hard to tell things make sense
[21:25] <racarr__> haha, nah, gotta power through until the sun goes down at least lol
[21:25] <racarr__> Think I am going to distract myself with low brain power acceptance testing.
[21:25] <greyback> :)