[01:34] duflu: next-day-pong [01:35] haha [01:35] smspillaz: Huh? [01:35] duflu: you pinged me at 5pm yesterday [01:36] smspillaz: Whatever it was I solved it... :/ [01:36] Can't remember [01:36] it was probably about the xsync stuff [01:36] No, don't think so [01:36] smspillaz: Hmm, actually it was about how to reproduce anything slower than 60 FPS, so yeah [01:37] Clearly I need a slower machine with nvidia [01:37] And I did try a dirt-cheap nvidia card too [01:37] duflu: I found the cause [01:38] smspillaz: Yeah looks like it might be related to the LLVMpipe window movement regression I reported too [01:38] I've noted it in bug 1027211 [01:38] Launchpad bug 1027211 in compiz (Ubuntu) "[nvidia] Moving or resizing windows freezes and stutters on nvidia (especially if some other window is redrawing)." [High,In progress] https://launchpad.net/bugs/1027211 [01:38] just working on something that could work now [01:38] But I have been thinking about reverting the damage repair method to be asynchronous again [01:38] smspillaz: I know, just saying it might apply more to the other bug :) [01:38] duflu: well, I think you might be able to get away with removing the XSync in damage repair [01:39] unless there's a race condition I'm not aware of [01:39] smspillaz: The XDamage functions are synchronous too. They should not need another XSync [01:39] duflu: yeah [01:39] duflu: interesting though, removing that got me about 10fps [01:40] duflu: can you double check by breaking in _XReply in XDamageSubtractRegion ? [01:40] smspillaz: But weirdly at the time I swear I got damage artefacts without it and had a good reason.. ? [01:40] duflu: yeah I remember you saying something about that [01:40] smspillaz: Later... I am hours away from being able to look at code. It's the start of my day. Not sure where yours lies [01:40] lays? [01:41] duflu: I have a meeting at 12 today and thats it [01:41] * smspillaz somehow to conned into doing rails [01:41] *somehow got [01:41] smspillaz: rails? [01:41] duflu: ruby on rails [01:41] smspillaz: That's what I thought. OK [01:42] duflu: I'm doing this internship / volunteer position thingy with http://bighelpmob.org/ [01:43] smspillaz: Cos you're generous... and bored :) [01:43] and I get sucked into things [01:43] and seem to be procrastinating getting that startup off the ground [01:43] smspillaz: I was criticising your complaint about holidays and then realized when I was at your age, I worked through the summer holiday too [01:43] workahol ;-) [01:44] 5/7ths pure alcohol [01:44] XD [01:44] Oops, 2/7ths [01:44] I see what you did there [01:45] 5/7ths also works [01:45] as to 7/7ths [01:45] *as does [01:46] duflu: anyways, what I was thinking of for the nvidia slowdown was to restore parts of the code that didn't immediately send geometry updates to the server but make it opt-in instead of opt-out [01:46] smspillaz: If that really is the main problem then we should stop. Sit on your hands. Sending geometry updates to the server is something we should do. [01:47] duflu: ah, sorry, delay sending those updates [01:47] Hence I was going to analyse the damage repair and again glib source priorities [01:47] duflu: it should be possible to do it right - this is what mutter is doing AFAICT [01:47] smspillaz: Yes but we have a feedback problem, probably. --> https://bugs.launchpad.net/compiz/+bug/1025586 [01:47] Launchpad bug 1025586 in compiz (Ubuntu) "[0.9.8 r3110 regression] [LLVMpipe] Dragging windows around is much slower with compiz 0.9.8 than 0.9.7 (using LLVMpipe)" [High,Triaged] [01:48] duflu: not really, its literally just that the nvidia driver can't handle ConfigureWindow requests at the same time as doing opengl [01:48] nfi why [01:49] (erm, can't handle a continuous stream of them) [01:49] smspillaz: Yeah that's a big issue, but maybe it's hard to distinguish multiple problems while the above bug exists [01:51] duflu: okay, sorry I stand corrected, mutter does do that [01:51] must be something else we do around that area [01:51] * duflu afk [02:05] bschaefer, I updated https://code.launchpad.net/~fginther/nux/add-code-coverage/+merge/138007 per your comments [03:31] duflu: ok, I have a workable solution to this problem, will have it up by tomorrow \o/ [03:34] smspillaz: I'm still in analysis and will test your proposals against both bugs [03:34] duflu: the problem is a quasi-feedback-loop [03:35] As always, good software development is 80% of the time thinking and only 20% typing. Anything more than that is dangerous [03:36] duflu: nvidia chokes on XConfigureWindow, as expected, however because it chokes we get more time to send it more XConfigureWindow requests [03:36] which makes it choke even more [03:36] I'm part of the way done with it [03:37] smspillaz: So that sounds like the LLVMpipe bug. Please propose against that [03:37] And maybe nvidia too. [03:38] duflu: nah its just nvidia [03:40] duflu: unless llvmpipe has exactly the same problems [03:40] (eg with moving opengl around) === vibhav is now known as Guest5822 === Guest5822 is now known as vibhav === vibhav is now known as Guest21128 === Guest21128 is now known as vibhav [06:14] Mirv: hey, around? [06:26] Mirv: sorry, was disconnected in case you answered :) [08:36] Mirv: still not around? [08:42] didrocks: what's up? [08:42] hey sil2100 :) I wanted to ask Timo to fix the python-support for https://bugs.launchpad.net/ubuntu/+source/google-mock/+bug/1076891 [08:42] Launchpad bug 1076891 in google-mock (Ubuntu) "[MIR] google-mock" [Undecided,Fix committed] [08:42] so that we can fix google-mock MIR match === chrisccoulson_ is now known as chrisccoulson [09:14] sil2100: did what I say makes sense? if Mirv isn't around, are you taking that one? (should be easy) [09:18] didrocks: I'll check up on that one in a moment then, I *should* be able ;) [09:24] sil2100: excellent! thanks :) [09:43] sil2100, Mirv, didrocks: somebody wants to ask details on https://bugs.launchpad.net/bugs/974242 about how the verification failed for that guy who just changed the verification-done to failed... it will block the SRU if it stays in this state [09:43] Launchpad bug 974242 in compiz (Ubuntu Precise) "Compiz is moving windows against my will" [Medium,Fix committed] [09:44] seb128: I'll let that to mterry to handle it :) [10:11] bschaefer: Are you still here ? [10:12] bschaefer: Just FYI: I commented on the nux-reduce-scopes MP. Everything with it should be okay - I doublechecked it... [10:26] didrocks: just now looking at the google-mock thing - hm, so you want to include python-support in main as well? [10:27] Or is it possible to get rid of that dependency in google-mock? [10:28] sil2100: did you read the comment? :) [10:28] it is about NOT including it in main [10:28] but moving to dh_python [10:29] Ok, so removing python-support ;) [10:29] yep === mmrazik is now known as mmrazik|lunch === _salem is now known as salem_ === dandrader is now known as dandrader|afk === mmrazik|lunch is now known as mmrazik === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|lunch [15:20] Trevinho, ping [15:20] fginther: pong [15:22] Trevinho, the proposed fix for the bamf 'kill No such process' issue is now building under jenkins. The build environment appeared to have been affected by a number of orphaned process on the build machine. After a reboot the builds are working again. [15:22] Trevinho, here's a build log: http://paste.ubuntu.com/1414882/ === dandrader|lunch is now known as dandrader [16:25] Trevinho, can you suggest a reviewer for https://code.launchpad.net/~fginther/bamf/ignore-kill-return/+merge/138316 [16:26] fginther: that script was initially written by tedg, even if I applied few modifications... [16:27] fginther: it looks good here btw [16:27] Yeah, we really should be switching to xorg-gtest when possible though. [16:27] That's the way forward :-) [16:28] sil2100: hey, did you get any time to work on https://bugs.launchpad.net/ubuntu/+source/google-mock/+bug/1076891? [16:28] Launchpad bug 1076891 in google-mock (Ubuntu) "[MIR] google-mock" [Undecided,Fix committed] [16:29] oh you did! [16:29] sil2100: thanks a lot :) [16:29] sil2100: ah, it needs tweaking! :) [16:29] Trevinho, tedg, thanks for looking === salem_ is now known as _salem [16:32] didrocks: probably! :) [16:32] didrocks: comments are welcome! [16:32] sil2100: I commented! [16:32] Since right now I'm molesting ibus ;p [16:33] sil2100: leave ibus alone! :) === _salem is now known as salem_ === Guest26733 is now known as help === help is now known as balloons1 === salem_ is now known as _salem === balloons1 is now known as balloons === _salem is now known as salem_ === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [19:03] bschaefer, can you take approve https://code.launchpad.net/~fginther/nux/add-code-coverage/+merge/138007 if it looks good now? [19:03] fginther, yup! [19:04] fginther, cool, im happy with that change, thank you! [19:07] Trevinho, tedg sorry to nag, but can https://code.launchpad.net/~fginther/bamf/ignore-kill-return/+merge/138316 be approved for merge? [19:10] fginther, Yeah, Trevinho approved it, just forgot to set the overall status. [19:10] I set that now [19:10] Hmm, alesage, do you know if bamf autolands? [19:11] tedg, yes it does [19:11] fginther, Okay, I would have expected a review by Jenkins... [19:11] my work here is finished [19:12] * fginther adds support for bamf ci jobs to his todo list [19:12] Ah, okay. [19:39] was unity2d dropped because no one wanted to port 4.X to 5 and qml2 ? because nokia stoped for qml1.0 support ? [19:40] I want a real reason why as llvm is not all that great. or was it $ on canonical ? [19:41] I am asking this after watching Rick spencers thing on ubuntu on air [19:43] bobweaver, I believe it was dropped because it required a completely duplicate effort to maintain two identical desktops with two codebases [19:44] no sane entity would want to do that [19:44] bregma, so in other words no moe money for qt devs ? [19:44] and no need for 2 things that do one thing [19:44] I don't know why one was chosen over the other, but I understand it was a difficult decision [19:44] well I guess that the next question is just that ^^ [19:45] and most of the Qt devs were rolled into the since Unity project, so it wasn;t a money thing [19:45] why nux c++ stuff because it was house ? [19:45] *single Unity project [19:45] I really have no inside information on what motivated the final decision [19:46] I mean it makes sense but the only fact is that llvm is not working all that well for me [19:46] it's still a work in progress [19:47] I am not trying to fight for 2d here I just want a clear understanding of why I should learn nux and why I should learn welll learn more c++ [19:47] Qt is also C++ [19:48] if unity 3d was used which it is I am sure that there is a smarrter person then me that can tell me why these things are best to learn or why what thye work on is what they love [19:48] bregma, I know that they are libs [19:48] but thanks :) [19:49] Like I could list of the top of my head why I love to use qml right , I am sure that there are people in this channel that can also do that with say compiz nux ect [19:50] * bobweaver is trying to get motivated ;? [19:52] Like Nux will be able to do X in the future that we could not see X doing in the future , kinda [19:56] Nux can do crazy things with shader (GPU) programming that Qt requires direct OpenGL programming on a canvas for [19:56] doing the same in QML requires extending QML using Qt and Open [19:56] OpenGL [19:57] what is wrong with opengl (es) rendering ? [19:57] thanks for this bregma I really like this subject [19:58] so you are talking about libdeclaritive shaders from qt community ? [19:59] I guess what I do not understand about what you said ^^ is the "QML requires extending QML using Qt and Open" what do you mean by "Open" ? [20:00] OpenGL [20:00] TBH I have only been using qml and programming for 1.5 years [20:00] well qml 6 months maybe year [20:01] bobweaver: I think the big difference is that Nux is a toolkit build on OpenGL, where at Qt has to go through abstraction layers before it gets to OpenGL [20:01] which makes Qt portable, but also heavier [20:02] so I guess that I have to figure out why the shader system is different then the one used in Nux to see the great things that it offers [20:02] atp right now I am just learning how to layer things in nux [20:02] I wouldn't expect "great things" in the way of features [20:02] Nux is, after all, a very new toolkit [20:03] but it should be fast and light and work well anywhere OpenGL support exists [20:03] mhall119, something that I always thought about you is that you are easy to talk with about these types of things even if I am new and dont understand some things [20:04] bregma, is also awesome j/s [20:05] so how does compiz and all this play togeather with Opengl [20:05] bobweaver: It's easy for me to talk about things in a non-technical way, when I know so very little about the technical side of it :) [20:05] like can or how are there any limits on compiz and open gl [20:06] If there are * [20:06] Compiz itself is kind of limited by X, and being a window manager for X [20:06] Unity has had to work around some of those problems with things like Bamf [20:06] since X doesn't have any concept of "this window belongs to this application" [20:09] mhall119, I think that I need to go through more of the old code esp the src/pirvate-unity-2d stuff so I can understand more of how the libs where all being drawn together. ATM I have bo clue where I would even start on that with 3d. besides just looking at #import's and then reading there libs [20:09] maybe there is a way to break the chain so to say [20:11] after I learn that maybe I will have a much better understanding of how unity as a whole is geared , and not just reading dash/* ect for unity 3d as I see that it is importing libs I just do not know what some of these libs do Or even how I can use them [20:12] I think that that right there is super impoant if I want to learn how to design anything in unity 3d. But I could be wrong. There is no book called "How to become a unity developer " :) [20:14] or even better "How to become a unity developer for dummies " though them books are junk anyways. maybe there is book for that but it is about gaming platform :) [20:14] of to learn thanks all [20:14] mhr3: bschaefer: ^^ any chance someone from the Unity team could spare an hour and to a hangout/classroom session on this? Seems it would help more than just the TV devs, but also anybody interested in contributing to Unity [20:16] an ubuntuonair.com session with screen sharing would be fantastic [20:20] mhall119, I would be there shit bro I would call into work [20:20] woops sorry about lang [20:21] got excited [20:21] bobweaver :) [20:48] mhall119, sorry, was on lunch [20:49] mhall119, hmm when would this hangout session be? [20:51] bobweaver, and how to become one? Fix bugs :) === salem_ is now known as _salem [21:44] bschaefer: any time, any day [21:46] mhall119, cool, well I could, or I could help find someone else as I don't have a webcam [21:48] bschaefer: we need to get you a webcam [21:51] mhall119, well I could possibly go out and find one out in the world [21:52] there's this little place called "amazon.com" on the interwebs [21:53] o there is...that is right...and they have all my info...interesting... [21:53] * bschaefer goes to browse through the dash [22:00] OMG! product listings that are relevant to your search terms! Oh the Humanity! [22:03] the question is, do we want bschaefer on a webcam or will that frighten too many prospective developers? [22:04] think of the children [22:04] bregma: the internet has seen worse, the entire Canonical Community team was on camera for 24 hours [22:05] explain why my internet was down at the time [22:06] I believe several ISPs and at least 2 foreign governments shut down access because of it === You're now known as ubuntulog [22:08] mhall119, bregma yes, think of them [22:08] are you volunteering bregma haha? [22:09] I don't have a webcam and I'm not going to get one [22:09] * bregma stick out his tongue [22:09] the last thinh I want is for my daughter to start using it while online [22:09] haha [22:10] well that makes sense