| === chihchun_afk is now known as chihchun | ||
| === marcusto_ is now known as marcustomlinson | ||
| duflu | alf_: Annoyingly, I upgraded, broke and then upgraded mako again. And something other than Mir has changed so I'm not getting consistent results any more. This will take time... | 07:03 |
|---|---|---|
| duflu | Oddly, unity8 is no longer fast enough to qualify for double buffering in wily-proposed whereas it was a few days ago | 07:04 |
| duflu | Still, could be something change in Mir too | 07:05 |
| === mibofra is now known as Guest35933 | ||
| duflu | A scary (or spurious) realisation: QtMir doesn't schedule enough frames to render clients smoothly. The only reason they don't appear to hang is because of the frame dropping fallback. | 08:25 |
| duflu | So it drops (stutters) when it could be rendering smoothly | 08:25 |
| duflu | Although dropping should appear in the log. Hmm | 08:26 |
| duflu | Bah, words. They're often wrong. | 08:32 |
| * duflu is still excited about the potential for simple improvements in qtmir | 08:32 | |
| === Guest35933 is now known as mibofra | ||
| alan_g | anpok_: you merged the g++-5 changes to 0.14 - does that mean yet another attempt to land has started? | 08:48 |
| anpok_ | yes | 08:49 |
| alan_g | /sigh - I was hoping it meant 0.14 had landed and 0.14.1 was speeding through | 08:49 |
| anpok_ | this time u-s-c boottest failed as it only upgraded mirserver and client libraries | 08:49 |
| anpok_ | but not the drivers | 08:49 |
| anpok_ | hence tries to boot without drivers | 08:50 |
| === vesar_lunch is now known as vesar | ||
| alan_g | the team will owe you a drink for this release | 08:50 |
| anpok_ | when I reverted the driver abi bump (we did not bump it during the 0.14 period) assumed that it might not be broken .. | 08:50 |
| alan_g | s/drink/large drink/ | 08:50 |
| anpok_ | not mir bootest fails (in silo 004 still) | 08:51 |
| anpok_ | -not +now | 08:51 |
| anpok_ | because guess what .. there was an abi break we missed.. | 08:51 |
| anpok_ | now looking into efficient ways to find it | 08:51 |
| anpok_ | and yeah merged the g++5 fixes.. | 08:52 |
| anpok_ | I hoped a karma improvement like that might improve our odds | 08:52 |
| alan_g | Early, automated detection is what we need. Not at the tail end of s stupidly involved manual process. | 08:53 |
| anpok_ | yes.. | 08:54 |
| duflu | greyback: Is it certain that QTimer::singleShot(0, this, SLOT(update())) will schedule a second frame (16ms later) or is there a risk it could coalesce into the current one being drawn? | 09:03 |
| duflu | I guess it assumes everyone is on a single threaded event loop | 09:04 |
| greyback | duflu: that call executed on the renderer thread. That appends an event to the main GUI thread (with the main event loop) to call the update() function, which indicates the scene is dirty, and tells the renderer to schedule a new pass | 09:08 |
| duflu | greyback: Even when the current pass is still pending? It doesn't get cleared at the end of the pass? | 09:09 |
| duflu | Hopefully at the beginning.. | 09:09 |
| greyback | duflu: the current pass is in progress when that is called | 09:09 |
| duflu | greyback: I know. That's why I'm asking. Is it clever enough to know the current frame's not finished and a second one after that is needed? | 09:10 |
| greyback | duflu: that's exactly what it's doing. I think it's reliable, it will schedule a second frame if there's another client buffer ready for compositing | 09:10 |
| duflu | greyback: Yeah in theory we'd see more bugs if it didn't work, but I still want to verify | 09:11 |
| greyback | code is a bit clunky tho, I'll admit that | 09:11 |
| duflu | Actually it's about right for an event loop design. Only the Q* syntax is unfamiliar for me | 09:12 |
| greyback | you'll get used to it ;) | 09:12 |
| duflu | greyback: On a different note, is there somewhere you can put code to execute after the eglSwapBuffers? | 09:21 |
| duflu | greyback: Oh, found it. Sorry | 09:23 |
| greyback | duflu: I know what you're thinking ;) I did try a prototype to release buffers earlier, but can't find it now | 09:23 |
| duflu | greyback: Yeah, it's a tangential thought. I should stay on the first task really | 09:24 |
| greyback | ah found it | 09:25 |
| greyback | lp:~gerboland/qtmir/remove-custom-framepump1/ | 09:26 |
| greyback | was causing rendering bugs tho | 09:26 |
| duflu | greyback: OK, yes fair enough | 09:28 |
| duflu | OK, bad news and good news... | 09:46 |
| duflu | Bad news: When dynamic double buffering is working properly it may not be beneficial to Unity8. | 09:46 |
| duflu | Good news: Predictive bypass (already landed and coming in 0.15) seems to raise frame rates by 25-35% (!) | 09:47 |
| duflu | Which really means it avoids frame skipping | 09:47 |
| greyback | duflu: why not beneficial to u8? As a server, or as a client of USC? | 09:49 |
| duflu | greyback: As a client of USC... I should have noticed -- any surface that's bypassed/overlaid (like the fullscreen U8) doesn't get dynamic double buffering. Due to the extra compositor demands of bypass/overlays | 09:50 |
| duflu | Predictive bypass reduces the problem, but apparently not enough | 09:50 |
| greyback | duflu: sounds like we should test and see for sure | 09:51 |
| duflu | greyback: I am. And it's not fun. Although in my full stack test with 0.14 predictive bypass was missing. So maybe it will free up the Unity stack enough to get the benefit back. It doesn't when running the pure 0.15 mir demos, is all | 09:52 |
| greyback | ok | 09:53 |
| duflu | Too many variables | 09:55 |
| duflu | greyback: In theory you could achieve a similar benefit in QtMir for apps by changing that zero-millisecond timer to something non-zero (but still short enough to not miss frames) | 09:57 |
| duflu | Or maybe not. Other parts might need to change too before there's any benefit there | 09:58 |
| greyback | duflu: why delay the timer? If we know there's a new frame to be composited, we might as well schedule a new renderer pass immediately | 09:58 |
| duflu | greyback: Hmm actually if the texture update for all surfaces is delayed in the same way, maybe not | 09:59 |
| duflu | It only works if you know your max render time and have room to play with. So not a good idea for GL on a mobile device I guess | 10:00 |
| greyback | yep | 10:01 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === chihchun is now known as chihchun_afk | ||
| racarr | Good morning! | 16:06 |
| === dandrader_ is now known as dandrader | ||
| kgunn | racarr: gm | 16:29 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|EOD | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun_afk is now known as chihchun | ||
| wulfensteyn | um.. on wily (mir 0.14) clicking on gedit menu crashes unity | 22:07 |
| wulfensteyn | also some strange crashes with gnome-calculator on demo server | 22:07 |
| wulfensteyn | the keyboard works fine now :D the key repeat rate seems to be fixed | 22:08 |
| wulfensteyn | +1 | 22:09 |
| bschaefer | mcphail, popey https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI | 22:42 |
| bschaefer | is the new branch which is moving to the new mir ABI (though im using trunk mir | 22:43 |
| bschaefer | ) | 22:43 |
| bschaefer | sooo you'll need a pretty new mir atm (not 100% how far off it is from main) | 22:43 |
| bschaefer | ill try to get a ppa with the right version of mir on it | 22:43 |
| popey | hello! | 22:49 |
| popey | that's something to play with at the weekend :) | 22:49 |
| bschaefer | popey, sweet :) | 22:56 |
| bschaefer | popey, i should be around irc, soo just poke me at any point! | 22:56 |
| robert_ancell | Does anyone know if Unity8 is planning to support client side decorations for applications (e.g. GNOME applications that are drawing a HeaderBar). | 23:30 |
| robert_ancell | Asking here because I guess a Mir surface will have to hint if it should be decorated | 23:33 |
| Trevinho | mh, wondering the same... | 23:37 |
| robert_ancell | I guess we'd need a mir_surface_spec_set_decorated() or similar | 23:38 |
| robert_ancell | bschaefer, Do you mean the Mir 0.14 API? That's in wily now | 23:42 |
| robert_ancell | oh, 0.15. | 23:43 |
| bschaefer | robert_ancell, aiming at trunk mir | 23:43 |
| bschaefer | soo 0.15, but i dont think there was an API change from 0.14 --> 0.15 | 23:44 |
| bschaefer | but theres some new stuff | 23:44 |
| robert_ancell | Most of that branch is Mir 0.14 I think | 23:44 |
| bschaefer | yeah, waiting on some new 0.15 stuff to land (relative mouse support and an egl pixel format thing) | 23:45 |
| bschaefer | relative landed soo i just need to implement those changes | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!