| racarr | annnnd race resolved | 00:08 |
|---|---|---|
| thomi | anyone awake in here? RAOF perhaps? | 03:21 |
| thomi | I'm pretty sure I've found another race condition in mir - this time in the client library. :-/ | 03:23 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| alan_g | alf__: re Thomi's email "Mir client library thread safety" - shall I deal with this one? | 08:19 |
| alf__ | alan_g: I haven't started looking into it yet, so feel free to take it | 08:20 |
| === mmrazik is now known as mmrazik|lunch | ||
| hikiko | wow what sort of magic does boost and when you assign a foo shared ptr to a bar shared ptr the ptr has knowledge of the correct type? | 10:38 |
| hikiko | it's not based at the template parameter at all | 10:38 |
| hikiko | :s/boost/std now :) | 10:39 |
| alan_g | hikiko: the first "magic" pointer was this one http://www.octopull.co.uk/arglib/TheGrin.html - shared_ptr is clever - it also allows a user defined deleter | 10:48 |
| hikiko | yes yes!! i just saw the boost documentation hehe :) but i can't imagine how the hell they implemented it!!! | 10:50 |
| hikiko | i tried without the make shared to see where's the magic and it was in the assignment, then I found the doc but still!! i don't understand it! | 10:51 |
| hikiko | I got how it works though :) cool!!! | 10:51 |
| alan_g | :) | 10:52 |
| alan_g | hikiko: have you seen https://code.launchpad.net/~alan-griffiths/mir/Wno-non-virtual-dtor/+merge/165551 ? | 10:58 |
| hikiko | oh no I didn't :) I started geting mir notifications today, that's cool :D | 11:01 |
| hikiko | so, you get a warning | 11:01 |
| hikiko | immediately | 11:01 |
| hikiko | btw alan_g does it happen to you to trigger internal compiler errors with gcc 4.7? | 11:01 |
| alan_g | It happens to everyone | 11:02 |
| hikiko | cool :) i am not the only one :) | 11:02 |
| alan_g | Is a bug in 4.7.2 | 11:02 |
| hikiko | i switch to clang from time to time, when I have no info about the error at all | 11:03 |
| hikiko | but i hope they fix it soon! | 11:04 |
| alan_g | hikiko: it is fixed upstream | 11:04 |
| hikiko | oh cool then I can just compile the new version | 11:05 |
| alf__ | alan_g: hikiko: I have 4.7.3 (from raring archives) and I haven't seen compiler errors for a while. I am not sure if 4.7.3 contains the fix, or I have been lucky enough not to trigger them... | 11:07 |
| === mzanetti is now known as mzanetti|lunch | ||
| alan_g | alf__: it is fixed in 4.7.4 (and 4.8_ | 11:11 |
| alf__ | alan_g: perhaps the fix has been backported to the ubuntu 4.7.3 packages? | 11:13 |
| alan_g | alf__: no, you've just not compiled bad code | 11:15 |
| alf__ | alan_g: ok | 11:15 |
| hikiko | hmm i have 4.7.3 | 11:16 |
| hikiko | maybe i have to compile the 4.7.4 :) | 11:17 |
| === alan_g is now known as alan_g|lunch | ||
| === mzanetti|lunch is now known as mzanetti | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === alan_g|lunch is now known as alan_g | ||
| === mmrazik is now known as mmrazik|afk | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| kdub | good morning, status, working on swapinterval 0 for clients | 15:00 |
| alan_g | Good afternoon. status tweaking code to get the customisation points I want | 15:01 |
| alf__ | kdub: does that involve BufferSwapperMultiSpin? | 15:05 |
| kdub | alan_g, alf__ with adding a swapping algorithm for swapinterval0, i'm weighing 1) just making BufferSwapperMulti more capable or 2) making BufferBundleSurfaces able to change between different algorithms | 15:05 |
| kdub | thoughts? | 15:05 |
| kdub | i'm sort of leaning towards 2), just because we'll have resizing, composition bypass, synchronous and asynchronous modes | 15:06 |
| alan_g | kdub: changing algorithms is something that might help switching to/from composition bypass | 15:07 |
| alf__ | status: investigating performance issues in Mesa (for some reason we wait for a GPU fence for ~5ms every frame, which doesn't happen for X11) | 15:07 |
| alf__ | kdub: I vote for (2), too. Btw, in order to get some performance numbers for the Mesa investigation I hacked together a spin version of BufferSwapper (not properly validated or tested though) | 15:08 |
| alf__ | kdub: I can push it somewhere if you are interested | 15:08 |
| alan_g | kdub: for the avoidance of doubt: +1 for 2 | 15:09 |
| kdub | alf__, yeah, that sounds useful for looking at android performance in the meantime | 15:10 |
| alf__ | kdub: ... or if your plate is full, I can take on the spin bufferswapper work | 15:11 |
| kdub | alf__, i think today i'll focus on making the mc::BufferBundleSurfaces switch between mc::BufferSwapper algorithms | 15:13 |
| kdub | so if on monday you want to write a mc::BufferSwapperSpin : public mc::BufferSwapper, that sounds like a good parallelization of work :) | 15:13 |
| alf__ | kdub: sounds good to me, too :) | 15:14 |
| alan_g | sounds excellent to me too. ;) | 15:15 |
| alan_g | kdub: what's the motivation for mga::GraphicBufferAllocator (AFAICS it adds alloc_buffer_platform(), which doesn't really do anything other than expose a different interface to what alloc_buffer() already does). | 15:17 |
| kdub | alan_g, admittedly its a bit weird... but there's a mc::BufferUsage and an mga::BufferUsage, with the only difference being that mga::BufferUsage has a framebuffer type | 15:18 |
| kdub | that android needs to allocate in the android platform, and in the review of the branch, we decided not to put the use_framebuffer type in mc::BufferUsage, because its not relevant to gbm | 15:19 |
| alf__ | kdub: alan_g: IIRC, the reason was because BufferUsage::framebuffer was not relevant to/needed by the compositor interface, it is an internal Android flag. | 15:23 |
| alan_g | kdub: OK, that fine point was eluding me. So the real question then is should we really be extending the mc::GraphicBufferAllocator interface to give us an interface for allocate frame buffers. (Or should that be a different interface.) *Thinks..." | 15:23 |
| kdub | oh, also, us bank holiday on monday | 15:29 |
| alan_g | kdub: uk too | 15:31 |
| alan_g | And the sun has just come out here... | 15:31 |
| alf__ | hikiko: Hi! Any news about the VT runtime issue we were discussing yesterday? I am curious about what could be going on there. | 15:32 |
| alf__ | alan_g: The cosmos is telling you to end your week/day ;) | 15:33 |
| alan_g | alf__: the cosmos has to wait - I want to get something finished first. ;) | 15:33 |
| alf__ | alan_g: :) | 15:35 |
| hikiko | lol @alan, alf__ sorry i am busy with something this very moment I'll ping you later | 15:39 |
| alf__ | hikiko: np | 15:52 |
| kgunn | kdub: alf ....read the scroll back, just wondering....the reason to create a mga::BufferUsage was to avoid having an android flag in the compositor ? | 15:56 |
| kgunn | but conceptually...it just means "this is a frame buffer" | 15:56 |
| kgunn | right? | 15:56 |
| kdub | right, but gbm doesn't need to make a distinction | 15:57 |
| kgunn | kdub: sure....but it doesn't hurt to have that info along for the ride either does it ? | 15:57 |
| kgunn | note...you can tell me, too late...don't unearth this :) | 15:57 |
| kgunn | just thinking that offscreen & fb's have so much in common... | 15:58 |
| kgunn | kdub: back to alan_g 's question about should it have a seperate interface for fb alloc | 16:00 |
| kgunn | i suppose to match it should | 16:00 |
| alan_g | kgunn: I've already split the interfaces on my WIP - don't think too hard about it. | 16:00 |
| kgunn | :) | 16:02 |
| kgunn | alan_g: i might hurt myself | 16:02 |
| alan_g | kgunn: I hope that's not a threat. ;^) | 16:03 |
| alf__ | kgunn: the reason for mga::BufferUsage, isn't so much that gbm doesn't need the flag. It's that the compositor interface (which mc::BufferUsage is part of) doesn't need the flag. We would be adding a flag to the external interface just to service an internal need of an unrelated component. Of course, this may change if we want to allow external (to the compositor) entities to ask for framebuffer surfaces. | 16:03 |
| alf__ | kgunn: (to ask the compositor components for fb surfaces) | 16:04 |
| kgunn | alf__: thanks, makes sense.... (you guys prob consider sloppy, but i don't mind having things for "other clients" in api's) | 16:05 |
| alan_g | kgunn: it depends on the type of API - here we're defining the *minimum* needs of compositor to minimise coupling. | 16:07 |
| kgunn | actually making me think...so would control for going in/out of bypass lie in the unity-mir layer ? | 16:07 |
| kgunn | e.g. is the compositor going to be smart (oh you're opaque & full screen)...or dumb (special wm client, you tell me when you want to go straght to fb) | 16:08 |
| kdub | off the top of my head, i'd say it wouldn't bypass the unity-mir layer, (be dumb) | 16:11 |
| alan_g | kgunn: I don't need to decide that (yet). ;) | 16:11 |
| kdub | yeah, we haven't grappled with the question fully | 16:11 |
| kdub | yet! | 16:11 |
| alan_g | 1. Get a CB mode working 2. Get CB mode switchable 3. Decide how to chose CB mode. | 16:13 |
| kgunn | alan_g: ;) sure...i just enjoy topics like this | 16:14 |
| alan_g | kgunn: np this is how I get informed before the decision needs to be made | 16:15 |
| kgunn | :) | 16:15 |
| alan_g | And the sun has just come out here...(again - following dark clouds and heavy rain). Must be time to go. | 17:03 |
| alan_g | kdub: kgunn - have a good holiday weekend! | 17:06 |
| === alan_g is now known as alan_g|EOW | ||
| kdub | you too alan_g|EOW | 17:06 |
| kgunn | alan_g|EOW: you too | 17:19 |
| kdub | i'm tempted to name this class mir::compositor::SwapperSwapper | 17:24 |
| racarr | kdub: For resizing? | 17:48 |
| racarr | I thought about a swapperswapper once XD | 17:49 |
| kdub | i think SwapperSwitcher is a better name | 17:49 |
| racarr | yes probably | 17:50 |
| === francisco is now known as Guest60367 | ||
| racarr | just drudging through some clean up, resolving little todos I left around on this input branch | 18:32 |
| racarr | fixed the race in the acceptance test though, and touch input picking with multiple clients is working well :) | 18:33 |
| racarr | :D | 19:01 |
| racarr | completely removed the mir::input::android namespace | 19:02 |
| racarr | from default server configuration | 19:02 |
| racarr | Lunch/laundromat time! | 20:12 |
| racarr | My present for all of you to joyfully review come monday: https://code.launchpad.net/~robertcarr/mir/rebuild-input-targeting/+merge/165712 ;) | 22:48 |
| kdub | only the runner up to the biggest diff this month :) | 23:04 |
| kdub | after glm removal | 23:04 |
| racarr | kdub: XD. Besides the acceptance test it's actually | 23:06 |
| racarr | pretty balanced in +/- | 23:06 |
| racarr | it's just different | 23:06 |
| racarr | it just made me giggle when I checked at the end... | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!