duflukdub: Interesting thought - nested bypass in its ability to use much less GPU might actually make phones less smooth (because they will clock lower). We need to get that under control too: https://bugs.launchpad.net/mir/+bug/148838601:41
ubot5Ubuntu bug 1488386 in qtmir (Ubuntu) "Double buffering is only smooth while you're touching it" [Undecided,New]01:41
=== chihchun_afk is now known as chihchun
=== shuduo_afk is now known as shuduo
RAOFWow. Touching mg::DisplayConfigurationOutput touches *all the things*.05:57
dufluRAOF: All the server things? Yeah probably06:06
dufluRAOF: Here's a thought: Is the system's "scale" setting a feature of the server rather than the display/displayconfig?06:07
RAOFNo, because it's per-output.06:07
dufluFair enough. More fields for everyone06:07
RAOFYeah :/06:07
dufluRAOF: Hmm, do the toolkits report scale per display?06:08
dufluBecause if it's systemwide in the toolkit designs, that would be a problem06:08
RAOFI'm pretty sure they do, yeah.06:08
dufluIf they report it at all06:09
RAOFgdk tracks scale per-output, but gdk_window_get_scale will report the largest scale factor in the current configuration.06:12
RAOFBut it'd be an easy optimisation to make it report the scale that the surface is on.06:13
RAOF(Because gdk notifies apps when the scale changes, and even with its current “maximum scale of everything on the system” approach the scale *does* change at runtime, so apps need to handle it)06:20
=== guest42315 is now known as o
=== o is now known as Guest39201
dandraderduflu, ping08:01
dufludandrader: Hello08:01
dandraderduflu, hi08:01
dandraderso, I got a problem um qtubuntu regarding resize events08:01
dandraderresize events are processed in a thread and buffer swapping in a different one08:02
dandradercurrently, when i get a resize event all I do is schedule the rendering of a new frame08:02
dandraderand it has been working well until a couple of weeks ago08:02
dandraderit used to be that after I get a resize event, on my next buffer swap I would get already a frame with the new size08:03
dufludandrader: Yeah, schedule a new frame on resize, but ignore the resize event contents. Instead use the dimensions of the buffer you get back from swap08:03
dandraderbut now it happens so that sometimes it takes two buffer swaps until I get a buffer with the new surface size08:03
dandraderduflu, that's what I do08:04
dufludandrader: That's always been an issue. There are TODOs and comments in the Mir demos about it08:04
dufludandrader: Let me find the details08:04
dandraderduflu, previously I would swap buffers until I get a buffer with the new size08:04
dandraderduflu, but that proved problematic in some situations08:05
dufludandrader: Just remember every swap buffers will appear on screen, so it should have rendering in it :)08:05
dufludandrader: https://bugs.launchpad.net/mir/+bug/128802108:05
ubot5Ubuntu bug 1288021 in Mir "MirResizeEvent's width/height fields are not useful, even dangerous" [Medium,Triaged]08:05
dandraderduflu, sure, when I say buffer swapping I mean rendering a new frame08:05
dandraderduflu, so now I'm thinking about doing the following08:06
dandraderduflu, when I get a resize event08:06
dandraderduflu, I render up to 3 new frames trying to get a buffer with a new size08:06
dandraderduflu, as opposed to rendering just once, as it's done now08:07
dufludandrader: There's a simple solution we've been using for a long time. Just see: https://bugs.launchpad.net/mir/+bug/128802108:07
ubot5Ubuntu bug 1288021 in Mir "MirResizeEvent's width/height fields are not useful, even dangerous" [Medium,Triaged]08:07
dandraderduflu, yes, I do this08:08
dandraderduflu, this is not the problem I'm explaining08:08
dandraderduflu, problem is the following: unity8 rotates from landscape to portrait, thus resizing the focused app, which gets a resize event from mir08:09
dandraderduflu, so qtubuntu, in the client app process, schedules the rendering of a new frame in response to that resize event08:10
dandraderduflu, but the next buffer still has a landscape size08:10
dufludandrader: I know. I've been looking after that bug. I have posted a partial solution and suggested how to handle the rest in comments: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/146651008:10
ubot5Ubuntu bug 1466510 in unity8 (Ubuntu) "Stretched screen (briefly) after rotating" [Undecided,Confirmed]08:11
dandraderduflu, so it will look streched (as unity8 is already in portrait) until the user flicks the app, causing a new redraw08:11
dandraderduflu, s/a new redraw/yet another redraw08:12
dufludandrader: I've fixed the stretching in my branch, but there's still a brief delay while it fixes up the bottom/right edges. Comment #4 should solve that.08:12
dandradersuggestion #4 sounds wasteful08:14
dufludandrader: It would look beautiful, more like iOS rotation08:14
dufluOh, except Unity8 itself would have to support partial rotation08:15
dufludandrader: I tested it on a phone last Friday. The unstretch branch really solves most of the problem. The rest is just minor polish08:15
duflu"minor polish" = you finding ways to tell the app to resize sooner08:16
dandraderduflu, so https://code.launchpad.net/~vanvugt/qtmir/unstretch/+merge/268724 does clipping/cropping instead of streching08:20
seb128hey there, does anyone know if there is documentation somewhere about mir-on-x?08:20
dufludandrader: Yes, so most of your pixels appear in the right place, even before the resize08:20
dufluseb128: Not sure. It's very new. I heard that even intel gfx support isn't ready yet08:21
dandraderduflu, I will try out the "redraw up to 3 times after getting a resize event" solution08:21
seb128duflu, if it's not working on intel on what is it working? ;-)08:22
dufludandrader: Hmm, if you really need that then there must be another bug not revealed by mir-demos yet08:22
dufluseb128: Other drivers. Ask camako / RAOF08:23
dufludandrader: I think you might have a new and unique bug there. Particularly for resizing input-driven apps. Not sure if we've covered that correctly. Yeah it seems like you do need to keep redrawing till the buffer dimensions == resize event dimensions08:24
dufludandrader: 3 times will work, but better to put it in a while loop08:25
seb128camako, RAOF, should mir-on-X work on intel? do you have documentation on how to test it?08:25
dufluseb128: Although "Mir on VT1" works right now ;)08:26
seb128less handy for testing :-)08:26
dandraderduflu, it's "*up* to 3 times". I give up ealier if I get a buffer with a new size already on the first or second redraw08:27
dufluseb128: Meh, Ctrl+Alt+Fn is easy. And you get much better performance too08:27
dufludandrader: Yeah you're right. Our mir demos failed to reveal that bug08:27
dufludandrader: Seems like Mir itself should keep sending you the same resize event till it matches08:28
dandraderduflu, thing is there's no synchronicity whatsoever between the mir event thread and the rendering thread08:30
dandraderduflu, if we could tie a frame number to the resize event it would be perfect08:30
dandraderduflu, so the client would know that it will get a buffer with the new size of frame number X08:31
dufludandrader: You can get the "age" of the buffer (number up to 3)08:32
dufluwhich might help08:32
dufluNot sure08:32
dufluAlso, I know... https://bugs.launchpad.net/mir/+bug/119438408:32
ubot5Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [High,Triaged]08:32
dandraderduflu, the client would internally count the number of buffer swaps it has done on a surface. if mir provided the frame number of the buffer which will have the new size on the resize event, the client would know exacly how many buffer swaps would be needed to reach it. do you think that this could work?08:39
dufludandrader: I say use a while loop. It will cover the case of desktop resizing with a mouse much better (where the resize operation could go on indefinitely)08:40
anpokseb128: not sure about hte current status, I know that there was something missing in the intel driver shipped in wily09:03
anpoknot sure if you have to go to drm-next or a newer mesa..09:03
alan_gduflu: are you still set up to test https://code.launchpad.net/~alan-griffiths/mir/fix-1488500/+merge/269171?09:09
duflualan_g: No, but it's likely we can find the offending debs in /var/cache/apt/archives/09:09
dufluIf not just download them again09:10
alan_gduflu: yeah, but making them appear in the directory in the right order isn't so easy09:10
alan_gI had to hack the loading code to make it happen on my machine09:11
duflualan_g: Is it raw (unpredictable) directory order?09:11
dufluDefinitely not then09:11
alan_gnm thanks09:11
duflualan_g: Try a --reinstall on the latest package09:11
alan_gI will, when I get home to a wily m/c09:16
dufluYou may not want a wily motorcycle09:18
alan_ganpok: as you're looking at USC... https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/26211010:15
alan_ggreyback_: I think your NF is addressed? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/26211010:19
greyback_alan_g: approved10:28
alan_ggreyback_: thanks. :)10:28
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
alan_gkdub: thoughts? https://code.launchpad.net/~alan-griffiths/mir/workaround-1441553/+merge/269008/comments/67687513:42
kdubalan_g, left a comment, i think a clearer comment is along the lines of "this number should be however many buffers the system has"13:45
kdubalthough, that number is part of what will be deprecated with NBS, so, its hopefully a short lived comment anyways13:46
alan_gkdub: thanks13:47
alan_gkdub: does this phrasing work?13:53
kdubalan_g, seems more accurate and clearer to me at least13:54
alan_gGood enough for me.13:54
camakoseb128, intel has a bug, so GL apps render black under mir-on-x.. Sw apps render ok. A new Mesa driver is being released, which according to RAOF, should fix the issue.14:08
camakoseb128, this is how I run it : bin/mir_demo_server --platform-input-lib lib/server-modules/server-mesa-x11.so.414:09
camakofrom a terminal14:09
alan_gcamako: it was working on my wily system end of last week. Still broken on vivid this week, I assumed the drivers got updated.14:13
camakoalan_g, what happens on vivid?14:14
alan_gthe client hangs without painting14:14
alan_gBut there's also the VT switching bug.14:16
alan_gWhich I didn't have last week14:18
robert_ancellWhy is it that GLES can do images in format GL_UNSIGNED_INT_2_10_10_10_REV in glTexSubImage2D but not GL_UNSIGNED_INT_8_8_8_8_REV?14:59
=== chihchun is now known as chihchun_afk
josharensonmterry: maybe I'm thinking about this wrong.. I'm running configure_file on qmldir and installing it in the binary directory. This is great. However, the plugin.h and plugin.cpp files need configuring too, but they are source files. Should there be 2 different files in the source dir (plugin_full.h && plugin_integrated.h) OR should I run configure_file on a "master" plugin.h file, and "copy" them to the source directory (seems wei22:01
josharensonmterry: that probably isn't very clear, so let me know if you need clarification22:01
mterryjosharenson, naw you can just say add_definition(-DLIGHTDM_MODE=1) or -DGREETER_MODE=lightdm or something and check that with preprocessor logic22:11
josharensonmterry: ack22:11
mterryjosharenson, I guess you'd use a target-specific version of add_definition.  I think it's like set_target_properties or something22:12
josharensonmterry: I'll check that out too22:12

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