[10:01] <vintox> hi guys
[10:02] <vintox> can someone help me with compiz please?
[10:40] <mzanetti> dednick: hey, the unlock SIM entry is gone again
[10:42] <dednick> mzanetti: can you run the indicators-client and get a copy of the network indicator info?
[10:42] <mzanetti> dednick: how?
[10:43] <mzanetti> dednick: do I need to install the indicators-client?
[10:43] <mzanetti> dednick: 'cause this is a read only dogfooding phone
[10:43] <dednick> mzanetti: yeah
[10:44] <mzanetti> but I guess I can make it writable to debug this and then flash it again
[10:44] <dednick> and then. in the indicators-client, click on the network indicator, and de-select enable visual representation
[10:44] <mzanetti> dednick: ok. will take a bit as I have an appointment soon and when I come back a bunch of meetings. but I'll try to get it debugged today
[10:44] <dednick> mzanetti: ok. thanks
[11:08] <mzanetti> greyback: check out the last comments on that bug... I'm not sure what to do with it tbh
[11:10] <mzanetti> greyback: basically what it says is that we shouldn't ever use stopApplication() but just close the app's window and hope that the app is implemented in a way that it calls quit() on its own when the window closes
[11:11] <greyback> mzanetti: I'm not sure if mir let's shell close a surface right now
[11:11] <greyback> lets
[11:17] <mzanetti> greyback: but isn't that what's already happening?
[11:20] <greyback> mzanetti: we start/stop apps, but we don't close their surfaces on them, just hide them
[11:23] <mzanetti> hmm.. ok
[11:45] <sil2100> tsdgeos: hi! Saviq not around today?
[11:45] <tsdgeos> sil2100: he's travelling back home
[11:45] <tsdgeos> sil2100: maybe in the late afternoon/eveining
[11:46] <sil2100> ah, thanks
[11:46] <sil2100> tsdgeos: anyway, since you might know some info about this one - did you have any time to look into https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1256360 ?
[11:46] <sil2100> tsdgeos: I have been told that management thinks about making that a promotion blocker ;/
[11:48] <tsdgeos> sil2100: that's only on shutdown of unity8
[11:48] <tsdgeos> least important thing ever imho
[11:48] <tsdgeos> that's all i can say :D
[11:48] <sil2100> tsdgeos: yeah, well, I'm not management so ;p
[11:48] <tsdgeos> i can show you much more worse things i'd like to consider a blocker
[11:48] <sil2100> tsdgeos: I also thought about it as low prio, but it seems there are people that want this gone
[11:48] <tsdgeos> sil2100: i did not look at it at all, you'll have to get Saviq
[11:49] <sil2100> k, thanks ;)
[11:49] <tsdgeos> i mean
[11:49] <tsdgeos> i did look at it but not past the "ok it's on crash not important"
[11:49] <tsdgeos> phase
[12:52] <Oxid> Всем привет. Кто может помочь? Панель Unity (ширина) не учитывается, получается ширина окон больше на ширину панели, края окон срезаются.
[12:53] <xnox> Oxid: please try #ubuntu-ru there are not that many russian speaking people here.
[12:53] <Zhenech> Oxid, this is mostly a development related and english speaking channel
[12:53] <xnox> Oxid: or try in english, if you can =)
[12:53] <Oxid> ok :)
[12:58] <Oxid> Hello. Who can help? Panel Unity (width) is not taken into account, it turns out windows more width to the width of the panel, the edges beveled windows.
[13:02] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/carouselLastItemClick/+merge/214230
[13:03] <tsdgeos> or mzanetti: https://code.launchpad.net/~aacid/unity8/carouselLastItemClick/+merge/214230
[13:05] <Cimi> tsdgeos, why no stepanimation at end?
[13:05] <Cimi> I'm not convinced
[13:05] <tsdgeos> Cimi: ?
[13:05] <tsdgeos> i do have a stepanimation at end
[13:05] <tsdgeos> you didn't
[13:05] <tsdgeos> so convince yourself
[13:06] <tsdgeos> and then go review the code again
[13:06] <tsdgeos> and even may use tryCarousel
[13:06] <tsdgeos> before commenting on it :)
[13:06] <Cimi> ahahah
[13:06] <Cimi> tsdgeos, so why you added it?
[13:06] <tsdgeos> because
[13:07] <tsdgeos> i'm pretty sure the only reason it was there it was because the last x calculation was buggy
[13:07] <tsdgeos> as it was (since that's the other thing i fixed)
[13:07] <tsdgeos> and that was only there to hide it
[13:08] <tsdgeos> note the real fix is inside the getXFromContinuousIndex function
[13:09] <tsdgeos> and anyway i'm not claiming i understand the code, i just claim it fixes stuff ;)
[13:10] <tsdgeos> Cimi: you're free to provide an alternate fix :)
[13:24] <Cimi> tsdgeos, found the original code
[13:24] <Cimi> hold on
[13:27] <Cimi> tsdgeos, actually, this part is missing
[13:27] <Cimi> it comes with a big commit
[13:27] <Cimi> tsdgeos, I'd not approve the branch until I realise what's going omn
[13:28] <tsdgeos> Cimi: that's why i asked you to review
[13:28] <Cimi> tsdgeos, so my idea
[13:28] <Cimi> tsdgeos, is that you can scroll without reaching the end
[13:28] <Cimi> imagine you scroll 98%
[13:29] <Cimi> tsdgeos, in this case you _need? the step animation
[13:29] <tsdgeos> you do
[13:29] <Cimi> ok cool
[13:29] <Cimi> so when you're at the end
[13:29] <Cimi> do you still need it?
[13:29] <tsdgeos> you do
[13:29] <Cimi> nope
[13:29] <tsdgeos> you do because your code checks for < 1 pixel
[13:30] <tsdgeos> and the list with scale and stuff
[13:30] <tsdgeos> it's not that accurate
[13:30] <Cimi> tsdgeos, I'll review the branch properly
[13:30] <tsdgeos> so you basically "reset" the position
[13:30] <Cimi> with manual testing and such
[13:30] <tsdgeos> Cimi: thanks for doing what i asked you to do, that is really helpful :)
[13:33] <tsdgeos> mterry: mornings
[13:33] <mterry> tsdgeos, hello!
[13:34] <tsdgeos> mterry: deja-dup killed my machine this morning on boot :'(
[13:34] <mterry> tsdgeos, killed your machine?
[13:34] <tsdgeos> ate all my RAM
[13:34] <tsdgeos> took me 30 min to kill it and recover from so much swapping :D
[13:35] <mterry> Huh....
[13:35] <mterry> tsdgeos, I've had a report on Fedora of that a while ago, but no one could reproduce
[13:37] <tsdgeos> mterry: i can't either
[13:37] <tsdgeos> rebooted again just to try
[13:37] <tsdgeos> and it all went fine
[13:39] <mterry> tsdgeos, sorry bro  :-/
[13:39] <tsdgeos> mterry: no worries, i know it's close to imposible to debug
[13:39] <tsdgeos> mterry: do you think there's anything i can do to help in the future in case it happens again?
[13:40] <tsdgeos> ls
[13:40] <tsdgeos> wops :D
[13:40] <mterry> tsdgeos, uh...  I guess get a backtrace of what it thinks it's doing.  But that's hard if your system is going kaput
[13:40] <mterry> tsdgeos, do you know if this was the deja-dup-monitor exe or the deja-dup one?
[13:41] <tsdgeos> i remember a monitor in the top/iotop output
[13:41] <tsdgeos> so probably the first
[13:44] <mzanetti> Saviq: you around yet?
[13:44] <tsdgeos> mzanetti: he was travelling this morning, not sure he had time to get home already
[13:55] <mzanetti> greyback: just realized that the bug is only invalid for the settings app.
[13:56] <mzanetti> greyback: I've added the checklist in case we want to land this for now
[14:01] <greyback> mzanetti: ok. I'll have to leave it to you to find out if that solution is acceptable to people
[14:02] <mzanetti> greyback: ok. but if it isn't I'll have to leave the other fix to you :P
[14:02] <greyback> mzanetti: ok
[14:21] <tedg> Saviq, ping bug 1302213
[14:39] <mhr3> didrocks, need your help with the sobump
[14:39] <didrocks> mhr3: sure?
[14:39] <mhr3> didrocks, sure :)
[14:40] <didrocks> ahah, was more "sure, what's up?"
[14:40] <didrocks> but if you are really really sure… :p
[14:40] <mhr3> didrocks, so problem we just realized we have - the libunity-scopesX pkg contains binaries for scoperunner and scoperegistry
[14:40] <mhr3> and those link against the lib
[14:40] <mhr3> but they're not versioned in anyway, so you can't really install both libunity-scopes0 and 1
[14:41] <didrocks> right
[14:41] <didrocks> do you want to?
[14:41] <mhr3> do i just add breaks, replaces, conflicts to 1, to get rid of 0?
[14:41] <didrocks> exactly
[14:41] <didrocks> conflict/replaces/provides
[14:41] <didrocks> rather
[14:41] <mhr3> provides?
[14:41] <didrocks> to help apt to understand the transition
[14:41] <didrocks> yeah
[14:41] <mhr3> no breaks?
[14:41] <didrocks> no
[14:42] <didrocks> how to phrase that
[14:42] <mhr3> and it would provide 0?
[14:42] <didrocks> let's say "breaks is temporary"
[14:42] <didrocks> it's a transiant state
[14:42] <didrocks> but libunity0 would be reinstalled at a later point
[14:42] <didrocks> conflict is definitive
[14:42] <didrocks> yeah, provides is an issue
[14:42] <didrocks> don't set it
[14:42] <didrocks> however, apt may have some troubles upgrading
[14:42] <mhr3> so just conflicts + replaces?
[14:43] <didrocks> how many packages have a dependency on libunity-scopes0?
[14:43] <mhr3> directly, zero
[14:43] <mhr3> it's via libunity-scopes-dev
[14:43] <didrocks> and what's dep on libunity-scopes-dev?
[14:43] <didrocks> not a whole lot I guess
[14:43] <mhr3> 4 pkgs
[14:44] <didrocks> hum
[14:44] <Saviq> mzanetti, now
[14:44] <didrocks> $ reverse-depends libunity-scopes0
[14:44] <didrocks> * unity-plugin-scopes
[14:44] <didrocks> * unity-scope-click [amd64 arm64 armhf i386]
[14:44] <mzanetti> Saviq: wb
[14:44] <didrocks> * unity-scope-mediascanner2
[14:44] <didrocks> * unity-scope-scopes
[14:44] <didrocks> that should be enough
[14:44] <didrocks> to force the transition
[14:44] <didrocks> so yeah, only conflicts + replaces
[14:44] <mhr3> ok
[14:45] <mzanetti> Saviq: on the last 2 comments in here: https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1273781
[14:45] <mzanetti> Saviq: does that mean we don't want this fix? https://code.launchpad.net/~mzanetti/unity-mir/quit-manually-started-procs/+merge/214013
[14:45] <mhr3> didrocks, and the ultimate solution is to start versioning everything, so that 0 and 1 could be installed in parallel, right?
[14:45] <mzanetti> or should we do this for now until Mir properly closes the window
[14:46] <mhr3> didrocks, meaning the "proper" solution
[14:46] <Saviq> mardy, can we SIGTERM the signon-ui for now? ↑↑
[14:47] <didrocks> mhr3: there is no chance for a service using on libunity version to be compatible with the other one?
[14:47] <didrocks> mhr3: like, dbus protocol being compatible? (if any)
[14:47] <Saviq> mzanetti, q:, though, are we SIGSTOP'ing non-upstart apps?
[14:47] <mzanetti> Saviq: yep
[14:48] <mzanetti> Saviq: we get the PID from mir and use that one to SIG*
[14:48] <mzanetti> Saviq: except for closing down we use upstart's PID which isn't set in this case
[14:48] <mhr3> didrocks, scopes by 3rd parties will be built using any released soversion, so we will need to provide compability
[14:48] <Saviq> mzanetti, so SIGTERM isn't enough
[14:48] <Saviq> mzanetti, we need SIGCONT, too
[14:48] <mardy> Saviq: I'd rather not... though in practice I don't think that this will cause big problems
[14:48] <mzanetti> Saviq: I tried. it is enough
[14:49] <didrocks> mhr3: part of the issue is that now britney is only offering you to have one version at any time
[14:49] <Saviq> mzanetti, when a process is SIGSTOP, it can't do anything in reaction to a SIGTERM
[14:49] <didrocks> mhr3: or you need to fork the source
[14:49] <mhr3> didrocks, who's britney? :)
[14:49] <mzanetti> Saviq: also we don't SIGCONT other apps before asking upstart to close them
[14:49] <mhr3> spears?
[14:49] <mardy> Saviq, mzanetti: I'd vote for unconfined processes not to be stopped, if my vote has any importance :-)
[14:49] <didrocks> mhr3: she doesn't sing though :p it's what is handling proposed -> release pocket migration
[14:49] <Saviq> mzanetti, that's different, upstart SIGTERMs and SIGKILLs after 5s
[14:50] <Saviq> mardy, that'd be an interim solution
[14:50] <mhr3> didrocks, we'll need to do something about it
[14:50] <mhr3> didrocks, but it doesn't have to be done now
[14:50] <mardy> Saviq: why interim? Can't it be like that forever?
[14:50] <mhr3> didrocks, haven't reached 1.0 yet :)
[14:50] <Saviq> mardy, I mean SIGTERM would be interim
[14:51] <didrocks> mhr3: yeah, I think we'll have to fork the source or multiple builds from same source…
[14:51] <Saviq> mardy, but anyway, shell has no idea of confined or unconfined
[14:51] <mardy> Saviq: ah, OK
[14:51] <mhr3> didrocks, i guess so :/
[14:51] <mzanetti> mardy: this just handles the case that upstart say "huh, I can't stop that app"
[14:52] <mardy> Saviq, mzanetti: OK
[14:52] <mzanetti> mardy: in this case we send it a SIGTERM (for now). as your suggestion (which I think we all agree with) requires more work in the lower layers first
[14:52] <Saviq> mardy, long-term we'll definitely ask the app to quit gracefully, and probably kill it after a timeout
[14:52] <Saviq> mardy, might be different for trusted helpers, though
[14:52] <mardy> Saviq: what about your idea to send the window closed event to all apps (even those started by upstart), before killing them? That sounded very reasonable to me
[14:52] <mardy> mzanetti: OK, that should be fine
[14:53] <Saviq> mardy, yeah, that'd be the plan
[14:53] <Saviq> mardy, and term/kill after a timeout
[14:53] <Saviq> mardy, but again, trusted helpers will probably be exempt from that
[14:53] <Saviq> mzanetti, but really, you can't TERM an STOP'ed app
[14:54] <Saviq> mzanetti, so either we're not STOPing, which would be a bug in itself
[14:54] <Saviq> mzanetti, or your testing failed :)
[14:54]  * Saviq goes for foo
[14:54] <mzanetti> I tend to agree with you from a theoretical POV, but my observations have been different
[14:54] <Saviq> d
[14:54] <mzanetti> Saviq: wait
[14:55] <mzanetti> will you joing the meetin now?
[14:55] <Saviq> mzanetti, yeah, I mean food like in the kitchen
[14:55] <mardy> wait! The food is poisoned!
[14:55] <mzanetti> :D
[14:55] <mzanetti> ssshhht
[14:58] <tedg> mzanetti, Saviq, so this was an issue for the QA folks, in that they want to stop an app via UAL that Unity has SIGSTOP'd.
[14:58] <Saviq> tedg, yeah, we should SIGCONT them before stopping via UAL
[14:58] <Saviq> tedg, ah
[14:58] <tedg> I'm curious whether we shouldn't be SIGCONT'ing them
[14:58] <Saviq> you mean completely outside
[14:59] <tedg> Yeah, via the test script
[14:59] <Saviq> tedg, yeah, they need to SIGCONT them indeed
[14:59] <Saviq> tedg, upstart will SIGKILL them, though, so they will exit after 5s
[14:59] <tedg> Yeah, and they're seeing that, but they'd like to be able be a little better.
[14:59] <tedg> Is there a way to ask Unity to close an app?
[15:00] <tedg> Like that QA could use.
[15:00] <tedg> I feel a little weird just sending SIGCONT blindly.
[15:01] <mzanetti> Saviq: right... the seems we're failing to SIGSTOP those not started by upstart
[15:01] <Saviq> mzanetti, yeah, I thought so, which might actually be OK
[15:04] <tedg> mzanetti, Saviq, Are you not starting unconfined apps using upstart?
[15:04] <tedg> Well UAL.
[15:05] <mzanetti> tedg: there are some exceptions. if you launch the online-accunts-ui from the settings app for example
[15:05] <mzanetti> tedg: or autopilot runs most of them by system call still
[15:05] <mzanetti> tedg: or qtcreator does currently
[15:05] <tedg> That's just because of the trusted session stuff not being complete?
[15:05] <tedg> Those all go away with the sidestage stuff landing, no?
[15:06] <tedg> i.e. no --desktop_file_hint=
[15:16] <pete-woods> Saviq: just letting you know I fixed the embarrassing build failure in the libusermetrics branch
[15:16] <Saviq> pete-woods, oh ok, didn't know there was one :)
[15:16] <Saviq> pete-woods, will kick the silo again soon
[15:16] <pete-woods> yeah, symbols fail
[15:17] <pete-woods> teach me to push without running bzr bd
[15:47] <kgunn> Saviq: so i asked camako & AlbertA to jump on the "unity8 crashes" during AP that someone debugged to be a mir prob...
[15:47] <kgunn> can someone provide some color commentary ?
[15:48] <kgunn> e.g. it lead back to an old bug we thot was fixed, so i'm thinking diff root cause
[15:48] <tedg> "They're debugging this like a NASCAR race on the last turn! Crashes Everywhere!"
[15:48] <kgunn> just looking for a breadcrumb trail
[15:48]  * tedg does color
[15:48] <kgunn> thanks tedg :) :/
[15:49] <tedg> kgunn, if you can make my phone update faster I'll have less time for IRC :-)
[15:51] <kgunn> lol
[15:52]  * davmor2 slips a 4g chip into tedg  's phone
[15:53] <kgunn> AlbertA: camako ...so i think maybe the more appropriate bug is this one
[15:53] <kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1302550
[15:53] <kgunn> ....which someone dup'd, and probably too quickly imho
[15:56] <AlbertA> kgunn: ahh ok, so this is the more recent occurrence then:
[15:56] <AlbertA> kgunn: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1302550
[15:57] <kgunn> yes
[15:57] <AlbertA> I see
[15:57] <AlbertA> ok I'll take a look
[16:27] <Saviq> tedg, yes, that will go away ultimately
[16:27] <Saviq> kgunn, the glDeleteTextures one?
[16:27] <tedg> Saviq, Will or has? I figured it was already gone :-)
[16:28] <Saviq> tedg, will, has not, yet
[16:28] <Saviq> kgunn, it happens on unity8 exit sometimes
[16:28] <tedg> Saviq, K
[16:28] <tedg> Saviq, Thoughts on the session shutdown?
[16:29] <Saviq> kgunn, so if you just go "while true; do restart unity8; done", you
[16:29] <Saviq> 'll get it after a few runs
[16:29] <Saviq> tedg, I think maybe we should just mimic the gnome-session api?
[16:30] <tedg> Saviq, It's pretty big as it deals with all the session management stuff. The command we're interested in is just "LogOut()"
[16:31] <Saviq> tedg, sure, we can start with that, and grow it as we go
[16:31] <tedg> Saviq, So really you are, if you want to call it LogOut I'm fine with that :-)
[16:31] <Saviq> tedg, think we should put this on the same interface name, or is that a bad thing to do?
[16:31] <Saviq> erm
[16:31] <Saviq> object path I meant
[16:32] <tedg> Saviq, I think it's bad for two reasons, one some but not all is kinda confusing, and two gnome-session is going away upstream. They probably won't keep the path either.
[16:32] <Saviq> tedg, there should be some fdo spec ;)
[16:33] <tedg> There's some work on that.
[16:33] <Saviq> oh, so maybe we could try and go towards that
[16:33] <tedg> Unfortunately it's mixing application management and session management.
[16:34] <tedg> They're focused on the inhibition problem, which we want to go through the Application Lifecycle stuff.
[16:35] <kgunn> AlbertA: camako ....scrollback saviq says just go "while true; do restart unity8; done" you'll hit it after a few runs...
[16:35] <kgunn> its an issue because unity8 is exited for our AP testing
[16:35] <kgunn> camako: AP == autopilot :)
[16:37] <Saviq> kgunn, camako, AlbertA, obvious issue for debugging is that it's running under upstart, you might want to run it under gdb, so `stop unity8`, export MIR_ things (you can check which in initctl get-env --global | grep MIR), and then loop it under gdb
[16:38] <Saviq> SIGILL on startup is expected, so you might go "gdb -ex run -ex continue unity8" or so
[16:39] <greyback> from the bug descriptiong, it's using the app screenshot code, so just starting/stopping unity8 probably won't reproduce it. You need an app to be running
[16:45] <Saviq> greyback, yeah, that description might be wrong
[16:45] <Saviq> greyback, i.e. I initially thought that
[16:45] <Saviq> greyback, but not sure any more
[16:45] <greyback> Saviq: ok
[16:45] <Saviq> I think I got it without apps, too
[16:53] <tedg> Saviq, So, I need a yes/no on adding a logout function. I'll take anything as the path/interface name that you'd like :-)
[16:53]  * tedg reloaded the bug
[16:53] <tedg> Saviq, Thanks!
[17:00] <Saviq> tedg, cheers, hope to make it happen next week
[17:27] <AlbertA> kgunn: I just noticed this branch hasn't landed for a while in papi:
[17:27] <AlbertA> lp:~andreas-pokorny/platform-api/fix-cross-compiling
[17:28] <AlbertA> kgunn: who needs to review it?
[17:29] <AlbertA> anpok:^
[18:29] <om26er> mzanetti, hi
[18:35] <Saviq> mzanetti, one for you: bug #1302761
[19:12] <kgunn> AlbertA: i got sidetracked...but on that papi MP...i'll try to land
[19:27] <AlbertA> kgunn: thanks
[19:45] <AlbertA> Saviq: thanks I used list-env
[19:45] <AlbertA> Saviq: however you do require something exercising the snapshot
[19:45] <AlbertA> Saviq: otherwise there's no texture to delete and no issue
[20:00] <AlbertA> kgunn: camako: I don't have a reproduction case yet, but I think this is simply a case
[20:00] <AlbertA> kgunn: camako: glDeleteTextures is called from a thread other than the one that created the texture
[20:01] <AlbertA> kgunn: camako: we should just do make current before deleting the texture as that object uniquely owns its gl context
[20:02] <camako> AlbertA: sounds good to me
[20:02] <Saviq> AlbertA, I wasn't sure it was limited to a screenshot case, but does make sense
[20:02] <kgunn> AlbertA: camako ...so, i suppose we'll wanna hot fix mir/trusty as well as devel
[20:04] <camako> AlbertA: we shld be careful that his doesn't get called too often... Makecurrent is expensive...
[20:04] <AlbertA> kgunn: so mir 18 has been promoted already?
[20:04] <kgunn> AlbertA: nope...
[20:04] <AlbertA> camako: we are already calling make current all the time :)
[20:04] <camako> AlbertA: Calling thread doesn't have a way of notifying the rendering thread, so it can call this?
[20:05] <AlbertA> camako: it's in the destructor though so it will be whatever that thread is
[20:05] <kgunn> in fact i was just wondering if i should grab the 018 tag version of devel...or go for the top of the tree ?
[20:05] <AlbertA> kgunn: I wondered about tagging minor version in devel
[20:06] <AlbertA> kgunn: then grabbin that...but don't kow if duflu would agree
[20:06] <kgunn> _exactly_
[20:06] <kgunn> i suppose 0.1.8 tag is safer...cause i know he tested it
[20:06] <AlbertA> camako: I suppose though we could shift the texture deletion to the stop call in the functor
[20:07] <AlbertA> camako: but then you have to touch the Pixel buffer interface which assumes no gl
[20:08] <AlbertA> camako: the GLPixelBuffer has no idea from what thread is being called
[20:09] <camako> Probably not a good place then...
[20:09] <AlbertA> camako: it any case, it's the destructor, which will only be called when the server is shutdown - so not often
[20:10] <camako> In my mind, all threads, should have a way of talking to the render thread when they want gl work done...
[20:10] <kgunn> probably more concerning that you say we're calling makecurrent "all the time" already
[20:10] <camako> But ok.. we'll get there I guess
[20:10] <AlbertA> kgunn: make current should only be expensive the first time I thought
[20:11] <AlbertA> kgunn: assuming you don't change thread contexts
[20:12] <kgunn> right, context switch is a buzz kill
[20:12] <AlbertA> camako: but in this case this is special work, it's not exactly rendering or compositing, it's snapshotting a client surface independently of compositing
[20:13] <camako> So glReadPixels?
[20:13] <AlbertA> camako: that's the current implementation yeah
[20:14] <camako> Hmm.. Why is it doing glDeleteTextures then?
[20:14] <AlbertA> camako: it's attaching the client surface, rendering to an fbo then glReadPixels
[20:15] <AlbertA> camako: attaching the client surface to a texture
[20:15] <camako> I see
[20:16] <AlbertA> camako: I don't have the history context on this
[20:17]  * AlbertA adds todo item to provide a platform specific implementation that just mmaps perhaps
[20:17] <camako> Calling makecurrent in this case is ok... But if there are all these threads hitting gl (and hence doing makecurrent) we shld pbably fix it in time
[20:18] <AlbertA> camako: well a gl context is created solely for the snapshoting, so it should be fine
[20:18] <AlbertA> camako: it should not perturb the compositor's gl context
[20:26] <kgunn> camako: alf would be the one to quiz in the snapshot case
[20:27] <camako> ok
[23:04] <AlbertA> kgunn: camako: https://code.launchpad.net/~albaguirre/mir/fix-1256360/+merge/214355
[23:06] <AlbertA> kgunn: camako: I didn't get to repro the issue though - also I would think this would crash all the time...strange that reports don't say that
[23:06] <camako> AlbertA: that's curious
[23:07] <camako> AlbertA: I'd think that too