[00:44] <bschaefer> RAOF, hey, how would one force mir to do double buffering? Seeing interesting issues/flashing (looks like the third buffer might be to much?)
[00:45] <RAOF> bschaefer: I think you need to twiddle with the code to do that.
[00:45] <bschaefer> RAOF, cool, ill dig into that :). Thanks!
[00:46] <RAOF> bschaefer: Also, on desktop, bypass *requires* triple buffering. But you don't necessarily care about that if you're just debugging.
[00:46] <bschaefer> RAOF, yeah, im just checking if its my code, or the apps code
[00:47] <RAOF> bschaefer: You could also check the age on the buffer, client side, to detect if it's being triple buffered.
[00:47] <bschaefer> as this is the only time i've seen the need for a frame damage using opengles + sdl
[00:47] <bschaefer> thats a good idea as well
[00:47] <bschaefer> RAOF, testing qemu out
[00:48] <bschaefer> the current image i see: http://i.imgur.com/RZg6uhx.jpg (it only updates the textures on whats changed)
[00:50] <RAOF> Whee!
[00:50] <bschaefer> :), it'll be nice to get working haha
[00:50] <RAOF> Also, maybe tiling?
[00:51] <RAOF> Hm
[00:51] <bschaefer> hmm, i think that image is after its freaking out
[00:51] <bschaefer> when i throw a clear in
[00:52] <bschaefer> i can see the textures updating only where somethings changed + width of the window
[00:52] <bschaefer> so each frame, it updates a chunk of the window, but adding in buffers it seems to be flashing
[00:53] <bschaefer> possibly an alpha issue?
[00:53] <bschaefer> as i was running into an alpha issue with the pixel format before...
[00:54] <bschaefer> (as with RGBA8888 selected for the texture + surface, i was getting an empty/grey window)
[00:54] <bschaefer> forcing RGBX8888 let me see the textures
[01:00] <RAOF> Hm.
[01:00] <bschaefer> RAOF, ill show you two pictures of one clearing each frame, and one doing it how it normal is
[01:01] <bschaefer> RAOF, otherwise ill debug what i can, and show you in malta
[01:01] <RAOF> Yeah. Yay Malta!
[01:01] <bschaefer> its going to be to warm :(
[01:01] <bschaefer> but yay!
[01:02] <bschaefer> RAOF, glClear before each from being drawn: http://i.imgur.com/MYUcRda.jpg
[01:03] <bschaefer> RAOF, no Clear:  http://i.imgur.com/J4IiccE.jpg
[01:03] <bschaefer> but yeah, ill see what i can find out :)
[01:03]  * bschaefer should have use mir screen cast
[01:03] <RAOF> :)
[01:37] <duflu> bschaefer: I see nice screenshots. The gaps could well be Qemu's fault. But also check you're not relying on buffer-age. Just in case...
[01:43] <bschaefer> duflu, sounds good
[01:43] <bschaefer> duflu, im not 100% the issue, but ill dig around some more :)
[01:43] <duflu> bschaefer: Also see if SDL2 on X11 has the same bugs ;)
[01:44] <duflu> Qemu's SDL2 is new and possibly buggy in damage tracking
[01:45] <bschaefer> duflu, works fine on X11 :(
[01:45] <bschaefer> well actually
[01:45] <bschaefer> i cant get the ubuntu iso install to come up
[01:45] <bschaefer> possibly a bug there yeah
[01:45] <duflu> bschaefer: OK then any simple SDL2 demos have similar issues?
[01:45] <bschaefer> duflu, nope
[01:45] <bschaefer> only sdl1.2
[01:45] <bschaefer> with software rendering
[01:46] <bschaefer> which i fixed with frame damage
[01:47] <bschaefer> duflu, i also dont know qemu very well or how to use haha
[01:47] <duflu> bschaefer: BTW if the mouse doesn't interact properly try: qemu -usbdevice tablet
[01:47] <bschaefer> o nice, i've not even gotten to try the mouse out
[01:47] <bschaefer> as the keyboard works
[01:47] <bschaefer> so thats what i've been tessting
[01:47] <duflu> Running Qemu in tablet mode will avoid it wanting grabs (which Mir lacks)
[01:49] <bschaefer> yeah, thats something racarr__ brought up :), my main goal was to make pixels look good
[01:49] <bschaefer> duflu, the only way to get sdl2 running as well is disable gtk and set sdl to 2.0
[01:49]  * bschaefer hopes its in their damage code
[01:55] <duflu> bschaefer: You mentioned 1.2... I thought you didn't support 1.2?
[01:55] <duflu> If you do then Qemu's SDL1.2 support is much more mature
[01:55] <bschaefer> duflu, i have a branch for it, but they aren't accepting patches :(
[01:55] <duflu> bschaefer: Oh, fair point
[01:55] <bschaefer> duflu, another reason, is they are creating a layer to turn 1.2 SDL API to 2,.0
[01:55] <bschaefer> 2.0
[01:56] <bschaefer> soo onces that layers there, we'll get all of 1.2 for free :)
[01:56] <bschaefer> but yeah, i should test it out on 1.2
[02:34] <RAOF> To the luncheon wagon!
[06:20] <duflu> ping anpok
[06:24] <anpok> pong
[06:25] <anpok> i have the same gdb issue you had
[06:25] <anpok> or still have?
[06:26] <duflu> anpok: Yeah, it's annoying but in other news...
[06:27] <duflu> anpok: Can you check this out? Seems to have only regressed last night: https://bugs.launchpad.net/bugs/1321077
[06:27] <anpok> oh
[10:03] <alf_> anpok: alan_g: Have you seen https://bugs.launchpad.net/mir/+bug/1321215 locally?
[10:05] <alan_g> alf_: no. But I've not been looking for it.
[10:06] <alf_> alan_g: I wasn't looking for it either, it came looking for me :)
[10:06]  * alan_g thinks CustomInputDispatcherFixture.custom_input_dispatcher_gets_started_and_stopped is a redundant name
[10:06] <alan_g> alf_: let me grab latest updates and try it
[10:13] <alan_g> alf_: this is just running on the phone? Or do you see it on desktop too?
[10:13] <alf_> alan_g: I can reproduce it locally on the desktop 100%
[10:13] <anpok> alf_: me neither
[10:14] <alan_g> alf_: I hit it after 232 iterations on desktop
[10:14] <alf_> alan_g: anpok: thanks, I have started investigating it, stay tuned
[10:15] <alf_> anpok: when/where is InputDispatcher.start()/stop() supposed to be called ?
[10:16] <alan_g> alf_: while you're there: CustomInputDispatcher.gets_started_and_stopped would be a better name.
[10:16] <anpok> alf_: as part of the DisplayServer start and stop proces..
[10:16] <alf_> alan_g: ack
[10:16] <anpok> oh it seems to not wait for completion
[10:44] <anpok> alf_: when I terminate the server process manually it did not fail within 2000 tries (which it did before) but I thougt the text fixture tear down does that already..
[10:44] <alf_> anpok: I am almost done with an alternative solution, I will ping you
[10:44] <anpok> oh it still fails
[10:45] <anpok> just need to have more load
[10:45] <anpok> ok
[11:23] <Saviq> hey guys, we seem to have an issue on android with the new Qt 5.3: https://bugs.launchpad.net/unity8/+bug/1321189
[11:24] <Saviq> for some reason ShaderEffectSource, which is a component in QML that is, in essence, creating a texture from a QML element, for consumption in a shader
[11:24] <Saviq> stopped working
[11:25] <Saviq> everywhere it's used, it goes black
[11:25] <Saviq> it's fine on X and on Mir on desktop, but affects all our three android devices
[11:26] <Saviq> and we're out of our depth on this now
[11:26] <greyback> Saviq: are any shader errors reported on the console?
[11:27] <Saviq> greyback, no
[11:28] <greyback> Saviq: and even a simple qml file using a ShaderEffectSource has this problem?
[11:28] <Saviq> greyback, yeah http://paste.ubuntu.com/7492386/
[11:28] <Saviq> greyback, is black instead of red, see https://bugs.launchpad.net/unity8/+bug/1321189/+attachment/4116145/+files/mako.png vs. https://bugs.launchpad.net/unity8/+bug/1321189/+attachment/4116146/+files/mako_good.png
[11:28] <Saviq> fooking barrier
[11:32] <greyback> Saviq: first step I'd take: capture an API trace - https://github.com/apitrace/apitrace
[11:32] <greyback> is available in the repos
[11:35] <alf_> anpok: https://code.launchpad.net/~afrantzis/mir/fix-1321215/+merge/220228
[11:44] <RAOF> alan_g: Yo! Are you available to talk about 1hz-rendering?
[11:45] <alan_g> RAOF: If you want me to
[11:46] <RAOF> I've written a follow-up comment. After you've read that, what would you like to see done?
[11:47]  * alan_g goes to look
[11:51] <RAOF> greyback: There'll be a shiny new apitrace 5.0 in the repos soon, too :)
[11:51] <greyback> RAOF: good, because 4.0 chokes on eglBindAPI :)
[11:51] <RAOF> greyback: That might be awkward
[11:51]  * greyback wants to try vogl too
[12:07] <alan_g> RAOF: I'm not convinced by the abstraction or the naming. But I do like the overall solution. I could just abstain.
[12:08] <RAOF> alan_g: I'll need to fix the merge conflict anyway (tomorrow); perhaps alf_ could weigh in, also.
[12:09] <RAOF> alan_g: Adding the last bits of frame dropping policy to FrameDroppingPolicy seems sensible to me, at least.
[12:19] <alan_g> Maybe SwapStateObserver <- FrameDroppingPolicy <- TimeoutFrameDroppingPolicy?
[12:21] <RAOF> That would make sense. BufferQueue would still construct a FrameDroppingPolicy from a FrameDroppingPolicyFactory, though. It'd just store it in a std::unique_ptr<SwapStateObserver> rather than std::unique_ptr<FrameDroppingPolicy>
[12:31]  * RAOF → sleep
[13:02] <Saviq> greyback, so yeah, it choked here on eglBindAPI
[13:02] <Saviq> greyback, pointers?
[13:02] <greyback> Saviq: recompile qtubuntu without that call. Frankly, that call should not be happening on arm
[13:03] <Saviq> oh ya
[13:03] <Saviq> y
[13:03] <Saviq> RAOF, anywhere I could get the 5.0 of apitrace already?
[13:03] <greyback> Saviq: tried it, chokes there too
[13:03] <Saviq> grr
[13:03] <greyback> sorry
[13:04] <Saviq> ok me builds
[13:08] <kgunn> alf_: alan_g|lunch AlbertA ... so do i understand it correct on 1hz-rendering-always MP, we seem ok with the approach for putting policy in bufferqueue, but we would want a follow up second effort for shell to be able to override policy ?
[13:09] <kgunn> sorry if i missed any irc chat on this...but i've been keeping an eye on this one, hoping we'll land it soon (as to put some road mileaage on it before promoting)
[13:22] <alan_g> kgunn: There's no real objection to separating a "policy" out - just a lack of clarity about what's separated out and how best to name it. (Although IMO separating out a configurable "policy" is premature until we can see what (if anything) needs separating out.)
[13:25] <kgunn> alan_g: ack
[13:30] <alan_g> You could have missed some IRC between RAOF and me about 90mins ago: There'll be a new version his "tomorrow". He's got some conflicts to address before it can land, and I'm happy enough with the general approach not to block.
[13:33] <kgunn> alan_g: thanks
[13:33] <kgunn> greyback: so when you overrride displaybuffercompositor
[13:33] <kgunn> will you auto-magically also use hwc ?
[13:33] <kgunn> or i'm guessing you'll need to "do some effort" there
[13:34] <kgunn> (which is hopefully a copy paste)
[13:34] <greyback> kgunn: no, effort needed. bypass might work tho
[13:34] <kgunn> ah...cool
[13:34] <kgunn> so we architected it right :)
[13:59] <mterry> greyback, btw, I filed https://code.launchpad.net/~mterry/unity-mir/dont-hide-focused-apps/+merge/220130 yesterday
[13:59] <mterry> About the hiding of suspended apps we talked about
[14:31] <AlbertA> kgunn: not so much sheller but other parts of the system should AUGMENT the policy
[14:31] <AlbertA> kgunn: meaning the policy should only be activated on display off/occlusion events
[15:01] <greyback> mterry: I added comment on your MR
[15:53] <kdub_> greyback, (kgunn) with that convo about getting bypass or hwc to work about 3h ago... would something like this (which works with hwc) get hwc to work for you?
[15:53] <kdub_> http://bazaar.launchpad.net/~kdub/mir/future-default-display-buffer-compositor/view/head:/src/server/compositor/default_display_buffer_compositor.cpp
[15:54] <kdub_> thats my integrated hwc-working branch (stuck behind some other branches at the moment)
[15:54] <kdub_> I also want to rip out that weird lines 60-62 and lines 82-86
[15:57] <greyback> kdub_: almost, main issue I see is that your use of HWC is an if/else. I'll probably have to render, but also call post_renderables_if_optimizable(renderable_list) - because the scenegraph contains things that are not Renderables
[15:58] <greyback> e.g. a non-fullscreen app, for iteration one, the panel is not in its own surface, but drawn explicitly with GL calls
[16:00] <kdub_> greyback, ack, that's the key, is to condense things into renderables where its simple to do so, and use gl where it can't be represented by a RenderableList
[16:00] <greyback> kdub_: agreed, but this is iteration 1
[16:00] <kdub_> because that abstracts the hwc stuff away, and the compositor writer just thinks in terms of 'can this be a RenderableList'
[16:00] <greyback> kdub_: so in time, we can move to using RenderableList as much as possible
[16:00] <greyback> but we're not going to be there for a while yet
[16:01] <kdub_> greyback, cool, just checking that its still pulling in a sensible direction
[16:01] <greyback> kdub_: yep, no objections so far
[23:08] <RAOF> Saviq, greyback: If you want it, http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/apitrace.git;a=shortlog;h=refs/heads/master is where you can find apitrace 5.0; git buildpackage will know what to do with it.