| duflu | kdub: 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/1488386 | 01:41 |
|---|---|---|
| ubot5 | Ubuntu 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 | ||
| RAOF | Wow. Touching mg::DisplayConfigurationOutput touches *all the things*. | 05:57 |
| duflu | RAOF: All the server things? Yeah probably | 06:06 |
| duflu | RAOF: Here's a thought: Is the system's "scale" setting a feature of the server rather than the display/displayconfig? | 06:07 |
| RAOF | No, because it's per-output. | 06:07 |
| duflu | Fair enough. More fields for everyone | 06:07 |
| RAOF | Yeah :/ | 06:07 |
| duflu | RAOF: Hmm, do the toolkits report scale per display? | 06:08 |
| duflu | Because if it's systemwide in the toolkit designs, that would be a problem | 06:08 |
| RAOF | I'm pretty sure they do, yeah. | 06:08 |
| duflu | If they report it at all | 06:09 |
| RAOF | gdk tracks scale per-output, but gdk_window_get_scale will report the largest scale factor in the current configuration. | 06:12 |
| RAOF | But 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 | ||
| dandrader | duflu, ping | 08:01 |
| duflu | dandrader: Hello | 08:01 |
| dandrader | duflu, hi | 08:01 |
| dandrader | so, I got a problem um qtubuntu regarding resize events | 08:01 |
| duflu | Yay | 08:01 |
| dandrader | resize events are processed in a thread and buffer swapping in a different one | 08:02 |
| dandrader | currently, when i get a resize event all I do is schedule the rendering of a new frame | 08:02 |
| dandrader | and it has been working well until a couple of weeks ago | 08:02 |
| dandrader | it used to be that after I get a resize event, on my next buffer swap I would get already a frame with the new size | 08:03 |
| duflu | dandrader: Yeah, schedule a new frame on resize, but ignore the resize event contents. Instead use the dimensions of the buffer you get back from swap | 08:03 |
| dandrader | but now it happens so that sometimes it takes two buffer swaps until I get a buffer with the new surface size | 08:03 |
| dandrader | duflu, that's what I do | 08:04 |
| duflu | dandrader: That's always been an issue. There are TODOs and comments in the Mir demos about it | 08:04 |
| duflu | dandrader: Let me find the details | 08:04 |
| dandrader | duflu, previously I would swap buffers until I get a buffer with the new size | 08:04 |
| dandrader | duflu, but that proved problematic in some situations | 08:05 |
| duflu | dandrader: Just remember every swap buffers will appear on screen, so it should have rendering in it :) | 08:05 |
| duflu | dandrader: https://bugs.launchpad.net/mir/+bug/1288021 | 08:05 |
| ubot5 | Ubuntu bug 1288021 in Mir "MirResizeEvent's width/height fields are not useful, even dangerous" [Medium,Triaged] | 08:05 |
| dandrader | duflu, sure, when I say buffer swapping I mean rendering a new frame | 08:05 |
| dandrader | duflu, so now I'm thinking about doing the following | 08:06 |
| dandrader | duflu, when I get a resize event | 08:06 |
| dandrader | duflu, I render up to 3 new frames trying to get a buffer with a new size | 08:06 |
| dandrader | duflu, as opposed to rendering just once, as it's done now | 08:07 |
| duflu | dandrader: There's a simple solution we've been using for a long time. Just see: https://bugs.launchpad.net/mir/+bug/1288021 | 08:07 |
| ubot5 | Ubuntu bug 1288021 in Mir "MirResizeEvent's width/height fields are not useful, even dangerous" [Medium,Triaged] | 08:07 |
| dandrader | duflu, yes, I do this | 08:08 |
| dandrader | duflu, this is not the problem I'm explaining | 08:08 |
| duflu | OK | 08:08 |
| dandrader | duflu, problem is the following: unity8 rotates from landscape to portrait, thus resizing the focused app, which gets a resize event from mir | 08:09 |
| dandrader | duflu, so qtubuntu, in the client app process, schedules the rendering of a new frame in response to that resize event | 08:10 |
| dandrader | duflu, but the next buffer still has a landscape size | 08:10 |
| duflu | dandrader: 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/1466510 | 08:10 |
| ubot5 | Ubuntu bug 1466510 in unity8 (Ubuntu) "Stretched screen (briefly) after rotating" [Undecided,Confirmed] | 08:11 |
| dandrader | duflu, so it will look streched (as unity8 is already in portrait) until the user flicks the app, causing a new redraw | 08:11 |
| dandrader | duflu, s/a new redraw/yet another redraw | 08:12 |
| duflu | dandrader: 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 |
| dandrader | suggestion #4 sounds wasteful | 08:14 |
| duflu | dandrader: It would look beautiful, more like iOS rotation | 08:14 |
| duflu | Oh, except Unity8 itself would have to support partial rotation | 08:15 |
| duflu | dandrader: I tested it on a phone last Friday. The unstretch branch really solves most of the problem. The rest is just minor polish | 08:15 |
| duflu | "minor polish" = you finding ways to tell the app to resize sooner | 08:16 |
| dandrader | duflu, so https://code.launchpad.net/~vanvugt/qtmir/unstretch/+merge/268724 does clipping/cropping instead of streching | 08:20 |
| seb128 | hey there, does anyone know if there is documentation somewhere about mir-on-x? | 08:20 |
| duflu | dandrader: Yes, so most of your pixels appear in the right place, even before the resize | 08:20 |
| duflu | seb128: Not sure. It's very new. I heard that even intel gfx support isn't ready yet | 08:21 |
| dandrader | duflu, I will try out the "redraw up to 3 times after getting a resize event" solution | 08:21 |
| seb128 | duflu, if it's not working on intel on what is it working? ;-) | 08:22 |
| duflu | dandrader: Hmm, if you really need that then there must be another bug not revealed by mir-demos yet | 08:22 |
| duflu | seb128: Other drivers. Ask camako / RAOF | 08:23 |
| duflu | dandrader: 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 dimensions | 08:24 |
| duflu | dandrader: 3 times will work, but better to put it in a while loop | 08:25 |
| seb128 | camako, RAOF, should mir-on-X work on intel? do you have documentation on how to test it? | 08:25 |
| duflu | seb128: Although "Mir on VT1" works right now ;) | 08:26 |
| seb128 | less handy for testing :-) | 08:26 |
| dandrader | duflu, 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 redraw | 08:27 |
| duflu | seb128: Meh, Ctrl+Alt+Fn is easy. And you get much better performance too | 08:27 |
| duflu | dandrader: Yeah you're right. Our mir demos failed to reveal that bug | 08:27 |
| duflu | dandrader: Seems like Mir itself should keep sending you the same resize event till it matches | 08:28 |
| dandrader | duflu, thing is there's no synchronicity whatsoever between the mir event thread and the rendering thread | 08:30 |
| dandrader | duflu, if we could tie a frame number to the resize event it would be perfect | 08:30 |
| dandrader | duflu, so the client would know that it will get a buffer with the new size of frame number X | 08:31 |
| duflu | dandrader: You can get the "age" of the buffer (number up to 3) | 08:32 |
| duflu | which might help | 08:32 |
| duflu | Not sure | 08:32 |
| duflu | Also, I know... https://bugs.launchpad.net/mir/+bug/1194384 | 08:32 |
| ubot5 | Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [High,Triaged] | 08:32 |
| dandrader | duflu, 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 |
| duflu | dandrader: 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 |
| anpok | seb128: not sure about hte current status, I know that there was something missing in the intel driver shipped in wily | 09:03 |
| anpok | not sure if you have to go to drm-next or a newer mesa.. | 09:03 |
| alan_g | duflu: are you still set up to test https://code.launchpad.net/~alan-griffiths/mir/fix-1488500/+merge/269171? | 09:09 |
| duflu | alan_g: No, but it's likely we can find the offending debs in /var/cache/apt/archives/ | 09:09 |
| duflu | If not just download them again | 09:10 |
| alan_g | duflu: yeah, but making them appear in the directory in the right order isn't so easy | 09:10 |
| alan_g | I had to hack the loading code to make it happen on my machine | 09:11 |
| duflu | alan_g: Is it raw (unpredictable) directory order? | 09:11 |
| alan_g | yep | 09:11 |
| duflu | Excellent | 09:11 |
| duflu | Definitely not then | 09:11 |
| alan_g | nm thanks | 09:11 |
| duflu | alan_g: Try a --reinstall on the latest package | 09:11 |
| alan_g | I will, when I get home to a wily m/c | 09:16 |
| duflu | Motorcycle? | 09:18 |
| duflu | You may not want a wily motorcycle | 09:18 |
| alan_g | haha | 09:19 |
| alan_g | anpok: as you're looking at USC... https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110 | 10:15 |
| alan_g | greyback_: I think your NF is addressed? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110 | 10:19 |
| greyback_ | alan_g: approved | 10:28 |
| alan_g | greyback_: thanks. :) | 10:28 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alan_g | kdub: thoughts? https://code.launchpad.net/~alan-griffiths/mir/workaround-1441553/+merge/269008/comments/676875 | 13:42 |
| kdub | alan_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 |
| kdub | although, that number is part of what will be deprecated with NBS, so, its hopefully a short lived comment anyways | 13:46 |
| alan_g | kdub: thanks | 13:47 |
| alan_g | kdub: does this phrasing work? | 13:53 |
| kdub | alan_g, seems more accurate and clearer to me at least | 13:54 |
| alan_g | Good enough for me. | 13:54 |
| camako | seb128, 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 |
| camako | seb128, this is how I run it : bin/mir_demo_server --platform-input-lib lib/server-modules/server-mesa-x11.so.4 | 14:09 |
| camako | from a terminal | 14:09 |
| alan_g | camako: 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 |
| camako | alan_g, what happens on vivid? | 14:14 |
| alan_g | the client hangs without painting | 14:14 |
| alan_g | But there's also the VT switching bug. | 14:16 |
| alan_g | Which I didn't have last week | 14:18 |
| robert_ancell | Why 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 |
| anpok | o_O | 15:02 |
| === chihchun is now known as chihchun_afk | ||
| josharenson | mterry: 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 wei | 22:01 |
| josharenson | mterry: that probably isn't very clear, so let me know if you need clarification | 22:01 |
| mterry | josharenson, naw you can just say add_definition(-DLIGHTDM_MODE=1) or -DGREETER_MODE=lightdm or something and check that with preprocessor logic | 22:11 |
| josharenson | mterry: ack | 22:11 |
| mterry | josharenson, I guess you'd use a target-specific version of add_definition. I think it's like set_target_properties or something | 22:12 |
| josharenson | mterry: I'll check that out too | 22:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!