| RAOF | Ok, that's a bit annoying. gdb now segfaults trying to read debugging symbols from mir_unit_tests | 01:15 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| * RAOF heads due luncheon | 02:33 | |
| kgunn | ok, realized i've never done this...if i run mir_demo_server_basic on vt1 and i want to kill it, how would i do that? | 03:05 |
| kgunn | duflu: RAOF ^ ? | 03:05 |
| duflu | kgunn: Firstly, server_shell is much cooler :) Secondly remember to sudo or else Mir doesn't have input (quit) support - https://bugs.launchpad.net/mir/+bug/1286252 | 03:06 |
| ubot5 | Ubuntu bug 1286252 in Mir "mir_demo_server* successfully start as non-root (without input support), meaning it can't be quit/switched away from" [Medium,Confirmed] | 03:06 |
| duflu | kgunn: Once you have input support it's Ctrl+Alt+Backspace | 03:07 |
| kgunn | duflu: ah, i did sudo.... | 03:08 |
| duflu | That reminds me, I wanted to move some common logic like that into the server library and let shells override it. It's annoying every demo shell should have to re-implement something as basic as quitting | 03:09 |
| duflu | (because mir_demo_server_minimal is unquitable, I think) | 03:09 |
| duflu | Oops. Quit the wrong shell? | 03:14 |
| RAOF | anpok_: Are you planning to try and land https://code.launchpad.net/~andreas-pokorny/mir/add-timer-to-main-loop/+merge/216881 anytime soon, or should I un-depend-upon it in 1Hz-rendering? | 05:03 |
| RAOF | Oooh! Oooh! Oooh! There's a new button on Launchpad reviews, “Show inline comments”! | 06:14 |
| duflu | Wha?! | 06:21 |
| RAOF | There's no ability to comment inline yet, but the first parts of that series are landing. | 06:21 |
| RAOF | Yay! | 06:21 |
| duflu | RAOF: Heh, yeah I was trying to figure out how to make one | 06:22 |
| duflu | What would also be really nice is side-by-side diffs | 06:23 |
| duflu | In my experience they're much better for code review | 06:23 |
| RAOF | Hm. Dumping the diff into meld would be pretty cool, yeah. | 06:31 |
| RAOF | That would probably be pretty easy to do, actually. | 06:35 |
| anpok | RAOF: i thought about doing so now, but havent started workin on that | 06:42 |
| RAOF | anpok: Well, sometime would be nice, as 1Hz-rendering depends on it. | 06:51 |
| duflu | RAOF: (1) Happy weekend. else (2) Please check again: https://code.launchpad.net/~vanvugt/mir/simplify-BufferQueue/+merge/218794 | 07:24 |
| RAOF | duflu: Doing so :) | 07:24 |
| RAOF | duflu: It seems that the uniqueness constraint could be satisfied in a less invasive way. | 07:28 |
| duflu | RAOF: You mean more exhaustive? I'd rather simplify and shrink the code before reconsidering unnecessary micro-optimizations | 07:28 |
| RAOF | I don't suppose you've got a test for this? | 07:31 |
| duflu | RAOF: It can't really be tested. The symptom is memory bloat of a private member... that is never leaked | 07:32 |
| duflu | You can observe and test it externally, obviously | 07:32 |
| duflu | I'll do another alt fix proposal | 07:33 |
| duflu | I've come to not expect anything to land, so I work on many different things at once :) | 07:34 |
| RAOF | You could measure memory use over thousands of compositor_acquire/compositor_release cycles, if nothing else :) | 07:34 |
| duflu | RAOF: fprintf tells me the vector is huge... I don't really need any more info | 07:40 |
| duflu | Hmm, a "smaller" fix actually isn't working | 07:40 |
| RAOF | But you can't run an fprintf test on every commit :) | 07:40 |
| duflu | RAOF: I don't intend to. Very few performance bugs get regression tests in general. Although I did manage with a bunch of SwitchingBundle issues before... | 07:42 |
| duflu | Also memory bloat is an issue most programmers never consider. They think not leaking is enough... but really you need to do real external system testing | 07:42 |
| RAOF | I'm still not sure why this isn't a proper target for an automated test? | 07:44 |
| duflu | RAOF: Hmm, could just set a time limit on the existing test and fail I guess | 07:44 |
| duflu | That would do it, but only on a small subset of system | 07:45 |
| duflu | Heh. I never intended to fix any bugs with this proposal | 07:45 |
| duflu | It just happened | 07:45 |
| RAOF | Parse /proc/self/status, check RSS isn't increasing over thousands of compositor cycles? :) | 07:47 |
| alan_g | Put a "reasonable" limit on the size and assert? Or add a query to report the queue sizes that can be checked in unit test? | 07:50 |
| duflu | alan_g: I think that's a case of testing the known cause, when a fix would eliminate the test. I'm trying for a different test that would remain valid regardless of the implementation | 07:51 |
| alan_g | duflu: I know but lacking a generic option it is better than no test. | 07:52 |
| duflu | alan_g: I might have a generic options. On the other hand, I don't think any or all memory bloat problems have internal testing. It's really an external thing usually | 07:53 |
| RAOF | Parsing /proc/self/smaps would get you a pretty good “am I using more memory by doing this thing over and over” test. | 07:53 |
| RAOF | This sounds like something that might be good for mir_test{,_framework}, actually. | 07:54 |
| alan_g | RAOF: that sort of thing is probably more appropriate in the acceptance/stress/performance tests | 07:54 |
| alan_g | yes | 07:54 |
| RAOF | Anyway, EOW for me! | 08:00 |
| alan_g | dednick: do you approve https://code.launchpad.net/~alan-griffiths/mir/spike-passing-out-client-fds/+merge/218629? | 08:45 |
| alan_g | Or are there still problems using it? | 08:46 |
| dednick | alan_g: got it working with trust sessions after you left last night. just approved | 08:47 |
| alan_g | Great! | 08:47 |
| duflu | alan_g: I'm seeing it too now. If you want to take over this, please do: https://bugs.launchpad.net/mir/+bug/1317801 | 09:37 |
| ubot5 | Ubuntu bug 1317801 in Mir "[regression] [BufferQueue] BufferQueueTest.compositor_never_owns_client_buffers occasionally crashes with: what(): unexpected release: buffer was not given to compositor" [High,In progress] | 09:37 |
| alan_g | duflu: ack - not sure I'll get to it this week though | 09:37 |
| duflu | alan_g: Sure. Just mentioning in case you do. Otherwise my Monday comes sooner | 09:38 |
| alf__ | duflu: I may be able to take it over today, I will reassign is so | 09:39 |
| alf__ | s/is/if/ | 09:40 |
| duflu | alf__: That would be good too | 09:40 |
| duflu | I got way too ambitious in the number of fixes I could get landed | 09:43 |
| duflu | Need to share the love a bit more | 09:43 |
| duflu | On the upside, not making progress gives me a clean slate for the weekend. Till next time... | 10:06 |
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === alan_g is now known as alan_g|lunch | ||
| anpok | AlbertA: any reason why you wrote for-loops instead of auto pos = find(begin(..),end(..),item).. in the buffer queue? | 13:28 |
| anpok | I mean was that based on the profilings? | 13:28 |
| AlbertA | anpok: yeah they did better in profiling and std::find and iterators | 13:31 |
| anpok | ok, i assumed those would be identical for somehing like vector | 13:31 |
| AlbertA | anpok: there's a small overhead when constructing iterators at least on gcc/glibc | 13:31 |
| AlbertA | anpok: so since the number of elements is small - the overhead in comparison is significant | 13:33 |
| === alan_g|lunch is now known as alan_g | ||
| === chihchun_afk is now known as chihchun | ||
| seb128 | hey Mir team | 14:44 |
| seb128 | I've a dell inspiron 11 laptop, which has a touch screen, testing unity8/Mir on trusty ... things run fine but the touch screen doesn't work | 14:44 |
| seb128 | is that a known issue/limitation? | 14:45 |
| racarr__ | Morning | 14:48 |
| seb128 | hey racarr__, how are you? | 14:49 |
| alan_g | seb128: racarr__ probably knows that part of the stack best. | 14:51 |
| racarr__ | seb128: Oh pretty good! You? | 14:54 |
| seb128 | I'm good thanks! | 14:54 |
| racarr__ | re: the touch screen...hmm...no one has one | 14:54 |
| racarr__ | so its hard to say | 14:54 |
| racarr__ | its not exactly expected to ork in that anyone has tried it | 14:54 |
| racarr__ | but I dont know why it wouldn't work... | 14:55 |
| racarr__ | someone has used a laptop touchscreen with success | 14:55 |
| racarr__ | maybe olli | 14:55 |
| racarr__ | so there must just be some sort of quirk or something | 14:56 |
| racarr__ | seb128: If you want to dig deeper MIR_SERVER_LEGACY_INPUT_REPORT=log MIR_SERVER_INPUT_REPORT=log could have something | 14:56 |
| seb128 | k | 14:56 |
| racarr__ | (export them as env variables in the environment unity system compositor is in) | 14:56 |
| seb128 | <bregma>seb128, your hardware may need to be defined as an Android touch device for Mir to recognize it properly | 14:57 |
| seb128 | <bregma>all of mine work out of the box now, but initially I had to create a file somewhere with hexadecimal device IDs in the title, can;t recall the details.... | 14:57 |
| seb128 | <bregma>I'll need to dig that up | 14:57 |
| seb128 | 14:57 | |
| seb128 | is that what I've been told yesterday | 14:57 |
| seb128 | so I figured that you guys might know more about that ;-) | 14:57 |
| racarr__ | seb128: yes there are these ".idc" files | 14:58 |
| racarr__ | I have never touched the code or one though so im not sure... | 14:58 |
| racarr__ | thats a good idea though | 14:58 |
| bregma | yeah, .idc files, that's it | 14:58 |
| racarr__ | some community guy porting a device...that was his f | 14:58 |
| racarr__ | ix | 14:58 |
| racarr__ | when his touchscreen didnt work | 14:59 |
| racarr__ | um I can look in to it after standup. or you can probably find one on your phone | 14:59 |
| seb128 | I'm fine hacking it locally | 14:59 |
| bregma | some touchscreens are not recognized as such because, well, hardware is flaky, so they need an IDC file to force the issue | 14:59 |
| seb128 | but that would be nice if those stuff were working out of the box | 14:59 |
| seb128 | normal users are not going to go figure that out | 14:59 |
| seb128 | well, the touchscreen is working fine under Xorg/unity7 | 15:00 |
| seb128 | so somehow it's recognized correctly | 15:00 |
| seb128 | just not by Mir | 15:00 |
| tedg | Do we get a compose key for free in Mir, or is that something we'll have to do ourselves? | 15:04 |
| racarr__ | I dunno, we might get it for free from XKB | 15:06 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|EOW | ||
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| AlbertA | anpok: so assuming we change to pre-multiplied alpha | 19:23 |
| anpok | AlbertA: where are we using the suspicious masking - or rather | 19:23 |
| anpok | why does the issue not occur on the framebuffer? | 19:23 |
| anpok | is the blending function for a normal display buffer different than for screen casing? | 19:23 |
| anpok | *casting | 19:23 |
| AlbertA | anpok: no it's the same | 19:24 |
| AlbertA | anpok: but assuming we change the blending function - | 19:24 |
| anpok | ah the scanout fixes it.. | 19:24 |
| AlbertA | anpok: there's still the issue that nested servers | 19:24 |
| anpok | hm but over-blending with premultiplied should be associative | 19:25 |
| AlbertA | anpok: would like to specify the final alpha value in the framebuffer | 19:25 |
| anpok | well the initial one has to be zero | 19:25 |
| AlbertA | anpok: for per-pixel alpha transitions between sessions | 19:25 |
| anpok | hm you mean the nested session want to do direct alpha writes? | 19:26 |
| anpok | *wants | 19:26 |
| AlbertA | anpok: well somehow...the main thing is supporting per-pixel alpha transition effects | 19:27 |
| anpok | i thought for our use cases we start with zero and just combine blend one over the other.. | 19:27 |
| anpok | could you explain more | 19:28 |
| AlbertA | anpok: what do you mean start with zero | 19:29 |
| AlbertA | anpok: alpha zero as background you mean? | 19:29 |
| anpok | clear the frame buffer on usc, and every nested session that has an alpha channel to rgba=0,0,0,0 | 19:29 |
| anpok | yes | 19:29 |
| AlbertA | anpok: ok, yeah that's what we kinda do | 19:30 |
| === dandrader is now known as dandrader|afk | ||
| anpok | so if the the normal blend mode (1,1-alpha) is not enough, we might have to extend the api | 19:31 |
| anpok | so I think (alpha,1-alpha) is just wrong | 19:31 |
| anpok | i mean we could extend the api to override the normal blending with other modes | 19:32 |
| anpok | ah something like nv_blend_equation_advanced | 19:36 |
| AlbertA | anpok: I suppose that in the nested case the resulting surface will have pre-multiplied rgb components | 19:37 |
| anpok | yes | 19:37 |
| AlbertA | anpok: and I suppose the QT renderer will produce the same as well | 19:37 |
| AlbertA | anpok: so yeah I can see we need to assume pre-multiplied alpha | 19:37 |
| anpok | hm we have to places, the demo_renderer and the gl_renderer | 19:38 |
| AlbertA | anpok: right | 19:38 |
| anpok | looking forward to the review :) | 19:38 |
| anpok | we even have a test case that requires current behavior | 19:39 |
| AlbertA | anpok: what do you mean? | 19:39 |
| anpok | the test case of gl_renderer is kind of .. odd | 19:39 |
| anpok | whenever you change something there you have to update the test case | 19:40 |
| anpok | i mean, you cannot change it without breaking the unit test | 19:40 |
| anpok | ah with review - i meant that I expect further comments with regard to alpha usage in gernal | 19:41 |
| anpok | hm the round corners of the window decoration look strange now | 19:44 |
| AlbertA | anpok: ummm, actually now that I think about it...you can change the surface global alpha | 19:45 |
| AlbertA | anpok: which means we can't assume pre-multiplied either | 19:45 |
| racarr__ | gonna top approve https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-2-resubmit/+merge/217685 | 19:45 |
| racarr__ | soon | 19:46 |
| AlbertA | anpok: I suppose we could change the shader to make it so...but doesn't seem right | 19:46 |
| racarr__ | unless anyone else wants to weigh in on MirCursor v. MirCursorConfiguration | 19:46 |
| anpok | racarr__: text conflicts? | 19:46 |
| racarr__ | damn | 19:47 |
| racarr__ | so close | 19:47 |
| anpok | AlbertA: hm i think we have to | 19:48 |
| racarr__ | ok fixing | 19:48 |
| racarr__ | I honestly cant believe how dumb merge algorithms are | 19:48 |
| racarr__ | I mean | 19:48 |
| racarr__ | I can because they are very easy to understand | 19:48 |
| racarr__ | its just annoying | 19:48 |
| anpok | there is a project that tries to provide a more semantic merge | 19:49 |
| racarr__ | I have seen some lately (Though only proprietary) | 19:49 |
| racarr__ | im really excited | 19:50 |
| anpok | does the merge on a whole program representation | 19:50 |
| racarr__ | yeah | 19:50 |
| anpok | i.e. the one i read about was limited to c# for now | 19:50 |
| AlbertA | anpok: yeah I see if we need to support correct alpha values in the framebuffer (for nested) I don't see a way | 19:50 |
| AlbertA | anpok: around pre-multiplied assumption | 19:50 |
| anpok | yes | 19:50 |
| anpok | AlbertA: if we dont do that we will be haunte by porte&duff | 19:50 |
| anpok | *porter | 19:50 |
| anpok | *haunted | 19:51 |
| AlbertA | right | 19:51 |
| AlbertA | :) | 19:51 |
| racarr__ | it would be a really fun problem to hack on (semantic merge) | 19:51 |
| anpok | hm we have clang now | 19:52 |
| anpok | and there is a python libclang wrapper | 19:52 |
| anpok | and you could make it learn from existing merges in the history of the project.. | 19:53 |
| racarr__ | haha. thats an even more fun problem | 19:53 |
| anpok | i.e. if dev a integrates code of dev b and there is conflict | 19:53 |
| racarr__ | I was thinking you could jut come up with | 19:53 |
| anpok | always take dev a.. or something.. | 19:53 |
| racarr__ | lots of hardcoded scenarios | 19:53 |
| racarr__ | that would solve most dumb problems | 19:53 |
| anpok | ok | 19:53 |
| racarr__ | i.e. a class definition gains | 19:53 |
| racarr__ | two method declarations | 19:54 |
| racarr__ | at the same line | 19:54 |
| racarr__ | isnt a conflict :p | 19:54 |
| racarr__ | its just two people adding a method to a class | 19:54 |
| anpok | but in different order | 19:54 |
| racarr__ | well right, somethings the order does matter, whereas if two developers put a method definition in a class | 19:55 |
| racarr__ | at the same time | 19:55 |
| racarr__ | its probably just fine to put the one that was added latter (in terms of timestamp) on the line after | 19:55 |
| racarr__ | sometimes* | 19:55 |
| anpok | AlbertA: ah that would just be frag*alpha in the shader | 19:59 |
| anpok | it looks like someone did that on purpose the way it is done now | 19:59 |
| anpok | and thats good | 19:59 |
| AlbertA | anpok: right the issue is how do you know which sources are pre-mutiplied already | 19:59 |
| AlbertA | anpok: and which ones aren't | 20:00 |
| AlbertA | anpok: what's in the shader currently is only to handle global alpha | 20:01 |
| anpok | hm right now all our client surface are.. but most of them have alpha=1 so we do not notice the difference | 20:01 |
| AlbertA | anpok: :) he yeah I guess if we look at it that way... | 20:02 |
| anpok | if fingerpait would bitblt an rpba png image wihout telling lpng to premultiply | 20:03 |
| anpok | i guess then we would have that case | 20:03 |
| anpok | (can libpng do that?) | 20:04 |
| AlbertA | anpok: not sure... | 20:04 |
| AlbertA | anpok: but yeah I guess we don't change the shader | 20:04 |
| AlbertA | anpok: or rather | 20:04 |
| anpok | why not? | 20:04 |
| AlbertA | anpok: I mean yeah change the shader but correctly compute the global alpha and just assume | 20:05 |
| anpok | ah o | 20:05 |
| anpok | k | 20:05 |
| AlbertA | anpok: the source is already pre-multiplied | 20:05 |
| rsalveti | kgunn: glmark2 just got approved | 20:06 |
| rsalveti | should be migrated soon | 20:06 |
| kgunn | \o/ thanks much rsalveti ... josharenson ^ | 20:06 |
| anpok | AlbertA: do you understand how the top decorations are drawn in the demo renderer | 20:07 |
| AlbertA | anpok: the title bar? | 20:10 |
| anpok | yeah, hm the part that should be cut off just started to get shine in the colors of the rainbow | 20:10 |
| anpok | -to get | 20:11 |
| anpok | there is something wrong | 20:11 |
| AlbertA | anpok: oh really? I'm not seeing that...you mean with the tip of mir devel? | 20:11 |
| anpok | if you swith to porter&duff over blending, then the top corners of the window are not properly cut off | 20:15 |
| AlbertA | ahhh... | 20:15 |
| anpok | but thats an error in the code that draws the decoration | 20:15 |
| AlbertA | saturation? | 20:15 |
| AlbertA | or maybe overflow | 20:15 |
| AlbertA | wrapping around | 20:15 |
| anpok | it does if(at corner) { if(in above cricle) { cancel } } if(cy<y) { shade ) | 20:16 |
| anpok | but it should be | 20:16 |
| anpok | it does if(at corner && (in above cricle) { cancel } else if(cy<y) { shade ) | 20:16 |
| anpok | demo_renderer.cpp:98 | 20:17 |
| anpok | hm still strange | 20:18 |
| anpok | ah yes it is a wonderful case of non premultiplied | 20:20 |
| anpok | as it only sets the alpha value but does not multiply it to the rgb | 20:21 |
| anpok | AlbertA: will you create an MP? | 20:25 |
| josharenson | yes thanks rsalveti... So I can look for it in universe in a few days? | 20:29 |
| rsalveti | josharenson: yeah, probably later today | 20:30 |
| rsalveti | https://launchpad.net/ubuntu/+source/glmark2 | 20:30 |
| rsalveti | once it migrates from proposed to release | 20:30 |
| anpok | racarr__: you mean you need someone to top approve? | 20:32 |
| racarr__ | anpok: Ah well I was going to do so | 20:33 |
| racarr__ | I just wanted to | 20:33 |
| racarr__ | submit the suggestion to the academy before doing so | 20:34 |
| racarr__ | :p | 20:34 |
| anpok | heh | 20:36 |
| anpok | discussion there seems to be at a dead end | 20:37 |
| anpok | agreement about an overall disagreement.. | 20:37 |
| anpok | in any case you might want to look at https://code.launchpad.net/~andreas-pokorny/mir/drop-dynamic-ptr-cast-in-input-configuration/+merge/218806 | 20:39 |
| anpok | since you are browsing right now.. | 20:39 |
| anpok | maybe i should wait for monday | 20:42 |
| racarr__ | anpok: Ill try and look in just a few min | 20:52 |
| === dandrader|afk is now known as dandrader | ||
| tedg | Is there an API for the trusted sessions somewhere? | 21:22 |
| AlbertA | anpok: yeah I will create it...right now I'm mostly concerned about getting unity8 just to work right | 21:29 |
| AlbertA | anpok: I could propose later to fix the support for transparent frame buffers | 21:30 |
| AlbertA | anpok: because switching to porter/duff is practically only applicable to nested usecase | 21:36 |
| AlbertA | anpok: where corrrect alpha is needed | 21:36 |
| AlbertA | anpok: in all other cases including screencasting there's no need | 21:36 |
| anpok | AlbertA: hmm... right now we do apply the alpha channel twice | 21:37 |
| AlbertA | anpok: but as you said, right now unity8 is rendering with alpha 1.0 so it doesn't matter | 21:38 |
| anpok | yes | 21:38 |
| AlbertA | anpok: it only matters in the demo shell I suppose | 21:38 |
| anpok | and potential transparency effects in the greeter some day | 21:39 |
| AlbertA | anpok: right | 21:39 |
| AlbertA | anpok: so maybe for now my initial fix of rendering an opaque background is enough (so that unity8 renders correctly) | 21:40 |
| AlbertA | anpok: then we can open the alpha can-of-worms | 21:40 |
| AlbertA | anpok: :) | 21:40 |
| anpok | first or second one? | 21:46 |
| anpok | confused | 21:46 |
| AlbertA | anpok: I think https://code.launchpad.net/~albaguirre/mir/render-opaque-background/+merge/218712 | 21:47 |
| AlbertA | anpok: is the simples solution for now for both the transparent screencast issue and the unity8 rendering issue | 21:47 |
| AlbertA | anpok: and then we need a discussion on supporting transparent framebuffers properly | 21:48 |
| AlbertA | anpok: I think probably an attribute of the DisplayBuffer so we can change | 21:49 |
| AlbertA | anpok: blening modes in the renderer could be the solution | 21:49 |
| AlbertA | anpok: maybe an opaqueness attribute | 21:49 |
| AlbertA | anpok: that the compositor can pass to the GLRenderer | 21:50 |
| anpok | ack | 22:03 |
| AlbertA | anpok: yeah an opaqueness attribute makes sense to me...that way we say non-opaque on the nested display buffer | 22:05 |
| AlbertA | anpok: and everything else opaque | 22:05 |
| AlbertA | anpok: i.e. the platform's display buffer and the screencast display buffer | 22:06 |
| anpok | well we have the pixel format | 22:06 |
| AlbertA | anpok: true but for some reason | 22:06 |
| AlbertA | anpok: the platforms are returning one with alpha support | 22:07 |
| anpok | ah yes | 22:07 |
| AlbertA | anpok: dunno why...and the nested display buffer just replicates that | 22:07 |
| anpok | and independent of that if the clients of the nested session make use of transparency we still have to blend properly | 22:07 |
| AlbertA | anpok: right which we haven't seen since nobody is rendering with per-pixel alpha at the mir level | 22:10 |
| AlbertA | anpok: it's all done by Qt...I wonder how they blend | 22:11 |
| * AlbertA goes to check | 22:11 | |
| AlbertA | anpok: glBlendFunc(GL_SRC_ALPHA, GL_ONE); | 22:20 |
| AlbertA | anpok: which I suppose makes sense, always make the destination opaque | 22:21 |
| AlbertA | anpok: well I'm not sure that's what they use---just found some hints here and there | 22:22 |
| anpok | thats odd | 22:22 |
| AlbertA | anpok: no nevermind one of the comments alludes to | 22:25 |
| AlbertA | glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA) | 22:25 |
| AlbertA | in qsgrendernode.cpp | 22:26 |
| AlbertA | all makes sense now | 22:26 |
| AlbertA | :) | 22:26 |
| anpok | http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]] -- So anyway, yeah, premultiplied alpha. Use it, love it, pass it on. Then maybe we'll only take another 20 years til everyone's doing this stuff correctly. | 22:29 |
| anpok | good | 22:29 |
| josharenson | kgunn, it appears as though you cannot run glmark2 offscreen on android | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!