=== salem_ is now known as _salem === rsalveti_ is now known as rsalveti [07:42] didrocks: hey. is there a way to enable arm builds for my ppa? [07:42] hey mzanetti, which ppa? [07:42] didrocks: https://launchpad.net/~mzanetti/+archive/testing [07:42] mzanetti: this will ask to use a non virtual ppa, we try to diminish the need as possible [07:42] mzanetti: personal ppa? I doubt about it [07:43] didrocks: so the only way to publish apps is to upload them to the official touch apps ppa? [07:44] mzanetti: right now, but this week will be to use daily releases [07:44] mzanetti: we need to transition to HUD 2 today, as discussed with sergio and ricardo [07:44] hey sil2100! how are you? [07:44] sil2100: btw, ready to push HUD 2 today? ^ [07:45] sil2100: do you mind coordinating with mzanetti on the medium tests so that we can transition to it? (not sure if we should disable temporarly to get things merged and so on) [07:45] didrocks: can't really follow... what has HUD to do with this? [07:45] mzanetti: because we don't have daily release until apps are migrated to new HUD [07:45] don't/can't [07:45] as we have a newer HUD in the ppa [07:45] didrocks: we are [07:45] meaning [07:45] i have branches waiting [07:46] https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603 [07:46] tsdgeos: yeah, I was waiting for the finale quantal touch image to be in, which should be done by done? [07:46] didrocks: I don't need daily releases... I just want to upload an app somewhere so it gets build for arm and I can install it on my phone again [07:46] mzanetti: you can use the touch ppa for one manual upload, yeah [07:46] and https://code.launchpad.net/~aacid/unity/new_hud_client_api/+merge/156616 [07:46] mzanetti: this will be reconverted for that purpose [07:46] actually only the first is needed [07:46] the for it to work [07:47] tsdgeos: there is not only unity-next, but good to know it's ready ;) [07:47] the second is to use the improvements [07:48] didrocks: well i said "we" ;) for a certain definition of we ;) [07:48] heh ;) [07:48] didrocks: that's going where? raring? or s-something? [07:48] thanks tsdgeos! will keep you posted once we have the base transition done [07:48] tsdgeos: raring daily-build-next and next ppas [07:48] tsdgeos: which will go into s then [07:48] i see [07:48] tx [07:48] yw! [07:49] mzanetti, can you please investigate ignoring /tests for coverage? [07:49] Saviq: ack [07:50] *** Error in `/usr/bin/perl': corrupted double-linked list: 0x029f0fe8 *** [07:50] :_S [07:50] tsdgeos, panda? [07:50] yeah [07:50] tsdgeos, yeah, they sometimes go there and cry in the corner :/ [07:50] hence the black eyes [07:59] mzanetti, tsdgeos, there seem to be issues with publishing (not just delay) in the end [08:00] mmrazik: ^ [08:00] mmrazik: known issue or new? [08:00] the last published ones are from yesterday 2pm https://jenkins.qa.ubuntu.com/job/unity-phablet-ci/ [08:00] mzanetti, Saviq: let me check. We had some issues in the past (several months ago) [08:06] mzanetti: ping [08:08] Saviq, mzanetti: its a different thing than in the past :-/ There are no errors. It looks like the publishing just takes ages [08:08] I might need Larry to figure out whats going on [08:08] it might be high load on jenkins.qa.ubunut.com or something like that and I have no access there [08:08] mmrazik, thanks [08:08] dednick, ping https://code.launchpad.net/~nick-dedekind/unity/phablet.run_on_device_gdb/+merge/159378 ? [08:09] Saviq: thanks. seen it. i'll take a look [08:09] dednick, cheers, just going through the active MPs [08:12] mzanetti: when you were looking at the network indicator layout issue, did you say it WASNT working in the chewie-client, or it WAS? [08:12] dednick: it wasn't here on desktop [08:12] mzanetti: hm. odd. working on mine [08:12] dednick: however, I use my desktop at GRID_UNIT_PX=18. That might makes a difference [08:13] mzanetti: ah. is that just an env setting i can change to test? [08:13] dednick: yes [08:13] dednick: also, I think the fix I proposed (use height instead of implicitHeight) got merged. [08:14] so if you try with current trunk it might be fixed [08:14] mzanetti: that's the same px as the nexus phone right? [08:14] dednick: i think the same as Galaxy Nexus. The n10 uses 20 if I'm not mistaken [08:16] dednick, also, there seems to be a regression with the indicators in trunk, when you swipe over an indicator quickly, the page is blank until you un-pin the indicator from the bottom [08:17] dednick, and "MenuContent.qml:102: TypeError: Object ClockPage_QMLTYPE_265(0xc29478) has no method 'reset'" [08:17] dednick, can you please look into that? [08:17] Saviq: sure [08:17] dednick, it looks like when the indicators are unloaded, they don't come back as soon as they are loaded again [08:19] Saviq: the indicators are only supposed to be loaded when you press the indicator bar. Previously they were being loaded on startup because of a bug. [08:19] but maybe we want that... [08:19] dednick, yeah, that's fine [08:19] dednick, but they don't load at all [08:19] dednick, well, they do, but are invisible [08:19] didn't sergio said that images where now raring based? [08:19] i just did phablet-flash and got a quantal one [08:20] tsdgeos, yeah, I still had to use the --alternate-settings approach [08:20] Saviq: ok. i havent seen that. I've only seen that they pop up after a bit of a delay [08:20] Saviq: i'll take another look [08:20] Saviq: doh :/ [08:20] tsdgeos, and it did download quantal-* anyway [08:32] mzanetti, I'd say that's hanging... :/ [08:33] http://10.97.2.10:8080/job/generic-mediumtests-runner/1263/console [08:33] Saviq: hmm... not sure... [08:33] 23 minutes is indeed a bit long for autopilot tests... [08:33] mzanetti, shouldn't there be more output? [08:34] Saviq: no [08:34] mzanetti, ah k [08:34] Saviq: autopilot doesn't print anything if you tell it to log to an xml file [08:34] mzanetti, sounds like room for improvement ;) [08:35] Saviq: actually... I've been asked to ask you to join a session about autopilot in Oakland [08:35] Saviq: feedback to developers of autopilot mainly. interested? [08:35] mzanetti, can you invite me on the calendar? [08:35] mzanetti, sure [08:35] Saviq: there's no schedule yet. but yes, I'll let you know as soon as I know anything [08:35] mzanetti, cool, yeah, count me in [08:54] Hi :) [08:54] mzanetti: we really need to fix that "QXcbConnection: XCB error: 148 (Unknown), sequence: 148, resource id: 0, major code: 140 (Unknown), minor code: 20" thing [08:54] it's getting silly having to retrigger so many qmluitests jobs [08:54] mmrazik, could you please take a look @ the compiz 0.9.10 automerger as it stopped to work recently... ? [08:56] MCR: looking [08:56] mzanetti: also seems ps-panda-5 doesn't have the new stuff that acceps Digia licenses, can you check? [08:56] thanks a lot [08:56] MCR: was it actually working before? [08:56] tsdgeos: yep [08:56] or maybe it was renamed? [08:56] mmrazik, yes [08:56] mmrazik, https://code.launchpad.net/~compiz-team/compiz/0.9.10/+activereviews [08:57] https://code.launchpad.net/~compiz-team/compiz/0.9.10 [08:57] oh... 0.9.10 == lp:compiz [08:57] it worked until 04-18 [08:57] yes [08:57] it is not for raring anymore unfortunately... [08:58] but we still need the merger, also CI and all the rest of the cool features ;) [08:58] MCR: was lp:compiz 0.9.9 until ~04-18? [08:58] no [08:58] mhm.. [08:58] tsdgeos: panda-5 updated [08:59] MCR: I can fix it but I still don't understand why it worked before :-/ [08:59] mzanetti: cheers! [08:59] but compiz/raring was deleted and 0.9.9 became compiz/raring [08:59] I think [08:59] (I did not do this change) [08:59] didrocks: head/unity.cfg should have no target_branch for compiz, right (ATM it points to lp:compiz/0.9.9)? [09:00] some shuffling was going on... but we already worked on 0.9.10 for some time [09:00] didrocks: which is the same as raring [09:00] mmrazik: didn't I change that? [09:00] mmrazik: let me recheck, I'm almost sure I changed it [09:00] hi didrocks :) [09:00] didrocks: its still in trunk [09:00] hey MCR! [09:00] or let me pull.. [09:01] nope. its in the trunk [09:01] right, I'm puzzled [09:01] I'm sure I fixed it though [09:01] * didrocks checks jenkins [09:01] thanks, didrocks [09:01] didrocks: its not in your r218 [09:02] which is changing raring to 0.9.9 [09:02] mmrazik: argh, indeed [09:02] anyway... I still don't get it why 0.9.10 was landing before [09:02] didrocks: shall I just fix it? [09:03] mmrazik: I'm pushing it [09:03] ok [09:06] mzanetti: any chance we can fix the "libGL error: failed to load driver: swrast" on the thing that runs the qmluitests? maybe that way we get past the qxcbconnection stuff [09:07] didrocks, mmrazik: Does your cryptic conversation mean it's fixed ? ;) [09:07] MCR: I'm just waiting for the triggering job to finish [09:07] MCR: lp:compiz is taken into account, yeah ;) [09:07] MCR: but it looks like the jobs are queued [09:07] just wanted to wait with the "yes, its fixed" message :) [09:08] cool - that was fast, thanks -> I shout out loud if the merger stays on weekend mode [09:09] MCR: yes please. Unfortunately these sort of errors are hard to find. I have a watchdog that looks for merge proposals that are approved but not merged for a long time. But that only works for branches we are "aware" of (i.e. they are configured to autoland). [09:09] in this particular case the error was that lp:compiz was not even configured to autoland [09:10] mmrazik, no problem @ all, if it gets fixed that fast... thanks a lot [09:10] (which was a typo) [09:10] Saviq: I've got to go out before our standup today and I may not be back by then. Shall i just add my work to the standup doc? [09:10] dednick, please do [09:10] mmrazik, you are always super-responsive +1 [09:10] tsdgeos: I'll try [09:16] mzanetti, Saviq: found the issue with indicators height. The BasicMenu type changed recently to a Ubuntu.Component.ListItem.Standard which has a height set. needed to heigh: undefined everything using implicitHeight [09:17] dednick, ah! [09:17] nice [09:17] dednick, good catch [09:18] mzanetti, pushed lp:~saviq/+junk/interface-tests with a SignalSpy and _data()-driven where applicable [09:18] just making sure i didnt break anything and i'll put a MP throught [09:18] Saviq: ack. I'll check it out [09:27] duflu, hi. I would like to bring the ubuntu code-patches (for scale and expo for example) inline, otherwise the code is hard to maintain. Do you know the reason why they have been made Ubuntu-only ? [09:29] MCR: Because they did not meet Compiz standards, and more importantly upstream Compiz didn't like them :) [09:30] MCR: Hang on... I upstreamed them already... !? [09:31] I like them and they do not need specific Ubuntu-only functions or depend on nux as far as I could tell... [09:31] duflu, I am not sure... [09:32] duflu, scale for example... [09:32] MCR: Looking at lp:compiz, they are not patches any more (?) [09:32] So what do you mean? [09:33] well, I compiled scale from lp:compiz and it does not have the close button and title overlapping... [09:33] I did not apply the patches yet, though... [09:33] so I am not 100% sure [09:34] duflu, do not worry about it -> I'll have to look into it in detail yet [09:34] just wanted to know which was the reason in the first place [09:34] MCR: Oh right, the Unity modifications. No. Those live in lp:unity AFAIK and upstream does not want them. Last time I asked around. [09:35] sure - they should live in lp:compiz ofc [09:35] Besides, you can close windows with scaleaddon. A proper upstream compiz solution would use or extend scaleaddon [09:35] sil2100: still not around? ;) [09:35] MCR: No we don't want them in lp:compiz. They're ugly and Unity-look-specific :) [09:35] ;) [09:36] Umm, pretend I didn't say the first bit [09:36] MCR: Anything that looks like Unity should be in lp:unity. But feel free to add a generic-looking close/cross button [09:36] dednick, I just reproduced the empty indicator on current release image, so it might not be a regression after all, or at least not a new one [09:37] duflu, it is not unity-specific in this case ;) [09:37] it will use whatever theme the user uses... [09:37] Saviq: does it happen when you first load the session? [09:37] for the titlebar in scale [09:37] dednick, not really, it happens whenever [09:37] but scaleaddon would be the place to be, I agree... [09:37] dednick, I think I see what the issue is [09:38] MCR: Hmm. Well I don't think that's the solution I would approve. But I don't approve things any more so you don't need my view [09:38] Saviq: hm. ok. I've seen it take quite a long time, but never not show at all. Is it a specific indicator, or anything? [09:38] dednick, it happens when I release the touch before crossing the threshold that makes it show at all [09:38] duflu, I always respected your view ;) [09:38] Saviq: ah. ok [09:38] and still am [09:38] Saviq: possibly a state change issue [09:39] dednick, yeah, simple way to reproduce: touch panel, drag minimally down until the grey bar comes down, release [09:39] Saviq: yeah. just got it [09:39] but it is hard to fix things in expo for example with this patch mess... [09:40] dednick, cheers === dandrader is now known as dandrader|afk [09:41] MCR: I resolved the "patch mess" last year. What are you talking about? [09:41] duflu, maybe I am confusing 2 issues now -> scale and expo [09:42] I was just working on scale recently [09:42] so I just noticed the scale problem and thought it might be the patch issue, but did not look into it in detail [09:43] MCR: There are no major scale/expo patches any more. See: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.10/files/head:/debian/patches/ [09:43] \o/ [09:43] I wonder how old your branch is :) [09:43] ;) [09:44] isn't 0.8 the right one ? === seif is now known as Guest93284 [09:51] dednick: why the file test_categories ? [09:53] tsdgeos: just a script to run the CategoryScene test. [09:53] although not really a test. just a debug scene [09:53] do we really need that? [09:53] the Scene, or the script? [09:53] ah [09:53] so it's not "really a test" [09:53] ? [09:54] tsdgeos: no. it's just to verify that the category results are working correctly [09:54] can't we do that in a test? [09:55] I built unity-next according to the instructions provided on wiki.ubuntu.com just to try it out. After that I removed however I noticed that there are 2 additional lenses as seen in http://imgur.com/RS0RUm4. How do I remove them? [09:55] does anybody know the package name? [09:55] tsdgeos: i guess its in the dash tests or will be when it gets merged. [09:55] i'll remove it. [09:56] tsdgeos: it was just so i could debug when writing the unity pugin stuff. [09:56] i see === dandrader|afk is now known as dandrader [09:57] dednick: any particular reason for the change in Lenses::updateLenses ? [10:00] tsdgeos: not really. just though more sense to have a non-visible Music lens, than Home lens (even though it's just test data). [10:00] oki [10:07] dednick: the fact that there is no globalresults is on purpose? [10:11] tsdgeos: you mean different to the normal results? [10:14] dednick: yep [10:14] i mean the non fake lens.cpp does [10:14] m_categories->setResultModel(m_results); [10:14] m_categories->setGlobalResultModel(m_globalResults); [10:14] you do [10:14] + m_categories->setResultModel(m_results); [10:14] + m_categories->setGlobalResultModel(m_results); [10:16] it is true that we're not using globalResults anywhere i think [10:16] so if that's the reason i'm ok [10:16] just asking [10:16] tsdgeos: yeah. we didnt seem to be. so i didnt see a point until we do. [10:17] ok [10:18] dednick: what's the other branch that depends on this? [10:18] launchpad tells me there are 2 but when clicking on the link gives me an empty page :-S [10:18] tsdgeos: i would have thought the home lens would use it. but it seems to use filter models with the normal results [10:20] tsdgeos: https://code.launchpad.net/~nick-dedekind/unity/phablet-tests-dashcontent/+merge/159459, https://code.launchpad.net/~nick-dedekind/unity/phablet-tests-dash/+merge/160032 [10:20] tx [10:21] tsdgeos: i think Cimi has got some as well [10:22] ok [10:22] approved, looks good [10:23] tsdgeos: ta [10:27] Saviq: https://code.launchpad.net/~nick-dedekind/unity/phablet.indicators.small-swipe/+merge/160321 [10:27] mzanetti: https://code.launchpad.net/~nick-dedekind/indicators-client/menu-implicitHeight/+merge/160310 [10:28] just letting you know they're there :) [10:30] dednick, awesome, approved [10:30] dednick: I don't think explicitly setting height to undefined is what we should do [10:31] dednick: can't we fix the issue in its root instead of working around it in some upper layers? [10:31] I can't see how this would be better than the preivous version [10:31] mzanetti: yeah, i wasnt really sure about that. [10:31] mzanetti: but the issue is in Ubuntu.Components [10:32] dednick: then it'll bite us over and over again I guess unless we report a bug to the SDK guys [10:32] mzanetti: could maybe use implcitHeight there... [10:32] dednick: yeah. I think that would be way to go [10:32] dednick, yeah, sounds like if Standard has a height: defined, it's a bug [10:32] dednick, please pick it up with sdk guys [10:34] mzanetti, Saviq: ok. who's on the sdk team ? :) === seif is now known as Guest16675 [10:34] dednick: bzoltan, timp, zsombi [10:34] didrocks: eek [10:34] ta [10:34] didrocks: took me longer than I thought, uugh [10:35] the HUD 2.0 work? [10:35] No, I jumped out to the bank to take out some money for Oakland ;) [10:35] ah ok [10:35] Now, doing HUD! [10:35] great ;) [10:38] mzanetti: do you know why we use implicitHeight anyway? what is the benifit? [10:39] dednick: in this particular case? [10:39] mzanetti: ya. [10:40] dednick: no... I would be fine with real height in here as its the end user representation... still the SDK using height instead of implicitHeight feels like a bug. [10:40] mzanetti: ok. [10:41] Saviq: wanted to keep the implicitHeight here which - regarding chewie's overengineered architecture - could make sense... [10:41] dednick: ^ [10:41] dednick, height/width should never be defined on top-level component in a QML file [10:42] dednick, implicitHeight/implicitWidth is there exactly for that purpose - "if height is not defined otherwise, here's my default height" [10:42] Saviq: ok. thanks. [10:42] dednick: basically chewie doesn't paint a full UI itself, but rather has a set of components that are compiled together by the middleware as needed. So everything can be seen as components in there [10:42] dednick, and if the component is used wrong, it's the component user's fault, not the component's [10:57] Saviq, mzanetti: looks like renato made changes to the ListItem to fix that issue. we're just not using an up-to-date version of ubuntu-ui-toolkit [10:57] dednick, ah, so the fix wasn't released yet? [10:58] it's in trunk, but not sure about the ppa [10:58] attempting to update now and see [11:01] mmrazik, seems there are still Jenkins issues left... armhf builds seem failing and the links point to 404 errors [11:01] MCR: we have some issues with publishing the results to public jenkins [11:01] MCR: what is the link which gives you 404? [11:01] https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1168919-multimonitor-cube-gears-green-gear-always-in-front/+merge/158790 [11:01] (for some reasons it takes up to 17h to get it published :-/) [11:01] the last comment by Jenkins [11:02] the failure link === MacSlow is now known as MacSlow|lunch [11:02] MCR: it looks like some jenkins problem :-/ http://pastebin.ubuntu.com/5595249/ [11:03] mmrazik, the same here: https://code.launchpad.net/~mc-return/compiz/compiz.merge-showmouse-another-cleanup/+merge/159993 [11:03] MCR: I need to go to doctor but will be back in ~hour [11:03] will check it then [11:03] thanks [11:03] happy healing [11:03] mmrazik, ping [11:04] tvoss: pong === mmrazik is now known as mmrazik|afk [11:07] Saviq: I think we're using standard sdk that comes with raring. We should be be adding the ubuntu-sdk ppa to the build script. [11:08] dednick, but it was broken on the device, which uses the phablet-team ppa [11:08] Saviq: i c. phablet-team doesnt include ubuntu-ui-toolkit package. [11:08] hmm [11:09] so where are we getting it for the device images from.... [11:10] i have no idea. trying to track it down now. [11:11] Saviq: qtdeclarative5-ubuntu-ui-toolkit-plugin [11:11] dednick, yeah that I know, just where does the package come from... [11:12] right, so ubuntu-ui-toolkit is already daily-landed [11:15] Saviq: isn't michi on irc? [11:15] mzanetti, at the moment he's probably in bed [11:15] mzanetti, well, maybe not yet, but it's 9pm for him [11:15] Saviq: no... he comments to my MPs [11:15] Saviq: ah... I thought he would be from sweden [11:16] mzanetti, nope, Brisbane [11:16] oh... brisbane [11:16] mzanetti, http://s-jenkins:8080/job/unity-phablet-ci/730/ stuck? [11:17] or just queued.. [11:17] Saviq: queued :/ we bumped the ticket's priority today morning [11:17] Saviq: the one for more VM's [11:17] .thanks [11:18] damn MIR! ;P [11:18] Saviq: proably queued, see http://s-jenkins:8080/job/unity-phablet-qmluitests/ [11:18] yeah it just started [11:27] tsdgeos, this should be ok... https://code.launchpad.net/~unity-team/unity/phablet.test_GenericLensView/+merge/160143 [11:28] Cimi: you should make that depend on the other MR that does the CategoryFilter changes and stuff [11:28] otherwise it's going to be a mess when merging [11:28] tsdgeos: Saviq: good news. I think I found the issue. well not found the root cause, but found how to reliably work around it (I hope). If you see it happening again, please ping me immediately [11:29] mzanetti, which one? publishing? or getting stuck? [11:29] talking about getting stuck I am [11:29] awesomer [11:29] tsdgeos, done [11:30] Saviq: regarding the publishing: it seems to be on the public jenkins instance which is not maintained by us. martin opened a ticked [11:30] mzanetti, k thanks [11:30] ticket === dandrader is now known as dandrader|lunch [11:50] didrocks: hmmm [11:50] didrocks: the hud switch might be a bit troublesome [11:51] mzanetti, got time for another quick QML Q? [11:51] nic-doffay: of course [11:51] Check this out: https://pastebin.canonical.com/89744/ [11:51] I'm trying to pass the X & Y values of the itemAtIndex of the first Repeater into the second Repeater. What is the correct way to achieve this? [11:52] nic-doffay: I wouldn't use 2 repeaters [11:53] mzanetti, what would you suggest? [11:54] nic-doffay: something like this: https://pastebin.canonical.com/89749/ [11:55] nic-doffay: would that work for your case? [11:55] mzanetti, I need to specifically pass each x and y of the each dots. [11:56] But otherwise the formatting is better. [11:57] nic-doffay: like this? https://pastebin.canonical.com/89750/ [11:57] nic-doffay: anyways, theDot.x and theDot.y will be 0, 0 here [11:57] mzanetti, so that id will be the correct index? [11:58] nic-doffay: you don't need the index. the whole Item {} is repeated. inside the Item {} its just like there would be only this one [11:58] mzanetti, hmm ok. So it's probably best to regenerate the x & y from the Circle component? [11:59] nic-doffay: why do you need x & y at all? [12:00] nic-doffay: the whole Item takes care about positioning. inside the item you shouldn't need to know about it, do you? [12:00] mzanetti, because the dots are positioned according to their index in a ring. The circle object for each index needs to be at the same position the dot is. === MacSlow|lunch is now known as MacSlow [12:00] nic-doffay: it is like this [12:02] nic-doffay: if you move the Item {} around, the Dot and the Circle will also be moved accordingly, because the Item is the parent and its children will always be painted inside the parent (unless you specify something else) [12:02] mzanetti, right, I think I misunderstood something then. [12:02] I'll give it a go and get back to you... [12:02] nic-doffay: ok. let me know how it goes. [12:03] mzanetti, one more thing. [12:03] yes? [12:03] I need to trigger an animation in the Dot and the Circle. [12:03] Should I put a function in the item which calls both of them? [12:04] then reference it with itemAt(i).callFunction. [12:04] Would that be the cleanest? [12:04] nic-doffay: hmm... hard to say... depends a bit what the trigger is and what kind of animation [12:04] nic-doffay, mzanetti I think there's one more issue here - the circles need to be in a separate layer than the dots [12:05] nic-doffay, mzanetti as the circles need to be blended with the big circle [12:05] Saviq, is there no way you can specify the Z order of a Component? [12:05] and the dots just painted on top of that [12:05] nic-doffay, z-order yes, but then you need to blend [12:05] Saviq, yeah I'm going to get the blending done after the ordering is correct. [12:06] I just wanted to get the circles appearing first then move on to everything else. [12:06] nic-doffay, btw, weren't you supposed to draw the circles in GL? [12:07] nic-doffay, that's what loicm suggested, no? [12:07] I thought that was the approach, too, as it'd be more performant that way [12:07] Saviq: you think it'd really be more performant? [12:08] The circles are being drawn with a ShaderEffect atm Saviq . [12:08] I just haven't done any blending maths yet. [12:08] nic-doffay, yes, that means an fbo per circle [12:09] mzanetti, yes I believe so, if they'd be painted in single buffer instead a buffer per-circle as it is now [12:09] Saviq, that would require more work then. [12:09] Saviq: more performant in terms of memory usage you mean... not in terms of speed [12:09] ok... that could well be the case [12:09]