| smspillaz | duflu: hollyyyy ... did you see the new nvidia driver release ? | 02:17 |
|---|---|---|
| smspillaz | Improved performance of OpenGL framebuffer object binds with Xinerama enabled by 2000-3000% when the application's windows do not span screen boundaries. | 02:18 |
| smspillaz | lol | 02:18 |
| duflu | Hah | 02:19 |
| duflu | Nice | 02:19 |
| smspillaz | duflu: buffer age support too! | 02:19 |
| * smspillaz cracks open his branch to try it out to see how much faster it is | 02:19 | |
| smspillaz | duflu: buffer_age means that we can finally use glXSwapBuffers without redrawing the whole backbuffer on every frame | 02:22 |
| duflu | That's handy, but not if only 1 or 2 drivers do it | 02:22 |
| duflu | smspillaz^ | 02:22 |
| smspillaz | still great if at least one does! | 02:23 |
| smspillaz | the free drivers will support it in the next kernel release from what I've heard | 02:23 |
| duflu | smspillaz: Mesa claimed to implement GLX_OML_swap_method but it never really worked. So I'm not holding my breath | 02:24 |
| smspillaz | duflu: buffer age is different | 02:24 |
| smspillaz | its really easy to implement driver side | 02:24 |
| duflu | My point still holds. I'll believe it when it's released and working | 02:24 |
| smspillaz | :) | 02:24 |
| * smspillaz adds xorg-edges | 02:25 | |
| smspillaz | *xorg-edgers | 02:25 |
| smspillaz | duflu: seems to work OK, though I suspect their implementation is a bit slow atm | 03:42 |
| smspillaz | maybe they do the buffer age tracking server side | 03:42 |
| smspillaz | duflu: nope, scratch that, forgot to enable lazy positioning :) | 03:55 |
| smspillaz | duflu: so awesome, it works great. I'll have something up for you /others to test tomorrowish | 03:55 |
| duflu | smspillaz: Tomorrow is my last day before vacation. No promise of any more large reviews this year :/ | 03:58 |
| smspillaz | duflu: no problem, it needs lots of testing anyways, it can wait | 04:00 |
| smspillaz | duflu: anyways, we no longer need to worry about the performance impact of doing that fbo bind on every frame, at least on nvidia \o/ | 04:01 |
| smspillaz | I think nvidia is going to go from our worst performing driver to our best | 04:01 |
| duflu | smspillaz: Cool. I thought I modified the FBO class to be smart enough to never rebind until absolutely required though | 04:01 |
| duflu | (when it needs a different FBO) | 04:02 |
| smspillaz | duflu: ah, when was that ? | 04:02 |
| duflu | smspillaz: Before GLES landed | 04:02 |
| smspillaz | right | 04:02 |
| smspillaz | duflu: althoguh you still have to switch between fbo and backbuffer to draw a frame | 04:02 |
| duflu | smspillaz: But that is only optimal for that class. If you can make the calling code (opengl plugin) rebind to different FBOs less often then that could still help | 04:03 |
| smspillaz | indeed, although for most frames we only do it once | 04:03 |
| smspillaz | erm, twice | 04:03 |
| smspillaz | once to fbo, once to back | 04:03 |
| smspillaz | glxswapbuffers | 04:03 |
| smspillaz | with buffer_age we don't even have to do that | 04:03 |
| smspillaz | I wrote some code a few days ago to track damage regions across old backbuffers, so gl tells you how old (in frames) your backbuffer is and then you just repair the relevant regions | 04:04 |
| duflu | smspillaz: Also worth checking Nux to see if and where it does its own rebinds. I suspect it does too much but don't really know | 04:04 |
| smspillaz | duflu: it does do way too much :( | 04:04 |
| duflu | smspillaz: Which history says is a significant bottleneck :( | 04:05 |
| duflu | smspillaz: I am curious because Nux+Unity works with all Compiz rendering modes now. If you're already using FBO then Nux should rebind less | 04:05 |
| smspillaz | duflu: the best thing we can do | 04:06 |
| smspillaz | duflu: is to determine when you're using a framebuffer object of the same size | 04:06 |
| smspillaz | and then switch between the color attachments | 04:06 |
| smspillaz | thats basically free | 04:06 |
| smspillaz | it'll require a bit more infrastructure between nux and compiz | 04:07 |
| duflu | smspillaz: Nux seems flexible enough that it *should* be able to work without FBOs. I don't understand why it needs them at all. Just give it a backbuffer... | 04:07 |
| smspillaz | duflu: you need fbos to do gaussian blurs | 04:07 |
| duflu | smspillaz: Oh, I forgot | 04:07 |
| smspillaz | well, you can do them without fbos but its much slower :) | 04:07 |
| duflu | smspillaz: I think it should be much faster. The need for FBOs in blurring is to only ensure there is no "drift" like you see with an in-situ blur | 04:09 |
| duflu | But regardless, if Unity turns off active blur, that should in the least prevent Nux using FBOs. People should have the option of making things faster even if it's not the default | 04:10 |
| smspillaz | duflu: also nux uses fbos becauses its convenient really | 04:10 |
| smspillaz | even though it shouldn't | 04:10 |
| smspillaz | duflu: anyways, the thing with gaussian blurs is that you need to do the 2nd pass using the results of the first | 04:12 |
| smspillaz | there might be ways to have pseudo-gaussian blurs which don't use 2 passes, but at the moment we use 2 passes | 04:12 |
| smspillaz | multiple color buffers are the best way to do that - reading off the backbuffer is expensive | 04:12 |
| duflu | smspillaz: Yes true for Gaussian. However there other countless other algorithms that don't require multiple orthogonal passes. | 04:12 |
| smspillaz | indeed | 04:12 |
| smspillaz | gaussian looks the best though | 04:13 |
| smspillaz | anways gottan run | 04:13 |
| duflu | Yeah Gaussian looks best but in a real-time UI, people will never tell the difference | 04:13 |
| duflu | Sorry, I don't mean to be one who abuses the term "real-time". I know Linux is not a real-time OS | 04:14 |
| didrocks | sil2100: hey! when you get some time, do you mind updating me on the failing tests? | 08:37 |
| sil2100 | didrocks: sure thing! I already have a branch prepared, when I'm done with this one more fix I will give it out for review - we this should fix 2 failing tests at least | 08:55 |
| didrocks | sil2100: sweet! do you think we'll be able to get down to 0 from this list failing? | 08:56 |
| didrocks | sil2100: as it's only a subpart of tests for non regressing other stacks, I would love setting the value to 0 | 08:56 |
| sil2100 | I would hope to get it down to 0, but some test failures are hard to track down, especially when they're hard to reproduce or some singular cases - I tried one of them yesterday and didn't yet find the root cause for the 'accidental' failure ;/ | 08:59 |
| didrocks | sil2100: maybe fghinter can give you access to the machine? as we are not using them, we can keep them in a fail case maybe so that it's easier for you to run them by hand? | 08:59 |
| sil2100 | didrocks: hm, I guess it wouldn't mind to try, I'll ping Francis when he's online | 09:05 |
| niktto | hi all! I have one quick question about AppIndicator3 in python. I'm using it as an alternative to GtkStatusIcon and I'm connecting same GtkMenu to it but it seems that I can't catch 'button-press-event' on GtkMenuItem | 10:05 |
| niktto | is there any road around this without using 'activate' signal? | 10:06 |
| smspillaz | duflu: hey, see my comment on the MRQ - I think the checks for nBounding < 1 and nInput < 1 are wrong and the source of the problem | 11:04 |
| duflu | smspillaz: Ah yes, good point. But we still want to support !XShape | 11:05 |
| smspillaz | duflu: indeed, see my comment for an idea on how to do that | 11:05 |
| duflu | So feel free to propose something that solves it | 11:05 |
| duflu | Night | 11:05 |
| smspillaz | duflu: are you working tomorrow ? | 11:06 |
| duflu | Yep | 11:06 |
| smspillaz | duflu: ok, well, I guess you can probably handle it | 11:06 |
| === _salem is now known as salem_ | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|lunch | ||
| didrocks | mterry: hey, thanks on the testapp MP! Feel free to get it merged, but I think we shouldn't automate it for daily process until we settle down on the name :) | 14:36 |
| mterry | didrocks, yeah | 14:36 |
| didrocks | mterry: something else, I think you saw that libunity-misc is not merging :/ | 14:36 |
| * didrocks keeps seeing autolanding branch being stalled | 14:36 | |
| mterry | didrocks, oh? wait I thought it did | 14:36 |
| didrocks | https://code.launchpad.net/~mterry/libunity-misc/modernize-build/+merge/139499 | 14:36 |
| didrocks | still approved | 14:37 |
| didrocks | fginther: ^ | 14:37 |
| didrocks | fginther: do you have anything to spot those branches? I keep having 3/4 a days in that stalled situation | 14:37 |
| mterry | didrocks, ah right. But not rejected due to jenkins. Just no jenkins around | 14:37 |
| didrocks | not really efficient to have to ping you or mmrazik every time | 14:37 |
| didrocks | mterry: ah, something else (and sorry to add more to your plate), but there will maybe be some SRU on webapps for youtube which changed its layout, so the script broke | 14:38 |
| didrocks | mterry: robru will do the packaging, but he will need a sponsor next week I guess | 14:39 |
| mterry | didrocks, OK | 14:39 |
| didrocks | so if you can have a look at it when it will be time : | 14:39 |
| fginther | didrocks, yes, we have job that checks for these. It's probably emailing marting, but not me... | 14:39 |
| fginther | s/marting/maring/ | 14:39 |
| fginther | s/maring/martin/ | 14:39 |
| didrocks | thanks mterry ;) FYI, I don't really know how the source packages are created (there is one source package for each script, but the real source is webapps-applications) | 14:39 |
| mterry | didrocks, yeah, they generate them somehow. also not sure how | 14:40 |
| didrocks | mterry: so for this security fix, mdeslaur and I just apt-get source and distro-patch until ken is back and we know how it works with their pkgme | 14:40 |
| didrocks | (the one we uploaded less than an hour ago) | 14:40 |
| didrocks | I guess you will have to do the same for the youtube one | 14:40 |
| didrocks | fginther: it needs patching then! :) | 14:40 |
| fginther | didrocks, mterry. sorry about that. It should be building shortly | 14:43 |
| didrocks | fginther: no worry, thanks! :) | 14:43 |
| didrocks | and one more on the autolanding list (even if the unity stack is not scheduled) | 14:43 |
| mterry | didrocks, what's the blocker for the unity stack? autopilot still? | 14:44 |
| mterry | (in terms of turning on autopublishing) | 14:44 |
| didrocks | mterry: yeah, we just got the first reliable results yesterday | 14:44 |
| didrocks | mterry: so, trying that + adding the dependencies between stacks (more on that in a publishing doc) once sil2100 will have few tests ironed out | 14:45 |
| didrocks | we'll probably do "one blank shot" tomorrow (without really releasing) with jibel | 14:45 |
| didrocks | but I don't feel confortable enabling that just before going on vacations :) | 14:45 |
| didrocks | mterry: I think I'll disable all the jobs btw. I don't think that in what is bootstrapped and running already, we'll have emergency fix | 14:46 |
| sil2100 | didrocks: yes, and I also probably found a bug in appmenu in the meantime as well | 14:46 |
| didrocks | sil2100: \o/ | 14:46 |
| didrocks | larsu: ^ | 14:46 |
| sil2100 | Trevinho is helping me out here as well | 14:46 |
| didrocks | oh sweet! | 14:46 |
| fginther | mhr3, can you review https://code.launchpad.net/~fginther/dee/add-code-coverage/+merge/139586 or suggest someone? | 14:47 |
| larsu | didrocks, what do you mean? The appmenu bug? | 14:47 |
| didrocks | mterry: not sure you were able to talk to cyphermox yesterday, I didn't get any feedback, did you have a chance to work with him on the failing tests in a chroot? | 14:47 |
| didrocks | larsu: not sure it's the same than Trevinho and sil2100 are looking at | 14:48 |
| cyphermox | didrocks: I was out cold all day yesterday | 14:48 |
| didrocks | so maybe better that the 3 of you sync! | 14:48 |
| cyphermox | I poked mterry this morning | 14:48 |
| mterry | didrocks, huh. I can't mark the testapp branch approved. Can you do that? | 14:48 |
| didrocks | cyphermox: yeah, hello btw! do you feel better? | 14:48 |
| cyphermox | didrocks: a little, yeah | 14:48 |
| didrocks | mterry: do you want that power? | 14:48 |
| didrocks | cyphermox: thé + miel? :) | 14:48 |
| mterry | didrocks, sure (muhahaha! more power!) | 14:49 |
| cyphermox | at least now I can actually stick to one physical location at home... ykwim | 14:49 |
| didrocks | ykwim? | 14:49 |
| didrocks | you know what I mean | 14:49 |
| didrocks | I guess :) | 14:49 |
| cyphermox | ;) | 14:49 |
| didrocks | cyphermox: take it easy! :) | 14:49 |
| cyphermox | meh, things still need to get done, and it's been taking way too long already | 14:50 |
| didrocks | mterry: waow! you are an autopilot hacker now, impressive! :p | 14:50 |
| didrocks | fginther: mterry: libunity-misc merged now and adding to the bootstrapped list! awesome :) | 14:51 |
| mhr3 | fginther, configure.ac:146: cannot open `build/autotools/gcov.m4': No such file or directory | 14:55 |
| mhr3 | fginther, looks like it doesn't support non-srcdir build | 14:55 |
| === james is now known as Guest16278 | ||
| fginther | mhr3, thanks I'll fixt that | 14:56 |
| === dandrader|lunch is now known as dandrader | ||
| fginther | mhr3, how are you doing the non-srcdir build? | 15:21 |
| mhr3 | fginther, mkdir builddir; cd builddir; ../autogen.sh; make | 15:24 |
| fginther | mhr3, thanks | 15:24 |
| didrocks | larsu: sil2100: sweet a fix and perf improvments! | 16:00 |
| larsu | didrocks, the performance increase was rather tongue-in-cheek ... it's only 4 empty indicators not being transferred over the bus | 16:01 |
| sil2100 | :) | 16:01 |
| larsu | but otherwise: yeah! I love how easy this was to fix | 16:01 |
| didrocks | larsu: ah ok, I thought it was for all exported menus :) | 16:01 |
| sil2100 | I'm testing larsu's solution now | 16:01 |
| larsu | didrocks, yes, all exported menus (that are GMenuModels) | 16:01 |
| larsu | didrocks, 4 is the number for charmap, it's really the amount of toplevel menu items | 16:01 |
| larsu | but still, since the indicators are empty, there's not much data ... | 16:02 |
| didrocks | ah ok, only toplevel menu indicators ;) | 16:02 |
| didrocks | yep | 16:02 |
| larsu | yeah but it's more Right now :) | 16:03 |
| sil2100 | larsu: tested, works! Can I approve globally, or do you want someone else to also review it before that? | 16:14 |
| larsu | sil2100, I want tedg to have a look as well, it's his code | 16:15 |
| larsu | sil2100, thanks for testing! | 16:15 |
| sil2100 | Would be awesome to have it merged in, I won't have to push the autopilot test-hack otherwise ;) | 16:16 |
| Zhenech | ?window 36 | 16:43 |
| tedg | larsu, Any clue on why GtkMenu inserts separators? | 16:56 |
| tedg | larsu, Seems kinda ridiculous. | 16:57 |
| larsu | tedg, that's the only way to do separators with GMenuModel (have them between all toplevel sections/items) | 16:58 |
| tedg | larsu, Ha, okay. Feeling sorry for who ever has to write appmenu-gtk for GMenuModel. :-) | 16:59 |
| larsu | otherwise you'd never have any separators | 16:59 |
| larsu | tedg, attente? :) | 16:59 |
| larsu | aww, he's not in here | 16:59 |
| tedg | Ah, didn't realize someone was on it. | 16:59 |
| tedg | It's going to be super painful as GMenuModel is so inflexible. | 17:00 |
| larsu | tedg, I hear he's making good progress, though :) Let's see how it turns out | 17:00 |
| larsu | tedg, thanks for approving | 17:01 |
| larsu | sil2100, should land soonish | 17:01 |
| === salem_ is now known as _salem | ||
| tedg | larsu, No problem, finding it is harder than approving it :-) | 17:01 |
| larsu | tedg, right... | 17:02 |
| * larsu was searching in unity-panel-service at first | 17:02 | |
| tedg | larsu, I'm sure he will, just inferring what the app was trying to do is going to be tricky. A lot of fakery. Plus you have to deal with lots of things changing that GMenuModel doesn't allow. | 17:02 |
| larsu | tedg, ya, when I first heard about it I thought it was an impossible job :) | 17:05 |
| === _salem is now known as salem_ | ||
| sil2100 | \o/ | 17:09 |
| sil2100 | Thanks :) | 17:09 |
| * larsu <-- dinner | 17:10 | |
| * tedg is a little concerned that larsu just got turned into dinner, but is hoping for the best. | 17:11 | |
| didrocks | tedg: you know, on those countries… | 17:12 |
| * tedg is a little concerned that didrocks is going to be turned into wine, but is hoping it is a nice wine ;-) | 17:15 | |
| didrocks | tedg: who will be the cheese then? :) | 17:15 |
| tedg | didrocks, seb128! | 17:15 |
| seb128 | tedg, heh, are you saying that I smell? | 17:16 |
| didrocks | seb128: I would find that offensive as well | 17:17 |
| tedg | Heh | 17:17 |
| tedg | I'm saying you age nicely. | 17:17 |
| didrocks | :) | 17:17 |
| seb128 | lol | 17:18 |
| === salem_ is now known as _salem | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === gatox is now known as gatox_lunch | ||
| === gatox_lunch is now known as gatox | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === jussi01 is now known as jussi | ||
| === _thumper_ is now known as thumper | ||
| alo21 | hi all.. | 22:19 |
| alo21 | I read some ideas here: https://wiki.ubuntu.com/Unity/Lenses/Ideas | 22:19 |
| alo21 | and I would to implement one of them. What should I do? | 22:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!