[08:39] <duflu> alan_g: Is Jenkins usually present or need to be requested on devel-mir-next? Seems it was present on one proposal but not the other
[08:40] <alan_g> duflu: it isn't set up for devel-mir-next
[08:40] <alan_g> maybe it ought to be
[08:41] <duflu> alan_g: Might be handy, but the process is already pretty indirect. Jenkins will always be gatekeeper in the end as things eventually get proposed to lp:qtmir
[08:41] <duflu> In the branches prior to that, less important
[08:49] <duflu> greyback_: Hey did U8/QtMir get its own screencasting tool?
[08:50] <greyback_> duflu: qt has it built-in
[08:51] <duflu> greyback_: Handy. Got a bin name?
[08:53] <greyback_> duflu: http://doc.qt.io/qt-5/qscreen.html#grabWindow is the method, is platform dependent. It's not a standalone tool tho.
[08:54] <duflu> greyback_: Kay nevermind. Just noticed the output format of mirscreencast has changed and I thought that might be to support some tool/script that can use it
[08:55] <greyback_> duflu: of that I've no idea. It wasn't done for Qt's sake anyway
[08:55] <duflu> The new format is theoretically less awkward but I don't know any mplayer/vlc incantation that can use it
[08:56] <duflu> Unlike the old format
[08:58] <duflu> greyback_: In other news, I've been playing with input resampling again, on the client side this time. Seems there's reasonable gain to be had if you implement app-specific resampling. If Qt has this, we should try it
[08:59] <greyback_> duflu: qt has it's own input resampling indeed
[09:00] <duflu> greyback_: Great. But if it's not turned on then turning off Mir's would be bad
[09:00] <greyback_> but as unity8 written in qt, it means unity8 will be doing the resampling
[09:00] <greyback_> it's turned on by default I believe (I don't think it can be turned off actually...)
[09:01] <duflu> greyback_: Oh, so it just didn't exist back when Mir got resampling?
[09:01] <greyback_> duflu: correct, it only appeared in qt5.4
[09:01] <duflu> That definitely needs testing then.
[09:02] <duflu> greyback_: Oh. It's not in RTM then
[09:02] <duflu> Yet
[09:02] <greyback_> yeah
[09:02] <greyback_> rtm on 5.3 still
[09:04] <duflu> greyback_: It's not in the 5.4 release notes... (?)
[09:05] <greyback_> hmm, let me check I'm talking out of my ass
[09:05] <duflu> afk
[09:06] <greyback_> https://qt.gitorious.org/qt/qtdeclarative/commit/6dc8f47bb05a8acb3cbcc697e0dc05356a01d4cf <- there's the commit anyway
[09:08] <greyback_> seems it wasn't noteworthy enough to mention in the release notes
[09:20] <duflu> greyback_: How do you know that was the 5.4 branch? It was committed before the 5.3 release.
[09:21] <greyback_> duflu: it was a guess
[09:24] <duflu> Actually committed around the same time as 5.3 released. So probably 5.3
[09:24] <duflu> Probably 5.4
[09:25] <greyback_> duflu: found the branch in the qtdeclarative repo, it landed in 5.4
[09:25] <duflu> greyback_: OK, retesting on a phone now
[09:42] <duflu> greyback_: Yeah I think there is some benefit. At least scrolling is smoother than the default 55Hz. But we already knew that was a problem and fixed it in 0.13. Still, I think when Mir gets a client function to toggle resampling it's probably time to default to off
[09:52] <greyback> bloody wifi
[09:52] <greyback> duflu: what situations would a client want non-sampled input?
[09:53] <duflu> greyback: If it can do a better job by virtue of its own multi-layered design (e.g. fingerpaint and coming soon: mir_demo_client_target).
[09:54] <duflu> And games no doubt
[09:54] <greyback> okies
[09:55] <duflu> greyback: Basically anything that can process multiple input events (well) per frame
[09:55] <RAOF> Such as Qt :)
[10:01] <duflu> RAOF: Isn't it Easter for you already?
[13:38] <kgunn> kdub: alf_ worth reading greyback_ and duflu's scrollback ^^
[13:38] <kgunn> drives me crazy, we need to stop saying "that looks better" and measure
[13:39] <greyback_> +1
[13:40] <greyback_> QML_NO_TOUCH_COMPRESSION=1 will disable Qt's input "compression"
[13:41] <kdub> yeah, it seems its valuable to configure mir's input sampling
[13:41] <kdub> and also, +1 to quantified discussions of course
[13:43] <alf_> kgunn: +1 for measure, but... there is still the unknown factor of things actually getting to the screen which we don't have a good way to measure, and essentially that is what counts
[13:43] <kdub> alf_, I guess thats what that python+lttng stuff was intended to make easier?
[13:45] <alf_> kdub: we can get closer with these, but there still may be issues in the display stack/hardware that we don't control
[13:45] <tvoss> alf_, not sure we should block on that bit
[13:45] <alf_> kdub: bottom line I guess is that "looks/feels better" is a valid, though subjective, metric
[13:45] <kdub> alf_, sure, but we won't ever control that, and we have to start measuring somewhere :)
[13:45] <alf_> tvoss: not saying that we should
[13:46] <tvoss> alf_, if there is a significance difference between what is visible and what the numbers tell us -> big issue
[13:46] <tvoss> alf_, kdub is Mir's resampling code instrumented such that we can do measurements on that?
[13:47] <kdub> anpok?
[13:47] <anpok> hm
[13:47] <anpok> the resampling itself has not clear enter exit points afaik
[13:47] <anpok> s/not/no
[13:47] <tvoss> alf_, kdub I also noticed that we introduced a magic constant 55 Hz there. The original android approach allows the client to pass in the timestamp of the start of the last render pass, which makes a lot more sense
[13:48] <tvoss> anpok, I'm pretty sure it has on the client side
[13:48] <anpok> tvoss: well there is one point where it starts, to accumulate and another where it will send stuff.. I belive either of the points is missing
[13:48] <anpok> but I might be wrong
[13:48] <tvoss> not sure I understand that statement
[13:49] <tvoss> anpok, mind pointing me to the tests for the resampling?
[13:51] <anpok> we only have received_event .. and not event_passed_to_event_delegate
[13:51] <anpok> as a trace point