| === 5EXABD84D is now known as infinity | ||
| === mibofra is now known as Guest38719 | ||
| === chihchun_afk is now known as chihchun | ||
| === davmor2_hols is now known as davmor2 | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| alan_g | alf_: anpok got time today for a little USC MP? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary/+merge/261181 | 08:44 |
|---|---|---|
| anpok | ok | 08:55 |
| duflu | alan_g: Let me know if you ever find a vectorized version? (just a list of vertices is enough) I like the idea of infinite scalability and 3D effects using the logo in future projects :) | 09:20 |
| duflu | Although it has rotational symmetry so should not be too hard... | 09:20 |
| alan_g | duflu: sure. Maybe someone in design has something more tractable than a png? | 09:21 |
| duflu | alan_g: Dunno. Although I suspect the basic list of coordinates required and then repeated 3/6 times would be hilariously simple | 09:22 |
| alan_g | alf_: do you know a way to get a premultiplied image out of any tool? I really don't want to write a script to edit the header. | 09:24 |
| duflu | alan_g: Frankly that's the best option to edit in situ. Because the requirement for pre-multiplication is in the code using it and not the image. If someone were to extract the image header and want to edit it, they would not want it pre-multiplied | 09:28 |
| alf_ | alan_g: I would say don't care about this for now, the sizes are small. I am more concerned about having both .h and .png | 09:29 |
| duflu | Even better if we generate the header from png at build time, which I'd recommend | 09:30 |
| alf_ | duflu: alan_g: Ideally we would produce the .h from .png and change to pre-multiplied alpha there | 09:30 |
| alan_g | Creating the header during the build would introduce a dependency on a tool that does that. | 09:30 |
| duflu | alf_: Maybe, probably not. If you're using a generic bin2c tool then it should not interpret the bytes it's converting | 09:31 |
| alan_g | (And I don't know one that does pre-multiplication | 09:31 |
| duflu | alan_g: I've done it many times. Write a bin2c.c tool and generate it at build time too :) | 09:31 |
| alf_ | duflu: we need to use a tool that dumps the pixel data, so it does know about the pixel format | 09:32 |
| alf_ | alan_g: I am fine on USC build depending on such a tool | 09:32 |
| duflu | alf_: "need" is over-used there :) | 09:33 |
| duflu | Just generate your tools at build time. It's a simple matter of *make* | 09:33 |
| alf_ | alan_g: (and I am fine not doing premultiplication for now) | 09:33 |
| duflu | It's not a performance issue. Running through the image once even on a slow device is quite fast enough | 09:34 |
| alan_g | How about I delete the .png and if anyone wants to generate the headers they can MP that? | 09:35 |
| duflu | alan_g: Reproducability says probably keep it | 09:35 |
| alf_ | alan_g: In that case don't delete it, I will try to propose an MP with the build time generation later today or tomorrow | 09:36 |
| alan_g | alf_: works for me. | 09:38 |
| alan_g | Guys, any preferences for which client API? Two options here: http://paste.ubuntu.com/11645578/ | 10:00 |
| duflu | alan_g: The second one will eventually be required (for type morphing) so probably better | 10:08 |
| alan_g | duflu: we can do type morphing with either | 10:09 |
| duflu | Well the second one makes more sense to me. You shouldn't need the connection object to morph | 10:09 |
| alan_g | The fist one is one call fewer and makes the existing mir_connection_create_spec_for_changes() more reasonable. | 10:11 |
| alan_g | *first | 10:11 |
| alan_g | But I too lean towards the second | 10:11 |
| duflu | alan_g: On that note, why is connection here? mir_connection_create_spec_for_changes(MirConnection* connection); | 10:12 |
| alan_g | I've a vague recollection it was for consistency with code we've now deleted. | 10:15 |
| alan_g | But I guess we don't need it for the new API | 10:15 |
| alan_g | Hmm. mir_surface_create() used the connection supplied to mir_connection_create_spec_for_XXX. Shouldn't the connection just be supplied to directly? | 11:33 |
| === chihchun is now known as chihchun_afk | ||
| === Guest38719 is now known as mibofra | ||
| === tvoss is now known as tvoss|dinner | ||
| === tvoss|dinner is now known as tvoss | ||
| === alan_g is now known as alan_g|EOD | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| SturmFlut | tvoss: Ping | 20:20 |
| tvoss | SturmFlut, pong | 20:20 |
| robert_ancell | RAOF, ping | 21:09 |
| kgunn | robert_ancell: is it a holiday over there...wonder if he's off | 22:54 |
| robert_ancell | kgunn, ah, is that it | 22:54 |
| RAOF | robert_ancell: Pong | 22:54 |
| RAOF | kgunn: No, that was yesterday :) | 22:54 |
| kgunn | Queen's birthday :) | 22:54 |
| robert_ancell | RAOF, had a question about X drivers and Mir - why do the drivers need to know they're running inside Xmir? | 23:05 |
| RAOF | robert_ancell: For new glamor-based XMir they don't, because there are no X drivers. | 23:05 |
| robert_ancell | RAOF, ah, so we can drop all those patches? | 23:05 |
| RAOF | Correct. | 23:06 |
| RAOF | Although this is a bit of a bone of contention. | 23:06 |
| robert_ancell | RAOF, oh, why? | 23:06 |
| RAOF | My understanding is that nvidia would very much like to have the same sort of DDX interface that the Xorg binary provides. | 23:06 |
| RAOF | So that they can provide their own GLX, and expose all the funky features that their hardware supports. | 23:07 |
| robert_ancell | RAOF, right, but there's always the option of other driver interfaces to Mir like Android | 23:07 |
| robert_ancell | RAOF, and I should be pushing these all into Debian git? | 23:07 |
| RAOF | If you've got access, please. | 23:08 |
| robert_ancell | RAOF, I'm not sure - I guess I should just try and push | 23:08 |
| RAOF | Oh, that reminds me... | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!