| === Logan_ is now known as [Live] | ||
| delinquentme | annyyoonneee have screenshots of the 13 UI? | 01:51 |
|---|---|---|
| === Logan_ is now known as log | ||
| === log is now known as Logan_ | ||
| === Walther_ is now known as Walther | ||
| BluesKaj | Howdy all | 12:07 |
| penguin42 | Hey BK | 12:10 |
| BluesKaj | hi penguin42 | 12:21 |
| BluesKaj | will the alternate install will be available for 13.10 when the release is official ? | 15:21 |
| bekks | There isnt an alternate anymore, isnt it? | 15:21 |
| BluesKaj | not for 13.04 ...there's Lubuntu alternate install for 13.10 , but that's all i can find | 15:29 |
| penguin42 | I just use the server install to do that | 16:17 |
| johnjohn1011 | will i ever be able to get 13.10 to run on my vmware machine? it's been broken for a while. | 17:02 |
| holstein | johnjohn1011: whats the issue? you might just want to wait til its released | 17:03 |
| penguin42 | hmm I should try Mir; is it easy to try KDE on Mir ? | 17:09 |
| holstein | !mir | 17:10 |
| ubottu | Mir is the next-generation display server currently under development by Canonical and Ubuntu. It's slated for inclusion in Ubuntu 14.04. For more information on it, see https://wiki.ubuntu.com/Mir/Spec . For code, see https://launchpad.net/mir | 17:10 |
| penguin42 | Oh I thought someone said it was going to land in 13.10 | 17:10 |
| holstein | penguin42: if you are looking for "easy", dont try MIR yet | 17:11 |
| penguin42 | worth giving a go in a vm? | 17:12 |
| alankila | probably not. phoronix (aka moronix) benchmarked it and found it loses 10 % of framerate at various tasks, and almost everything goes through xmir, so unless you want to help testing it I doubt there's any use benefits | 17:15 |
| penguin42 | is there a native Qt/Mir and would KDE use it? | 17:15 |
| alankila | shuttleman said in a blog post that it works "smoother" but I have no idea what the basis for that claim is. I am willing to believe interesting things happen when xmir doesn't get used anymore. | 17:16 |
| alankila | I believe any direct mir support is still only being written | 17:16 |
| penguin42 | alankila: I can believe there might be something along the lines of the modern desktops do compositing in the window manager anyway so if you just move that to a different layer perhaps it doesn't matter much | 17:17 |
| penguin42 | I guess 10% ain't bad for some code that's that new | 17:17 |
| alankila | well, performance loss is to be expected when you shove more crap into the stack, I guess | 17:17 |
| alankila | now eliminate X and make direct OpenGL rendering calls from client code, I believe that should show a significant performance increase | 17:17 |
| alankila | the only part that can break that is the compositor by wasting time before it gets to displaying the new pixels | 17:18 |
| alankila | but there's no real reason to expect that compositors would do a poor job | 17:18 |
| penguin42 | and not necessarily any worse than the current ones in the window managers | 17:18 |
| alankila | exactly, the work is more or less the same, though less intermediate processes involved | 17:18 |
| alankila | also raspberry pi compositors have shown that if you can use specific compositing hardware, you will gain a lot of performance | 17:19 |
| alankila | this is apparently simple alpha blending 2d hardware. This task is more common in UI-related work than full 3D that isn't required outside a game context, so some ARM hardware has extra support for that kind of use case | 17:20 |
| penguin42 | yeh makes sense; one of the thing I like about KDE is that you can switch it to use Xv compositing | 17:22 |
| alankila | really? Xv is a YCrCb color space thing. I'd guess the RGB to YCrCb conversion would eat any benefit | 17:22 |
| alankila | or maybe it's actually a real YUV. I'm not sure. I remember the hardware provided brightness, contrast and gamma controls though they are basically simple interpolated lookups and some vector-by-matrix multiplication algebra in the end | 17:23 |
| penguin42 | sorry, I meant XRender | 17:23 |
| alankila | hm right. XRender though supports more than most people end up using. I guess above all the OVER blending operator is the only one that matters | 17:24 |
| alankila | I did take a look once and saw that some harware is capable of accelerating some of the XRender operators. Where that doesn't happen, pixman implements software versions of these ops | 17:25 |
| alankila | xrender's and pixman's real problem is that they don't support color spaces. This, for instance, is the reason why a pdf rendering library called poppler doesn't produce high-quality output. Hardware can generally only support linearly coded sRGB and the sRGB-curve coded sRGB, with the sRGB textures/framebuffer extension | 17:26 |
| alankila | supporting general transformations is very challenging, though if you can boil it down to an interpolated 3-component lookup then you are in business with fairly modest complexity cost. | 17:27 |
| penguin42 | why what do you need for pdf? cymk ? | 17:27 |
| alankila | for instance wayland apparently has surface color spaces support, so that is pretty exciting | 17:27 |
| alankila | pdf allows use of any colorspace it knows and icc profiles for the pdf blending ops, which are the same as in pixman | 17:28 |
| alankila | for instance a graphic may come with the ICC profile of the display it was drawn/edited on | 17:28 |
| alankila | together, the component values + the profile encode the physical intensities of the 3 primary color components, or that is what it boils down to when human is the ultimate consumer of the product | 17:29 |
| alankila | I haven't heard of any serious technical talk with mir, if it fixes or has plans for fixing any of the long-standing linux graphics issues, especially when it comes to color management and 16 bit per component surfaecs and stuff like that. | 17:31 |
| alankila | wayland at least has a plan, so it seems to me that wayland is going to provide capabilities similar to window and macintosh | 17:31 |
| alankila | for instance microsoft defined a color space called scRGB(16) that high-end publishing applications can use | 17:31 |
| alankila | anyway, end ramble. I think the Mir is going to be a mistake, more of the crap we already have, unless some really serious people actually think what a display system needs to provide. IMHO the most important job for the display system is to display a color correctly on screen, so that means color management, 48-bits-per-pixel surfaces for image editors, and support for color gamuts past sRGB | 17:33 |
| penguin42 | alankila: I'm not sure yet, and wouldn't really want to say until I see how well it actually works | 17:35 |
| alankila | I would like to be proven wrong, but there's not much visibility to the mir development | 17:36 |
| alankila | you can join #wayland and talk about color management and the people there engage with your arguments and so on, so I suspect that wayland will have a mature color management and what they just shipped in 1.2 sounds like it's the right solution to me | 17:36 |
| alankila | whether mir is just a 90s graphics technology implemented in 10s hardware remains to be seen | 17:37 |
| penguin42 | hmm I was expecting to prove you wrong and point you to Mir's blueprints on lp, but I can't see any | 17:37 |
| alankila | exactly | 17:37 |
| alankila | there's not much visibility to the development, so I can only hope the people involved are serious graphician type minds who know what graphics programs need rather than engineers that just think providing what 1990s already could do is enough | 17:38 |
| alankila | I could download sources and take a look though. Maybe I'd like what I see, maybe I wouldn't. But ... I don't really have the time for that. | 17:38 |
| penguin42 | yeh I'm tempted to, and I wouldn't mind fixing bugs etc if I find them, but I'd have to get sign off from my employer before doing the contributor agreement and that would be hard work | 17:50 |
| === cmagina-away is now known as cmagina | ||
| === cmagina is now known as cmagina-away | ||
| === hggdh_ is now known as hggdh | ||
| jakubo | Hi, does the new grub version mean that i can finally release my fake-raid set up system's grub from its sleep in the precise repository? | 19:31 |
| BluesKaj | booted the default kernel for comparison to the liquorix | 19:36 |
| jakubo | to give an anwer to my own question asked before: yes it works (for me: i.e. nvidia fakeraid)!!! | 20:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!