| === chihchun is now known as chihchun_afk | ||
| === sturmflut_ is now known as sturmflut | ||
| === chihchun_afk is now known as chihchun | ||
| === c74d is now known as Guest28244 | ||
| === marcusto_ is now known as marcustomlinson | ||
| === marcusto_ is now known as marcustomlinson | ||
| 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:39 |
|---|---|---|
| alan_g | duflu: it isn't set up for devel-mir-next | 08:40 |
| alan_g | maybe it ought to be | 08:40 |
| 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:41 |
| duflu | greyback_: Hey did U8/QtMir get its own screencasting tool? | 08:49 |
| greyback_ | duflu: qt has it built-in | 08:50 |
| duflu | greyback_: Handy. Got a bin name? | 08:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| duflu | Unlike the old format | 08:56 |
| 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:58 |
| greyback_ | duflu: qt has it's own input resampling indeed | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| duflu | greyback_: It's not in the 5.4 release notes... (?) | 09:04 |
| greyback_ | hmm, let me check I'm talking out of my ass | 09:05 |
| duflu | afk | 09:05 |
| greyback_ | https://qt.gitorious.org/qt/qtdeclarative/commit/6dc8f47bb05a8acb3cbcc697e0dc05356a01d4cf <- there's the commit anyway | 09:06 |
| greyback_ | seems it wasn't noteworthy enough to mention in the release notes | 09:08 |
| duflu | greyback_: How do you know that was the 5.4 branch? It was committed before the 5.3 release. | 09:20 |
| greyback_ | duflu: it was a guess | 09:21 |
| duflu | Actually committed around the same time as 5.3 released. So probably 5.3 | 09:24 |
| duflu | Probably 5.4 | 09:24 |
| 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:25 |
| 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:42 |
| === greyback__ is now known as greyback | ||
| greyback | bloody wifi | 09:52 |
| greyback | duflu: what situations would a client want non-sampled input? | 09:52 |
| 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:53 |
| duflu | And games no doubt | 09:54 |
| greyback | okies | 09:54 |
| duflu | greyback: Basically anything that can process multiple input events (well) per frame | 09:55 |
| RAOF | Such as Qt :) | 09:55 |
| duflu | RAOF: Isn't it Easter for you already? | 10:01 |
| === alan_g is now known as alan_g|lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader|afk is now known as dandrader | ||
| 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:38 |
| greyback_ | +1 | 13:39 |
| greyback_ | QML_NO_TOUCH_COMPRESSION=1 will disable Qt's input "compression" | 13:40 |
| kdub | yeah, it seems its valuable to configure mir's input sampling | 13:41 |
| kdub | and also, +1 to quantified discussions of course | 13:41 |
| 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:43 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| tvoss | anpok, mind pointing me to the tests for the resampling? | 13:49 |
| anpok | we only have received_event .. and not event_passed_to_event_delegate | 13:51 |
| anpok | as a trace point | 13:51 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOW | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!