[01:49] <duflu> This is odd. Why is Xorg slower on Haswell than Sandybridge?!
[01:50] <duflu> Mir has no such problems
[02:06] <RAOF> duflu: What test?
[02:06] <RAOF> duflu: Also, fast Sandybridge vs slow Haswell?
[02:07] <duflu> RAOF: I swapped my drive out of an HD2000 system into an HD4400
[02:07] <duflu> And it stutters quite a bit
[02:08] <duflu> Oops... HD4600
[02:09] <duflu> I'm suspicious of:  [     1.949] (**) intel(0): "Tear free" disabled
[02:09] <duflu> But can't remember what it used to be
[09:14] <mlankhorst> there didn't used to be a tear free option
[09:14] <mlankhorst> and it was always disabled :p
[09:57] <duflu> mlankhorst: Just guessing...
[09:57] <duflu> But if I wanted a real answer I would debug Compiz
[09:57] <duflu> trying to avoid that
[09:58] <duflu> alan_g: Any hints as to how to force gmock to match 16 elements passed to a GLfloat* parameter? :)
[09:59] <alan_g> duflu: write a bespoke matcher?
[09:59] <duflu> alan_g: That's what I thought, but attempts so far don't even compile
[10:00] <duflu> And the docs are too vague to explain why
[10:00] <alan_g> racarr has written quite a few around the input tests
[10:05] <duflu> On second thoughts, this test probably should not exist using mocks. It assumes too much about the internals of the class
[10:25] <alan_g> Talking about assuming implementation details: Does anyone think SocketSessionTest.basic_msg is a readable or useful test?
[10:25]  * alan_g wants to delete it
[10:28] <duflu> alan_g: If you can't read it then that doesn't bode well. I though you knew that stuff better than most
[10:28] <duflu> +t
[10:28]  * duflu wanders off
[11:10] <ricmm> kdub: asleep? ;)
[13:02] <alan_g> alf_: can you take a look? I'm getting happier with it (but it may be just that I'm getting used to it): https://code.launchpad.net/~alan-griffiths/mir/spike-exposing-rpc-in-frontend/+merge/202351
[13:03] <alf_> alan_g|lunch: sure
[14:11] <kgunn> alf_: a matter of curiosity, we don't have triple buffering on at the client level do we ?
[14:17] <alan_g> kgunn: we don't
[14:17] <alf_> kgunn: alan_g: AFAIK, the code supports triple buffering for client surfaces. What is blocking it?
[14:21] <kgunn> alf_: so i was just thinking, wrt side stage, where the code relies on snapshotting when "closing"/"revealing"
[14:21] <kgunn> and that the pipeline is stalling
[14:21] <kgunn> e.g. its gotta read from the buff
[14:21] <kgunn> before it let's it continue rendering
[14:21] <kgunn> & swapping buffs
[14:21] <kgunn> whereas, triple buffering would at least help alleviate
[14:22] <kgunn> this getting in at least one extra render while you're still reading
[14:22] <kgunn> (all theory of course)
[14:22] <kgunn> ricmm: ^
[14:26] <alf_> kgunn: are we seeing an actual slowdown when the sidestage is revealed/closed?
[14:26] <kgunn> alf_: yeah there's definitely some stall/jank at times
[14:27] <kgunn> if you flash devel-proposed, it has sidestage...N10 of course
[14:28] <alf_> kgunn: And I am assuming that snapshotting been identified as the culprit or is this a theory?
[14:28] <kgunn> alf_: all theory
[14:32] <ricmm> alf_: do you have a N10?
[14:33] <alf_> ricmm: yes
[14:33] <ricmm> can you give it a go with the latest image
[14:33] <ricmm> you'll have the feel of whats happening
[14:33] <alf_> ricmm: ok
[15:19] <alan_g> alf_: sorted tabs (and placated valgrind over the SocketSessionTest.basic_msg_is_received_and_dispatched test)
[15:20] <alf_> alan_g: ok
[20:16] <dandrader> do you guys have trouble getting useful backtraces out of gdb on the device (arm)?
[20:22] <kdub> dandrader, sometimes
[20:23] <dandrader> kdub, any trick I can do to improve it?
[20:26] <kdub> dandrader, unfortunately no, havent spent a lot of time looking