| Will123456 | zgreg: good thinking - we're the best bug squashing team in town | 00:00 |
|---|---|---|
| Will123456 | zgreg: on my nvidia machine the blur still works when triggering the bug | 00:01 |
| zgreg | it looks very strange, here: http://i.imgur.com/WmzI8.png | 00:01 |
| Will123456 | yeah... that is weird. let me get a screenshot of my own screen | 00:01 |
| zgreg | anyway, can you post a bug report? I | 00:02 |
| zgreg | am the lazy today | 00:02 |
| Will123456 | sure thing. i'll grab the screenshot then write one up and link it here | 00:02 |
| Will123456 | looks like it's already been reported here | 00:07 |
| Will123456 | https://bugs.launchpad.net/unity/+bug/987674 | 00:07 |
| ubot5 | Ubuntu bug 987674 in unity (Ubuntu) "Dash maximise button changed location" [Low,Confirmed] | 00:07 |
| Will123456 | adding your screenshot would help | 00:07 |
| zgreg | yeah, I'll do that | 00:08 |
| Will123456 | whoops, looks like i had also reported this then forgot i had done so :P | 00:11 |
| Will123456 | https://bugs.launchpad.net/unity/+bug/985083 | 00:11 |
| ubot5 | Ubuntu bug 985083 in unity "maximise dash windows control jumps out of place" [Undecided,Confirmed] | 00:11 |
| Will123456 | i guess it's a duplicate | 00:11 |
| Will123456 | zgreg: i think we've got that one wrapped up | 00:13 |
| Will123456 | high five etc. | 00:13 |
| zgreg | hehe | 00:13 |
| Will123456 | so how does the non-GLSL codepath in Nux do dash blurring? | 00:13 |
| zgreg | it's a bit different because it's doing the blur only at 1/4 the background's resolution | 00:14 |
| Will123456 | ah right | 00:14 |
| zgreg | there might be some more differences, not sure | 00:15 |
| zgreg | the non-GLSL codepath in nux is a bit crap anyway | 00:15 |
| Will123456 | see i was wondering about that. i have a laptop that is fast enough to do pretty 3D stuff but chokes slightly on the blur, so I was wondering if it did an obvious optimisation like that... | 00:15 |
| zgreg | well, the blur definitely can be improved | 00:15 |
| zgreg | it's a rather straight-forward gaussian blur implementation and doesn't take advantage of linear sampling | 00:16 |
| zgreg | with linear sampling the number of texture reads can be reduced | 00:16 |
| Will123456 | yeah, i've been doing shaders a lot recently and i've read about things like that | 00:16 |
| Will123456 | i looked in the unity source code and i couldn't find any obvious glsl code though. i guess i wasn't looking hard enough | 00:17 |
| zgreg | the technique is described here: http://rastergrid.com/blog/2010/09/efficient-gaussian-blur-with-linear-sampling/ | 00:17 |
| zgreg | it's all in libnux, a separate library | 00:17 |
| zgreg | nux is horribly inefficient overall, from what I can see | 00:17 |
| zgreg | it does a lot of redundant opengl calls, and doesn't batch anything | 00:17 |
| zgreg | IIRC the non-GLSL codepath does ~30 opengl calls to draw a single textured quad :D | 00:20 |
| zgreg | and then again for the next quad, and again, and again | 00:20 |
| zgreg | the GLSL codepath is not quite as bad, but there's still a lot of room for improvement | 00:21 |
| Will123456 | zgreg: thanks for the link! | 00:21 |
| Will123456 | it's a shame that it's inefficient. that's sort of the last thing you want for a DE :P | 00:22 |
| Will123456 | or shell or whatever :P | 00:22 |
| zgreg | yes, I agree | 00:22 |
| Will123456 | in the glsl blurring I have in the game I'm working on, I do a horizontal blur and then a vertical one | 00:23 |
| zgreg | basically nux sets ALL state that is required for drawing the primitive every time | 00:23 |
| zgreg | it does a little bit of caching for texture state but that's it | 00:23 |
| === dragonfyre13 is now known as dragonfyre_away | ||
| Will123456 | zgreg: i suppose that makes it easier to write nux-interfacing code...? i'm forever tripping up on openGL state leakage | 00:24 |
| zgreg | it doesn't cache any of the global state, and doesn't use a separate opengl context (I think that might be the major problem= | 00:24 |
| Will123456 | is that for things like the lenses? i'm totally unfamiliar with the codebase | 00:24 |
| zgreg | Will123456: yes, maybe that makes it easier, but of course less efficient | 00:25 |
| zgreg | and it really wouldn't be hard to use "nux sections", i.e. calls to save/restore opengl state only when needed | 00:26 |
| Will123456 | yeah. in my head i'm imagining a layer you could put under nux that intercepts all openGL state changes and only sends them on if they are actually different than the previous state. maybe that's easier thought about than done, though :P | 00:26 |
| zgreg | well the problem here is that nux typically reuses compiz' opengl context (as far as I know) | 00:27 |
| zgreg | and that context might be in some strange state, so nux sets all state again, for every primitive drawn | 00:27 |
| Will123456 | ah right, that makes sense! so you think using a different context would make things a lot more efficient? | 00:28 |
| Will123456 | what would be required to get that actually done? | 00:28 |
| zgreg | yes and no, switching opengl contexts is expensive | 00:29 |
| zgreg | but it would be worth a try | 00:29 |
| zgreg | the alternative is to annotate code that calls into nux to save/restore state so it won't be needed to set state again for every primitive | 00:29 |
| zgreg | that would allow efficient state caching | 00:30 |
| Will123456 | yeah... from my ample experience of doing openGL badly, i can appreciate why setting all the state every time would be an attractive proposition | 00:31 |
| Will123456 | if only to save headaches | 00:31 |
| zgreg | it would be interesting to do some batching, too | 00:32 |
| zgreg | nux already contains some functions to draw multiple textures with one call, but they are almost completely unused | 00:33 |
| Will123456 | zgreg: on what layer would you do this though? i have no idea how the lenses talk to unity/nux for drawing, but in my experience having the logic-dealing code not have to think in terms of batching things is quite nice and lovely | 00:34 |
| zgreg | I'm only familiar with the low-level drawing code in nux | 00:35 |
| zgreg | I'd implement explicit batching | 00:35 |
| zgreg | e.g. draw icon and icon background (for the dock) with one call | 00:36 |
| Will123456 | zgreg: so it does icons and their backgrounds separately right now? | 00:38 |
| zgreg | the ideal solution is much more complicated: use a texture atlas and batch as much as possible | 00:38 |
| zgreg | Will123456: yes, IIRC, almost everything is drawn separately at the moment | 00:39 |
| zgreg | there's this one nux function for drawing a single texture quad and it's used all over the place | 00:39 |
| Will123456 | zgreg: i'm mostly familiar with developing in java and using lwjgl/libGDX. libGDX has quite a nice sprite batching class | 00:40 |
| zgreg | grep nux and unity for QRP_1Tex :p | 00:41 |
| Will123456 | you tell it to draw individual textures and it constructs a mesh that incorporates all of the images you specify | 00:41 |
| zgreg | yes, that's the efficient way | 00:41 |
| Will123456 | zgreg: it'd be nice if nux had something like that, instead of the QRP thing! | 00:42 |
| Will123456 | (or rather together with) | 00:42 |
| zgreg | sure, but that's a lot of work | 00:42 |
| zgreg | and really, it's not THAT bad, so I think doing some smaller batches and state caching will be enough | 00:43 |
| zgreg | the super inefficient nux/unity as of now still runs acceptably on crappy atom netbooks, after all :) | 00:44 |
| Will123456 | zgreg: sometimes you can find set ups that it doesn't like... i have an 3 ghz AMD dual core with a respectably middle of the range ATI card (open source drivers) that can't run unity beyond a slow crawl | 00:45 |
| Will123456 | it's more or less fine when you boot up, then running even a few programs slows it right down. it feels more like an awkward combination of things rather than the sort of slowdown you'd expect from just having more stuff going on | 00:46 |
| Will123456 | that's more me just moaning - but i really wish i knew what was causing the problem! | 00:46 |
| Will123456 | zgreg: if you could make one change to unity right now, what would it be? | 00:51 |
| zgreg | small change? | 00:52 |
| Will123456 | anything you want, but yeah, if it was small? | 00:52 |
| Will123456 | i will warn you this is a hypothetical scenario :p | 00:52 |
| Will123456 | i don't have fingers in many pies | 00:52 |
| zgreg | well I'd probably optimize blur and drawing code, since IMO performance is very critical for a desktop shell | 00:53 |
| zgreg | it should perform well even under serious load | 00:53 |
| Will123456 | zgreg: i may be talking nonsense here, but would increasingly hardware accelerated things like web browsing make inefficient nux code more evident? | 00:54 |
| zgreg | not sure, really... | 00:56 |
| Will123456 | zgreg: are you hacking on nux at all are you just an observer? | 00:57 |
| zgreg | well I recently did a little hacking on it and fixed a regression | 00:57 |
| zgreg | but nothing serious | 00:57 |
| Will123456 | hey, that's more than me :) | 00:58 |
| zgreg | nux had this bug with messed up texture coordinates that lead to some rendering artefacts, and this was driving me mad | 00:58 |
| zgreg | https://bugs.launchpad.net/nux/+bug/927441 | 00:59 |
| ubot5 | Ubuntu bug 927441 in unity (Ubuntu Precise) "Far left character in panel (and launcher popups) distorted" [High,Fix released] | 00:59 |
| zgreg | this one | 00:59 |
| Will123456 | zgreg: nice one! | 01:00 |
| Will123456 | funnily enough i never noticed that bug on my machine. i have noticed the nvidia proprietary driver 'fixing' my mistakes though, so maybe that's got something to do with it | 01:01 |
| Will123456 | i'm looking for a nice intel integrated laptop for that reason | 01:01 |
| Will123456 | (mistakes in my shader code and so on, that is - not in nux :P) | 01:02 |
| zgreg | the bug wasn't apparent in all configurations | 01:02 |
| zgreg | the problem was that nux tried to be extra clever and adjusted texture coordinates to make sure textures are sampled in the midpoint of texels | 01:02 |
| zgreg | but, this extra cleverness was wrong and in fact moved the coordinate to the boundary between two texels | 01:03 |
| zgreg | and, depending on floating poing precision, the phase of moon, etc. you either got the issue or not | 01:03 |
| Will123456 | ah right, yeah... that sounds awkward | 01:04 |
| zgreg | turning on linear sampling instantly made the problem apparent, though | 01:05 |
| will | zgreg: sorry about that. i wrote a shader that hardlocked my PC | 01:08 |
| === will is now known as Guest80344 | ||
| === Guest80344 is now known as Will123456 | ||
| Will123456 | that's probably why i shouldn't be allowed to hack on nux | 01:08 |
| zgreg | ever used opencl/cuda? | 01:10 |
| zgreg | it's pretty easy to crash your machine with gpgpu programs | 01:10 |
| zgreg | GPUs aren't capable of preemptive multitasking, so if a shader program locks up, the UI locks up | 01:11 |
| zgreg | and with opencl it's also pretty easy to corrupt GPU memory | 01:11 |
| zgreg | it's definitely a lot of fun :D | 01:12 |
| Will123456 | zgreg: yeah, i have - but only a little bit and it was before I really 'got' doing things in the GPU-way | 01:12 |
| Daekdroom | Isn't that going to generate a huge amount of UI issues once gpgpu becomes popular? | 01:12 |
| Daekdroom | Or are drivers able to prevent them? | 01:12 |
| zgreg | Daekdroom: well, drivers usually reset the GPU after a few seconds of lockup | 01:12 |
| Will123456 | Daekdroom: the nvidia proprietary drivers didn't prevent me crashing my machine just now... :( | 01:13 |
| zgreg | sometimes that won't work well, though | 01:13 |
| Will123456 | as far as i'm concerned if a shader takes more than a few seconds to compute then the drivers should just halt everything and try and return to normalcy, but i realise it's probably 1000x times more complicated than that | 01:14 |
| zgreg | no idea (only driver programms know, probably), but I think the problem is determing the last valid state and returning to that | 01:16 |
| zgreg | *programmers | 01:16 |
| Will123456 | in an alternate universe there is a linux library that all applications can hook into and hand vital data and instructions to incase something terrible happens and the lastwillandtestamentlib sorts everything out for them | 01:18 |
| Will123456 | so if your program locks up, compiz greys the window out then pops up a little box saying "saving all your hard precious work" :P | 01:19 |
| jkd | hi. i'm trying to work out how to add a new option to the launcher. I added it to LauncherOptions.h, and to unityshell.xml.in | 01:29 |
| jkd | and LauncherOptions.cpp as well. the option shows up in ccsm now, but changing the value with the dropdown does not seem to change options()->location (in Launcher.cpp) | 01:30 |
| jkd | does anyone know how to hook up the option to the member variable in unity::launcher::Options? | 01:31 |
| jkd | build/generated seems to have auto-generated stuff pertaining to the options, but i haven't quite been able to figure it all out yet | 01:31 |
| === Guest77193 is now known as yofel | ||
| === yofel is now known as Guest53016 | ||
| === Guest53016 is now known as yofel_ | ||
| zyga | hi, I may have spotted a bug in unity 2 with radiance theme | 09:33 |
| zyga | it seems that all the text in the panel is corrupted, as if it had a shadow that's xored with the background | 09:34 |
| zyga | the effect is not random, if I press a menu entry to open it the style changes and the 'shadow' is no longer there | 09:34 |
| zyga | is this a known issue? can anyone reproduce this? | 09:34 |
| zyga | (it could be radiance bug) | 09:35 |
| zyga | (i meant unity 2d, not unity 2) | 09:36 |
| rye_ | zyga: something that looks like something described in bug #723167 ? | 09:40 |
| ubot5 | Launchpad bug 723167 in unity (Ubuntu) "Panel does not use standard GTK/Pango font rendering/antialiasing, causing fuzzy fonts" [Medium,Confirmed] https://launchpad.net/bugs/723167 | 09:40 |
| rye_ | zyga: that's where my bug report was duplicated into, but I don't see how it works properly with Ambiance and breaks with Radiance | 09:41 |
| === rye_ is now known as rye | ||
| zyga | rye: no | 09:44 |
| zyga | rye: pitti's screenshot looks right by my standards | 09:45 |
| zyga | rye: what I'm observing just looks wrong | 09:45 |
| zyga | rye: I suppose it deserves a screenshot to asses further | 09:45 |
| Donut | can anybody tell me how I do configure the application switcher so that it switches between ALL applications/windows and not only the ones on my current workspace? | 09:45 |
| Donut | It worked just fine in 11.10. I don't understand the philosophy behind 12.04... | 09:46 |
| rye | Donut: ccsm - Unity - switcher - bias alt_tab to prefer windows on the current viewport | 09:49 |
| Donut | thx | 09:51 |
| jo-erlend | or GEdit: /apps/compiz-1/plugins/unityshell/screen0/options/alt_tab_bias_viewport | 09:51 |
| jo-erlend | sorry | 09:52 |
| jo-erlend | gconf-editor :) | 09:52 |
| Donut | jo-erlend: thx. this should be better because I have an alternate unity installed :-) | 09:52 |
| jo-erlend | think it's the same setting, only different GUIs. | 09:56 |
| rye | hm, unityshell? I am not sure the settings is taken from compiz plugins in 2d, we need unity devs assistant | 09:57 |
| rye | assistance | 09:58 |
| jo-erlend | pardon? | 10:12 |
| jo-erlend | nobody mentioned Unity 2D. It uses DConf. | 10:12 |
| === _salem is now known as salem_ | ||
| === sdague_ is now known as sdague | ||
| === daker__ is now known as daker | ||
| === yofel_ is now known as yofel | ||
| DebolazST | Is it possible to get unity to make the icon used to notify you of new messages blink? | 17:50 |
| mhall119 | DebolazST: the icon in the Launcher or in the notification bubble? | 18:06 |
| mhall119 | or the message indicator? | 18:06 |
| DebolazST | The message indicator. The icon that looks like a paper envelope. | 18:06 |
| mhall119 | it can be made to change color when you have new messages | 18:06 |
| DebolazST | It turns blue when there's a new message available, but this is almost unnoticable. | 18:07 |
| DebolazST | People don't see colors, they see change. | 18:07 |
| mhall119 | I think the idea was not to annoy the user over having new messages | 18:07 |
| DebolazST | I find it annoying to miss messages for so long that the person I was talking to has logged off. | 18:08 |
| mhall119 | DebolazST: if you want to make a design proposal, read through http://unity.ubuntu.com/getinvolved/design/ to get to know the process, then send your proposal to unity-design@lists.launchpad.net | 18:08 |
| DebolazST | It would be nice to have another message indicator that could be enabled that would behave like that. | 18:09 |
| mhall119 | You can make one if you wanted | 18:09 |
| mhall119 | DebolazST: http://unity.ubuntu.com/getinvolved/development/common-components/#message-menu has the message menu code, you can fork that and make your changes to it, that would probably be easiest | 18:10 |
| mhall119 | or see http://developer.ubuntu.com/resources/technologies/application-indicators/ for writing a new indicator from scratch | 18:10 |
| DebolazST | Hmm, it would probably be easiest to change the existing message indicator. | 18:11 |
| mhall119 | yeah | 18:11 |
| mhall119 | then you can submit a code patch with your design proposal | 18:11 |
| * DebolazST makes a note of all this information and emails it to himself. | 18:13 | |
| DebolazST | I always found the message indicator hard to notice. I actually have to physically look up at it to see if there's a message available, which isn't something I naturally do since Unity is designed so that everything I actively do is placed on the other side of the screen. | 18:16 |
| DebolazST | And that isn't a bad thing by itself, I find the launcher quite pleasant to work with and I love its current position. It just makes it hard to notice incoming messages. | 18:18 |
| bschaefer | thomi, hey | 18:20 |
| thomi | yo | 18:22 |
| thomi | 'sup? | 18:23 |
| thomi | we're missing you in Oakland. | 18:23 |
| bschaefer | nothing much, trying to figure out this anthy problem haha | 18:23 |
| bschaefer | o how nice, well it smy fault haha, forgot to apply for sponsorship :P | 18:24 |
| bschaefer | its* | 18:24 |
| bschaefer | how was your flight? | 18:24 |
| DebolazST | Hmmm, I know it's the attention_cb function in indicator-messages that gets called when a notification pops up, but I'm not entirely sure what would be the best approach to making it blink. | 20:37 |
| DebolazST | Should I use a timer of some sort, or can the svg image used itself be animated? | 20:38 |
| DebolazST | I guess another way to ask that question is: Does Unity support SVG animations? | 20:40 |
| * DebolazST decides to go with the timer approach. | 20:59 | |
| === salem_ is now known as _salem | ||
| DebolazST | Hrmmm... I made some changes to indicator-messages, now its menu is completely empty. | 21:58 |
| DebolazST | Do I need to do anything magical to install it properly on the system? | 21:59 |
| DebolazST | Other than configure --prefix=/usr ? | 22:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
