/srv/irclogs.ubuntu.com/2014/07/16/#ubuntu-mir.txt

RAOFReally, gcc? If you use C++, even if you intend to expose a purely C ABI, you are compelled to expose random std:: detritus too?00:32
RAOFWhy, hello there!01:46
RAOFQuite clearly nobody actually suse the mir_debug_* symbols, because they're mangled.01:46
=== chihchun_afk is now known as chihchun
dufluRAOF: Umm, worthy of a bug report maybe02:08
RAOFOr I'll just fix it.02:09
dufluOr both at once...02:09
dufluIf it never worked then it's not a regression. If no one ever used it then maybe not important enough to be a bug :)02:09
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
dufluHey gdb understands STL containers now and makes them readable07:09
dufluthat's new07:09
RAOFOh, the python support got fixed?07:18
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 love07:26
ubot5Ubuntu bug 1275398 in Mir "i915 driver/i945 hardware: Mir GL clients are rendered as black or transparent windows when using i945 graphics" [High,Triaged]07:26
dufluanpok_: Please apply love where appropriate07:26
dufluUmm.07:26
dufluYou know what I mean07:26
anpok_:)07:26
anpok_i am strugling still with qxl07:27
anpok_it does page flip07:27
anpok_it seems to drop the page flip event to the event queue07:27
anpok_user space seems to get woken up but there is no page flip event07:28
=== chihchun is now known as chihchun_afk
alan_gRAOF: @"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:07
RAOFVia libmirserver?08:08
RAOFWe currently dlopen them from libmirserver, right?08:08
RAOFThen the (server) client code never needs to directly link against libmirplatform?08:09
alan_gNope. The point of libmirplatform being LGPL is that it doesn't require client code to link against the GPL libmirserver08:09
alan_gBTW I like the idea of introducing .symbols08:10
RAOFOoooh!08:11
alan_gwe do dlopen [mesa|android]/libmirplatformgraphics.so - so it could work for those08:11
RAOFBy “client code” in this case you mean “platform drivers”?08:11
alan_gFor this example, yes08:12
RAOFWhat else is going to require symbols from libmirplatform, and not also link with libmirserver?08:12
alan_gtrue. But by "client code" I mean drivers, servers, client, etc08:13
RAOFThere's a separate libmircilentplatform, right?08:13
alan_gThere is08:14
RAOFAnyway, 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:15
RAOFI think the state we _want_ to be in is having exactly two SOs - libmirserver.so and libmirclient.so08:16
alan_gFor servers & clients maybe. But drivers introduce a third case08:17
alan_gAnd I would prefer to share common code than link it into all three.08:18
alan_gOr four if there's really a good reason for libmirclientplatform.so being different from libmirplatform.so08:20
RAOFDrivers don't need to link against anything Mirish; they get dlopen()ed, so they always have the symbols available.08:20
RAOFDrivers are never useful outside the context of a mirserver instance08:21
* RAOF is somewhat foggy, so may in future disown current statements :/08:21
* alan_g is not going to argue now but doesn't feel quite convinced08:22
RAOFI'm a bit annoyed that libstdc++ means that libmirclient exports >1000 symbols, rather than the ~10 or so we *actually* want to export.08:23
dufluRAOF: Yeah I was wondering how you were going to solve the template problem. Particularly since libmirserver needs many of the template instance symbols exported08:25
alan_gI think it's a lot more than 10 (but a lot more less than 1000)08:26
dufluI think you will find it will be higher than 1000, I expect08:26
dufluTemplates are evil things08:26
dufluA tip for counting unique templates: Search for "::~" to identify unique destructors08:28
RAOFalan_g: Yeah, more like 50, true.08:28
RAOFduflu: I gave up touching libmirserver. Practically every cpp file is a part of the ABI there.08:29
* RAOF started trying to hide what look like purely internal classes, but it turns out that they're not purely internal.08:30
dufluRAOF: 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 interfaces08:30
duflu"unreachable" meaning we don't provide any APIs for people to access instances of said classes08:31
alan_gRAOF: my feeling is that libmir[client]platform is already stable (if not pretty) and a better measure for driver compatibility than the volatile server ABI08:31
RAOFduflu: That's what I did; it's not true that they're unreachable by public interfaces.08:31
dufluRAOF: Well, some, not all, obviously08:32
RAOFI don't think any of them are unreachable by public interfaces, actually.08:32
dufluRAOF: There used to be plenty. But I haven't made a stab at it for a long time08:33
RAOFAt least by my criterion of ‘if I apply visibility=hidden to this class, does everything link?’08:33
dufluGiven the number of headers has increased, I doubt they're all actually needed in public now08:33
alan_gRAOF: meaning tests that access "internal" classes?08:34
dufluRAOF: Obviously Mir needs those headers. I'm talking about headers no external project wants/can utilize08:34
RAOFalan_g: No, meaning mir_demo_server.08:34
anpok_well we can safely hide those not in include08:34
anpok_oh08:34
RAOFanpok_: Ba baw! Incorrect!08:34
anpok_our examples do that?08:35
dufluBecause we rejected the idea of separating "shared" headers from "public"08:35
alan_gWe should be able to hide those not in include08:35
RAOFanpok_: Because we expect people to derive from DefaultServerConfiguration, so everything that DefaultServerConfiguration touches needs to be public.08:35
RAOFAnd by ‘public’ I mean “linkable to”.08:35
dufluAh the ServerConfiguration beast08:35
alan_gWhy?08:36
anpok_RAOF: sure? but for those forward decls should sufficient08:36
RAOFNot at link time.08:36
anpok_+be08:36
dufluAlthough public projects only need access to classes used in public methods of *ServerConfiguration08:36
dufluI mean used in public declarations08:37
alan_gRAOF: yes, at link time08:37
RAOFYou can't have an object with fields that have visibility less than the object.08:37
alan_gBut the fields only need the forward decls08:37
dufluSounds like we may have exposed too much info in *server_configuration.h"08:38
alan_gCertainly more than I think we do08:38
RAOFSo, empirically, if you stick a bunch of visibility=hidden attributes on classes with headers in src/server, mir_demo_server_* cannot link.08:39
alan_gWe *should* be able to do that. I don't think the root cause is DefaultServerConfiguration - but will need to investigate.08:41
RAOFBecause the class derived from DefaultServerConfiguration needed a bunch of symbols.08:41
duflucamako: 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 branch08:41
RAOFYeah, I'll push this branch at some point.08:41
duflucamako: And then there's no waiting for Jenkins ;)08:42
RAOFHere we go...08:44
RAOFCMakeFiles/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
RAOFAnd a thousand others.08:45
RAOFBut EOD for me here.08:45
alan_gRAOF: goodbye. (But that is a function in DefaultServerConfiguration, not something the function "touches".08:46
alan_g)08:46
camakoduflu, I see your point. However, we have already suffered and are in the final stretch (packages built).08:55
camakoThere is an ongoing discussion on configuring jenkins for the rtm.08:56
camakoMeaning two distros..08:56
* camako feels our problems will be addressed soon 08:56
* alan_g admires the optimism of youth08:57
duflucamako: 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/mir08:57
* camako hasn't considered himself as "youth" in a very long time.. But thanks..08:57
dufluThat was previously "nice to have" but with two distros, probably now required08:57
camakoduflu, yes... That's why I'm "optimistic"08:58
camakodednick, I'm assuming you've seen kgunn's email?08:58
camakoCan we push for landing silo 18, or do you need to fix smth?08:59
dednickcamako: just read now09:00
dednickcamako: give me a sec09:00
camakosure09:01
sil2100o/09:01
camakoduflu, thanks for updating the changelog...09:02
dednickcamako: give me a about 15 minutes to give the silo a quick test09:05
camakodednick, sounds good... Take your time... I've yet to finish testing myself..09:05
greybackalf_: 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 buffers09:23
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 back09:24
alf_greyback: ... "Scopes" scope and going back it increases to over 1500, trying to figure out what the diff is09:25
greybackalf_: I think that's because the contents of an off-screen scope are still being rendered09:25
greybackalf_: I've pushed a patch to improve things, it should have landed by now09:26
alf_greyback: which package?09:26
greybackalf_: unity8, from the silo609:26
dufluThat's fun. Callgrind says we make a quarter of a million fread calls to load X cursors09:27
greybackalf_: Qt's scenegraph renderer does not do off-screen culling09:27
alf_greyback: :/09:27
anpokgreyback: if we make those buffers opaque?09:27
anpokthen still  no culling?09:27
greybackwell it's a big cost for a large scenegraph, and a good developer can more easily manually manage the visibility of components09:28
greybackalf_: a nice way to visually see these off-screen things is to run unity8 with QSG_VISUALIZE=overdraw09:29
greybackanpok: 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 issue09:29
greybackanpok: yeah making them opaque would help09:30
greybackalf_: yep09:30
greybackalf_: dash is doing lots of work, and lots of bad things09:30
greybackand as a result qt isn't able to optimise much09:31
alf_greyback: "actual rendering & buffer management" how do you mean that?09:32
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:34
greybackalf_: 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:36
alf_greyback: hmmmmm09:37
anpokthe full screen blend blocked the caller for around 2 ms on nexus409:37
greybackanpok: the thing is, we see performance drop with zero apps open. So that is Qt rendering directly to the mir provided framebuffer09:38
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 pronounced09:41
anpokwasnt there an option to move eglSwapBuffers to another therad in Qt?09:43
greybackanpok: 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 misses09:44
anpoki thought there was another one that also moves eglswap to a third09:44
alf_greyback: anpok: but this is just on the top of my head, no hard facts to back it up09:46
alf_greyback: anpok: off the top ...09:46
alf_greyback: your new unity8 build is much better in terms of gl calls per frame09:53
greybackalf_: yeah, but you can still experience jank when switching between apps & scopes scope10:00
greybackso not perfect10:01
alf_greyback: you mean while switching between the two, or after switching to scopes and back to apps again10:09
alf_?10:09
greybackalf_: if I just go back & forth between the 2, it seems to slow a bit10:11
greybackexpecially with a certain flick10:11
dufluGood news. I shall leave you today with nothing new to propose10:15
greyback\\o/10:16
greybackduflu: oh to continue our custom to belatedly admit we've not done anything wrt window management: I've not done anything wrt window management recently10:17
duflugreyback: Awesome-tastic10:17
duflugreyback: Me too but only because RTM trumps WM10:17
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 mess10:18
* duflu has another idea and fails to log off...10:18
greybackalf_: yep10:18
greybackalf_: but at least a probably solution is in the pipeline: split Dash out of shell so it is a separate process10:19
greybacks/probably/probable/10:19
greybackwell "solution"10:19
greybackit'll still render slowly10: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
greybackbut the frame boundary missing would be more forgiving - if that theory is right (I'm convinced)10:20
dufluAh. 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:21
duflualf_: Framedropping. And the fact that Qt apparently lacks throttling to be able to use it safely10:22
greybackalf_: yes10:26
greybackduflu: 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
duflugreyback: Could refer to different things. Where's it written?10:28
greybackduflu: I dunno, I saw you write it, I wanted to know what you were referring to10:29
duflugreyback: 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 behind10:30
greybackduflu: ok, that's interesting10:31
duflugreyback: So fingerpaint for example always keeps up with the current pointer location, but a fast renderer (frame dropping) sees many more samples... smoother curves10:32
dufluI know for a fact my mouse generates around 1000 events per sec. Mir is certainly not getting most of them10:32
camakodednick, the silo is testing well for me. How is it on your side?11:10
* camako saw some msgs between alan_g and tvoss11:10
camakoand dednick11:10
dednickcamako: silo working for me. tvoss having some issues, but don't think it's directly related.11:18
=== alan_g is now known as alan_g|lunch
greybackalf_: I'm getting more & more convinced by your frame boundary explanation12:15
alf_greyback: convinced by experiments or by thinking about it? :)12:17
greybackalf_: I've no proper data, more just thinking about it12:17
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
greybackalf_: I know, it's horrible12:19
greybackalf_: totally defeating the batching optimisation12:20
greybackexplains why scrolling so severe on CPU and GPU12:20
alf_greyback: Do you think there is an easy way with the QtComp codebase to test the frame boundary theory?12:23
greybackalf_: possibly by comparing frame render & frame delta times between QtComp & non-QtComp12:28
greybackQSG_RENDER_TIMING *might* give enough info, else QSG_RENDERER_DEBUG=render12:28
greybackwould also need to compare the same complex scene for both cases12:29
=== alan_g|lunch is now known as alan_g
=== greyback is now known as greyback|lunch
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
Saviqhey guys, got a gift for you - client crash on exit bug #134269414:19
ubot5bug 1342694 in mir (Ubuntu) "qmlscene crashed with SIGSEGV in _M_release() on quit" [Undecided,New] https://launchpad.net/bugs/134269414:19
Saviqit *could* potentially be qtubuntu, too14:19
=== greyback|lunch is now known as greyback
AlbertASaviq: it's being discussed... I think alan_g just root caused it14:37
Saviqcoolz14:37
=== dandrader is now known as dandrader|lunch
=== chihchun_afk is now known as chihchun
=== dandrader|lunch is now known as dandrader
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
racarr__Would appreciate thoughts on https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/22524220:04
racarr__once it or something similar lands can go around and add cursor support to qt, chromium, gtk, etc...20:04
=== dandrader|afk is now known as dandrader
racarr__+ any problem with landing https://code.launchpad.net/~mir-team/mir/improve-attribute-protocol-and-normalize-getters/+merge/22591220:06
racarr__opinions on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731 probably more important than cursor20:11
racarr__opinions on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731 probably more important than cursor20:15
racarr__whoops20:15
racarr__how to share acceptance tests with unity-mir/qtmir/mirqt/gerry21:00
racarr__beyond copy pasting code21:00
racarr__ive been thinking though there are a lot of tests21:00
greybackracarr__: I'm open to ideas21:01
racarr__that should be run against21:01
racarr__the shell server configuration21:01
greybackracarr__: 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:01
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-mir21:02
racarr__would turn up about just as much21:02
greybackcould you make a gdoc and put your review comments in there please? Easier to deal with than an email thread IMO21:02
racarr__I kind of tried to identify things that we may want to fix asap though.21:02
greybackoh sure, most of the same mistakes are probably there :)21:02
racarr__like...I had kind of forgotten that screencast authorization was never implemented21:02
racarr__lol21:02
racarr__ok will21:03
racarr__google doc it up21:03
greybackwith QtComp, I need to disable it, as it won't work21:03
greybackuntil I combine Qt's renderer with Mir's interface properly21:03
racarr__haha right...21:04
racarr__we need proper permissions for display config at least21:04
racarr__or21:04
racarr__maybe both are just always disabled on the phone21:04
racarr__and there is21:04
greybackI've no idea how shell mediates that. We've not had that discussion21:05
racarr__developer mode :p21:05
racarr__always disabled + developer mode to always enable21:05
racarr__is better than21:05
racarr__always allowed though21:05
greybackoh apparently I was wrong, we do send clients focus/unfocus events21:06
racarr__:)21:07
racarr__https://code.launchpad.net/~mir-team/mir/improve-attribute-protocol-and-normalize-getters/+merge/22591221:08
racarr__last chance to object pre landing21:08
greybackracarr__: why does a setter return the type that is set?21:12
greyback+ MirSurfaceType set_type(MirSurfaceType t);21:12
racarr__greyback: hmm no real reason atm...the exception throw21:13
racarr__used to be in configure instead of set_*21:13
racarr__I guess there is some thought that the logic is like21:14
greybackracarr__: 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 it21:14
racarr__well21:14
racarr__they are private21:14
racarr__the public api is21:14
racarr__int configure(int, int) lol21:14
greybackthat's a crappy API and you know it21:15
racarr__lol which part21:15
greybackwhy not just export these private methods?21:15
greybackABI stability?21:15
racarr__well as it stands the only user is frontend which is21:15
greybackme21:15
racarr__happy with the ints.21:15
racarr__?21:16
greybackeh. I'm trying to be a vocal API consumer21:16
racarr__haha.21:16
greybackconfigure(int,int) is an unpleasant way to set properties on something21:16
greybackaside from that, I like your changes21:17
racarr__I think, as needed/requested, setters and getters can be added for specific properties....some of them have public getters21:17
racarr__I guess configure/query is really the API to frontend21:17
racarr__and the API to shell21:17
racarr__has been ignored lol21:17
greybacknice :P21:19
racarr__I hope I make sense...I may literally be the most tired I have ever been right now21:20
racarr__the good news. No niccotine in 5 days!21:20
racarr__and i...enjoyed the whole process this time21:21
racarr__and am pretty confident that I am over it21:21
racarr__the bad news. no proper sleep in 5 days!21:21
greybackkeep it up man, you can do it21:23
racarr__I think tonight is finally my night just due to sheer and total exhaustion.21:23
racarr__:D Thanks21:23
greybackI'm not in any hurry for you to do anything (think I'm the bottleneck right now)21:23
greybackso if you need to snooze, go for it21:24
racarr__I...none of it makes me want to smoke lol im just so tired atm hard to tell things make sense21:24
racarr__haha, nah, gotta power through until the sun goes down at least lol21:25
racarr__Think I am going to distract myself with low brain power acceptance testing.21:25
greyback:)21:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!