| RAOF | Uuuh, launchpad? Why did you just silently eat my workitems? | 02:00 |
|---|---|---|
| duflu | Uuuk, google? Why did you just silently eat my personal account and force me to retry for an hour to prove my identity? | 02:30 |
| duflu | Seriously though... I have plenty of two-factor mechanisms and instead of asking for them, Google asks me questions that no reasonable person would be able to answer. Like the month I opened my account, or the month/year I first used Calendar. | 02:34 |
| RAOF | Woah. | 02:53 |
| kgunn | RAOF: duflu ...could one of you review/approve https://code.launchpad.net/~mir-team/mir/bump-deb-changelog16-mirserver8/+merge/191548 | 03:13 |
| duflu | kgunn: Done, but needs a minor fix | 03:14 |
| duflu | kgunn: Also, I assume we've given up on keeping milestones up to date with each 0.0.N ? | 03:15 |
| RAOF | duflu, kgunn: Do we need dates in the changelog *at all*? | 03:16 |
| RAOF | s/changelog/version/c | 03:16 |
| duflu | RAOF, kgunn: Yeah if we're bumping the version this much then there's no need for a date in there too | 03:17 |
| duflu | So long as it *increases* each time | 03:17 |
| kgunn | duflu: robert_ancell used to set milestones...altho, i'm not enlightened as to its usefulness...other than maybe trying to target bugs to be done (e.g. phone-v1-freeze) | 03:18 |
| duflu | kgunn: I've been maintaining them much of the time, but they're not useful if the milestone moves this often. You need less frequent point releases. | 03:19 |
| duflu | kgunn: If we're not using them then we should have even just one milestone for the release and target that | 03:19 |
| kgunn | RAOF: duflu ...as to date, dunno, i thot there was some esoteric reason it was needed | 03:19 |
| duflu | kgunn: I think we're free with version strings. So long as they increase and also end with -NubuntuN. The prefix is our own choice | 03:20 |
| duflu | ... the prefix being the upstream project version without -NubuntuN | 03:21 |
| kgunn | duflu: so you guys are saying instead of this 0.0.16+13.10.20131011-0ubuntu1....we should just make it 0.0.16-0ubuntu1 | 03:23 |
| duflu | kgunn: I think so | 03:23 |
| RAOF | Yup. | 03:23 |
| kgunn | robert_ancell: ^ what you say even tho you no workie on mir anymore | 03:23 |
| robert_ancell | the only reason I was stamping versions was so we could mark bugs as closed against that version | 03:24 |
| robert_ancell | recently the version is useful for bumping build dependencies | 03:24 |
| duflu | Although the "16" is meaningless. It would have more meaning if we replaced "16" with "<bzr rev number>" | 03:24 |
| robert_ancell | I'd agree with duflu using the bzr revision number is more useful | 03:24 |
| robert_ancell | and having some sort of major version number for telling the difference between versions in Ubuntu | 03:25 |
| duflu | Then the "0.0" is a placeholder for real project versioning (in future) | 03:25 |
| duflu | Yeah, the major.minor needs to change, somehow, for each cycle at least | 03:26 |
| kgunn | duflu: ok...can we go with this for this time, let me coordinate with didrocks tomorrow.....i don't want to switch it up and have a reason for grinding everything to a halt | 03:26 |
| duflu | Fair point. My experience with versions and didrocks that anything which increases is fine. And anything with meaning is better | 03:27 |
| duflu | *is that | 03:27 |
| duflu | Argh. Although in using revision numbers you have to remember *only* the development-branch has useful history now. So it would have to be the revision of development-branch | 03:31 |
| duflu | And similarly, when branching post-saucy, that has to branch from development-branch. Or else we lose the history. Because lp:mir presently has no useful history | 03:35 |
| kgunn | duflu: now ? https://code.launchpad.net/~mir-team/mir/bump-deb-changelog16-mirserver8/+merge/191548 | 03:46 |
| duflu | kgunn: Needs fixing still :( | 03:52 |
| duflu | Really, we're not using milestones and the "16" is meaningless. So we should go to upstream version "0.1" or higher. And let ubuntu saucy versions be "0.1-0ubuntuN". | 03:56 |
| duflu | or "13.10..." :) | 03:56 |
| kgunn | ok strange...i remerged from trunk, that went fine, dch -i and did all the updates...all seemed fine... | 04:17 |
| kgunn | but now, when i try to push...is says error "These branches have diverged." | 04:18 |
| kgunn | but when i do bzr missing it just shows my one commit... | 04:18 |
| kgunn | and a merge from dev-branch results in "nothing to do" | 04:20 |
| RAOF | Where are you pushing to? | 04:25 |
| duflu | kgunn: bzr info to see where you're pushing to. Verify it's your own and not a shared branch. Then explicitly: bzr push --overwrite lp:~kgunn/mir/somewhere | 04:34 |
| kgunn | duflu: ok...now? | 04:41 |
| duflu | kgunn: All approved. But then again... I'm not sure if and where we actually broke the server ABI :) | 04:46 |
| duflu | ... hence it might not have needed incremening | 04:46 |
| duflu | +t | 04:46 |
| om26er | duflu, hey! | 08:15 |
| om26er | duflu, got an opinion on bug 1240841 ? | 08:16 |
| ubot5 | bug 1240841 in mir (Ubuntu) "[Mir]In-App scrolling is lagging much" [High,New] https://launchpad.net/bugs/1240841 | 08:16 |
| duflu | om26er: Hi | 08:16 |
| * duflu looks | 08:16 | |
| tvoss | om26er, which image? | 08:16 |
| tvoss | om26er, maguro? | 08:16 |
| om26er | tvoss, 100 mako | 08:16 |
| tvoss | om26er, was it present yesterday? | 08:17 |
| om26er | tvoss, yes it was | 08:17 |
| duflu | om26er: Probably not Mir at least. Since native Mir demo clients are perfectly smooth | 08:17 |
| duflu | But maybe... | 08:17 |
| tvoss | om26er, can you please verify with a less complex client than the browser? | 08:18 |
| om26er | tvoss, ok, let me try the contacts app | 08:18 |
| tvoss | om26er, ideally, something without too much interaction with the underlying system would be helpful | 08:19 |
| tvoss | om26er, to isolate variables | 08:19 |
| duflu | That's fun. The Mir branches appear to have had Compiz tags imported into them at some point. How useless. Now deleting them | 08:25 |
| om26er | tvoss, its visible in address-book as well | 08:27 |
| om26er | with only 38 contacts in the list | 08:27 |
| duflu | om26er: On startup too (not many surfaces running in the background)? | 08:28 |
| om26er | just rebooted. lets see | 08:29 |
| duflu | om26er: P.S. occlusion optimizations just landed, but don't do anything on mako because --> bug 1240833 | 08:29 |
| ubot5 | bug 1240833 in Mir "[feature] Expose at least one non-alpha pixel format for Nexus 4" [Medium,Triaged] https://launchpad.net/bugs/1240833 | 08:29 |
| om26er | duflu, will it help on nexus 7 ? | 08:30 |
| * ogra_ sees it on maguro with the browser and all webapps (though i was blaming the browser initially) | 08:30 | |
| duflu | om26er: Haven't looked yet | 08:30 |
| duflu | Yeah it seems the browser is naturally slower than other apps anyway | 08:30 |
| ogra_ | (lagging and horrible jumpiness when scrolling that it) | 08:31 |
| duflu | It has a lot to do | 08:31 |
| ogra_ | well it didnt do that a week ago or so | 08:31 |
| om26er | duflu, facebook.com or omgubuntu are really smooth in the browser under Mir. there are other sites that can be slow but these 2 are super smooth | 08:31 |
| ogra_ | and indeed i dont see that on mako | 08:31 |
| om26er | *under SF | 08:31 |
| duflu | om26er, ogra_, Yeah I think we know our Android rendering is sub-optimal. I don't know what is planned to fix there next. Best ask kdub. | 08:32 |
| om26er | duflu, just rebooted. visible right after phone starts in contacts app | 08:32 |
| tvoss | om26er, just augment the bug with your findings. Ideally add a video, we will look at it | 08:32 |
| ogra_ | duflu, well, maguro has other more low level probs too with Mir ... like exposing a uevent for *each* vsync, seems that doesnt happen on SF | 08:33 |
| duflu | ogra_: Sounds bad. But I'm no Android expert | 08:33 |
| ogra_ | yeah | 08:33 |
| tvoss | ogra_, do we have a bug report for that? | 08:33 |
| ogra_ | tvoss, yes, pitti is just working with om26er on one of the fallout bugs in #ubuntu-touch | 08:34 |
| ogra_ | (one is that udevd eats constantly 10%+ on maguro, the other is that upstart picks up these events and collects ram like crazy) | 08:35 |
| ogra_ | tvoss, we dont really have a bug against Mir for it, but i think somewhere in Mir lies the root of this | 08:35 |
| ogra_ | seems SF somehow tells the driver to stop the event spam (probably through a special arch specific switch) | 08:36 |
| tvoss | ogra_, digging | 08:36 |
| om26er | tvoss, ok. will do | 08:36 |
| === pete-woods is now known as pete-woods-brb | ||
| tvoss | om26er, did you upload the video, yet? | 09:07 |
| om26er | tvoss, i was helping pitti with some udev debugging | 09:08 |
| tvoss | om26er, ack | 09:08 |
| om26er | tvoss, will upload in a few minutes | 09:08 |
| om26er | duflu, so who is going to work on bug 1240833 ? | 09:25 |
| ubot5 | bug 1240833 in Mir "[feature] Expose at least one non-alpha pixel format for Nexus 4" [Medium,Triaged] https://launchpad.net/bugs/1240833 | 09:25 |
| om26er | Kevin ? | 09:25 |
| duflu | om26er: Don't know. But it's next cycle :( | 09:26 |
| om26er | duflu, next cycle starts in a few days ;) | 09:27 |
| om26er | well actually tomorrow :p | 09:27 |
| duflu | om26er: Hah. Yeah fair point. Still don't know. It's a simple concept, but potentially tricky to implement | 09:27 |
| === pete-woods-brb is now known as pete-woods | ||
| om26er | tvoss, I don't think video camera are able to capture the lag. I have been trying to record a few videos but none seems to show the problem. perhaps I need a better camera | 10:08 |
| tvoss | om26er, ack | 10:08 |
| davmor2 | om26er: what's the issue I have a pretty good camera I can setup | 10:24 |
| om26er | davmor2, on Mir open contacts app with ~50 contacts, try flick from bottom towards top and see if the scrolling lags. try the same on SF. make a video for both | 10:25 |
| om26er | its even more visible in the webbrowser.. in sites like omgubuntu or facebook | 10:26 |
| davmor2 | om26er: I was going to say open planet.ubuntu.com and you get it | 10:26 |
| om26er | yeah | 10:26 |
| davmor2 | tvoss: ^ this is what I said yesterday, If you open planet.ubuntu.com on a maguro because of the length of the site page you can really see the glitchy effect on mir. Not so much lag for me more that is seems to bounce forever and a day | 10:28 |
| tvoss | davmor2, again, maguro is not really the reference here, but I will look at it as soon as I have some time on my hands | 10:28 |
| om26er | davmor2, confirm this bug 1240841 | 10:29 |
| ubot5 | bug 1240841 in mir (Ubuntu) "[Mir]In-App scrolling is lagging much" [High,New] https://launchpad.net/bugs/1240841 | 10:29 |
| tvoss | davmor2, until then, please make sure that we have bugs logged with as much information as possible | 10:29 |
| om26er | I see that on mako Sir! | 10:29 |
| tvoss | om26er, sure. One other thing: *much* is not really helpful, either we have hard numbers to quantify the slowdown, or it lags. I would rather model qualitative attributes in the bug importance | 10:30 |
| tvoss | davmor2, om26er that being said: bug reports with attached videos or as usual, detailed steps to reproduce would help the most | 10:30 |
| om26er | ok, we'll improve the title and attach a video if I get my hands on a better camera | 10:31 |
| davmor2 | tvoss: I can video the glitch effect I'll add it to the bug, I'll give you a ping once it is done | 10:32 |
| tvoss | davmor2, thx | 10:33 |
| tvoss | om26er, thx | 10:33 |
| ogra_ | tvoss, i find it funny that maguro isnt really the reference anymore since we were told we need to focus exactly on this device class | 10:33 |
| ogra_ | instead of the beefy arch | 10:33 |
| ogra_ | (though that seems to have shifted a little) | 10:34 |
| tvoss | ogra_, fair point, and we will get to optimizing for it, too. However, the PowerVR SGX 540 is *known* to be full of issues, and we don't have drivers with proper hardware compositor support for it | 10:34 |
| tvoss | ogra_, that's the main reason it does not benefit as much of the performance improvements | 10:34 |
| ogra_ | yeah, i understand whats the issue indeed | 10:35 |
| mlankhorst | everything powervr has issues :P | 10:35 |
| * ogra_ fights with PVR since nearly 4 years already :) | 10:35 | |
| tvoss | mlankhorst, but there are particular bad chips in that series ;) | 10:35 |
| ogra_ | maguro is just a different pandaboard ;) | 10:35 |
| tvoss | mlankhorst, ogra_ specifically, touching the fb stalls rendering pipelines and rendering contexts in wild and wonderful ways | 10:36 |
| tvoss | ogra_, that's one of the reasons just catting the fb can lead to "interesting" behavior on maguro | 10:36 |
| tvoss | ogra_, but yes, I'm talking in technical terms here. In general I do agree that we should not only consider super-phones | 10:37 |
| ogra_ | theyshould be second focus instead | 10:40 |
| davmor2 | tvoss: video added to bug | 10:52 |
| tvoss | davmor2, +1, thx | 10:52 |
| davmor2 | om26er: can you confirm that is what you see too | 10:52 |
| davmor2 | tvoss: is that alright for you? | 10:54 |
| tvoss | davmor2, yup, helps a lot, thx | 10:57 |
| davmor2 | tvoss: same thing happens on contacts as with the slow scroll on the browser page you get that bouncy glitchy effect | 10:59 |
| tvoss | davmor2, ack | 10:59 |
| davmor2 | tvoss: the only really odd thing if you do the same scroll in unity8 itself you don't get the glitch it's nice and smooth :) | 11:07 |
| om26er | davmor2, try opeing three apps and scroll in unity then ;) | 11:08 |
| tvoss | davmor2, that's indeed interesting | 11:08 |
| tvoss | om26er, please add that information to the bug report | 11:08 |
| om26er | davmor2, yeah, I can confirm your video | 11:08 |
| om26er | tvoss, ok | 11:08 |
| davmor2 | om26er: I've confirmed the bug then now I know it is the same thing :) | 11:09 |
| om26er | davmor2, btw opening omgubuntu.co.uk is also an easy way to reproduce that bug. since that a mobile optimized app | 11:11 |
| davmor2 | om26er, tvoss: I'm assuming that the slow scroll in unity8 with apps open is mostly just down to lack of memory so it's possibly hitting the swap | 11:11 |
| tvoss | davmor2, might well be. However, we have optimization potential in Mir, too | 11:11 |
| om26er | davmor2, memory is not much of a problem on mako. its because the apps that are running in the background are still being rendered by Mir | 11:11 |
| om26er | davmor2, bug 1227739 | 11:11 |
| ubot5 | bug 1227739 in unity-mir "Mir continues to render background application surfaces even when they're not visible" [High,Triaged] https://launchpad.net/bugs/1227739 | 11:11 |
| tvoss | om26er, only for a certain amount of time, after that, the processes are sigstopped | 11:12 |
| davmor2 | om26er: right yeah I see it when you open an app and you get that initial stall sometimes and another app appears till the new one is fully loaded | 11:12 |
| === alan_g is now known as alan_g|lunch | ||
| lool | Hey folks | 12:40 |
| lool | wanted to ask, is there some kind of xvfb for mir? some kind of fake mir backend in memory | 12:41 |
| lool | no specific GPU connected | 12:41 |
| alf_ | lool: no, we do have a dummy display backend in the tests (no drawing done at all) | 12:43 |
| alf_ | lool: why do you need the memory backend? | 12:43 |
| alf_ | lool: also see https://bugs.launchpad.net/mir/+bug/1118903 | 12:45 |
| ubot5 | Ubuntu bug 1118903 in Mir "[feature] Mir lacks a software rendering backend" [High,Triaged] | 12:45 |
| lool | alf_: something inbetween emulator virtual machine, and real hardware basically | 12:46 |
| lool | alf_: I think this is indeed related; thanks for the pointer | 12:47 |
| lool | alf_: I guess there is probably a fake fb driver we could use with this support for fbdev | 12:48 |
| lool | I'll check with kgunn how far this is in the mir roadmap | 12:48 |
| lool | (with other work such as performance work upcoming) | 12:48 |
| kgunn | lool: why the query ? e.g. what's your proposed need ? | 12:57 |
| lool | kgunn: I'm chatting with vila on evolutions of CI stuff, and this came up as one of the things that might help running some of the tests on vms | 13:02 |
| lool | kgunn: So was just tring to get status | 13:02 |
| lool | kgunn: maybe we will need this sooner rather than later, depends how far this is | 13:03 |
| === alan_g|lunch is now known as alan_g | ||
| kgunn | lool: ok, right now its nowhere (...unless duflu has been sneaky and spent time on it) | 13:03 |
| lool | kgunn: Ok; thanks | 13:04 |
| kgunn | lool: but thanks for this...i will | 13:04 |
| kgunn | make sure to create a bp for some general mir testability items (this is 1 of handful) | 13:04 |
| alf_ | lool: don't the VMs we have support KMS/DRM? | 13:04 |
| kgunn | alf_: true...but, isn't the fb is just a phoney...its really a sw fb that gets redirected to a window right? | 13:05 |
| kgunn | alf_: oh i get your point | 13:05 |
| kgunn | alf_: you might use a sw buffer as fb, but that doesn't mean there is no fb | 13:06 |
| kgunn | oops, meant gpu... | 13:06 |
| kgunn | you might use a sw buffer as fb, but that doesn't mean there is no gpu | 13:06 |
| === pete-woods is now known as pete-woods-brb | ||
| lool | alf_: I'm not sure; I think where there are cases where we dont want this relayed to real hardware, but rather have fake fbs | 13:13 |
| alf_ | lool: do you mean the final display, or the rendering? | 13:14 |
| lool | alf_: I guess it depends; on one side we want to exercize Mir itself, on the other side sometimes we just want a solid hardware independent output for higher level tests which are not dependent on GPU specific behaviors | 13:16 |
| lool | Perhaps something we might want to do for instance is simulating cloning or extending of displays, or rotating the screen | 13:16 |
| lool | or different DPIs | 13:17 |
| alf_ | lool: (if it's just for the final display, we could just draw to an off-screen buffer instead of the real framebuffer) | 13:17 |
| tvoss | lool, so you want a vesa backend? | 13:17 |
| alf_ | lool: so ideally you want a pure software pipeline, e.g. what the bug describes | 13:17 |
| alf_ | lool: GPU not involved in neither display nor rendering | 13:18 |
| lool | alf_: Yes, in regular memory buffers is what I had in mind rather than real framebuffer | 13:18 |
| lool | much like Xvfb | 13:18 |
| lool | tvoss: vesa still goes to hardware via bios? | 13:18 |
| lool | alf_: yes pure software | 13:18 |
| lool | alf_: exactly | 13:18 |
| alf_ | lool: the rendering part may be a bit tricky, but we could probably just use mesa software rendering for this | 13:19 |
| alf_ | lool: btw, I am not sure that xvfb doesn't use the GPU at all, I think it does so for rendering | 13:22 |
| alf_ | lool: perhaps you just want mir in an X window? :) | 13:22 |
| lool | alf_: Actually I care to be able to say "Run these commands that would usually output things to a real screen on a fake screen and let me be able to poke at it" | 13:27 |
| lool | alf_: typically, take screenshots, get events about what's going on, influence it | 13:27 |
| lool | alf_: e.g. did the display output get "turned off" | 13:27 |
| tvoss | lool, so you want a state-observable mock? I think that's best done in the project-internal tests | 13:28 |
| lool | alf_: the main use case is running tests in a reproducible manner and simulating / listening to events; e.g. I can run a "rotate unity8" test on intel or nvidia hardware without testing the intel and nvidia specific behaviors, and then do integration testing on real hardware | 13:28 |
| lool | tvoss: but right now when we're actually displaying something it goes to real hardware and might behave differently on this or that hardware | 13:29 |
| lool | also, hardware sucks | 13:29 |
| lool | if you see what I mean | 13:29 |
| lool | we'll always need testing on real GPUs | 13:29 |
| lool | but if we could run most of the pre-integration test steps in vms / reproducible + controlled environments, that would be more reliable, scalable | 13:30 |
| tvoss | lool, sure, I'm not argueing against your point, only saying that I think what you want is a mockable and obversable backend, as independent of HW as possible | 13:30 |
| tvoss | lool, what are preintegration tests from your pov? | 13:30 |
| lool | tvoss: Ah Mir backend, yes | 13:30 |
| lool | tvoss: typically testsuites of our components | 13:30 |
| lool | one class is unity8 itself, another class is anything running in unity8 | 13:31 |
| lool | but in all cases, we're rarely writing GPU specific code and we could run all tests first on a virtual backend, then on a GPU in the last integration steps | 13:32 |
| tvoss | as in-process? | 13:32 |
| lool | hmm not sure | 13:32 |
| tvoss | lool, sure, we would need graphics drivers for the vm's then | 13:32 |
| lool | Frankly, I dont fully grasp how the technical implementation would look like yet :-) | 13:32 |
| lool | but in the end, I feel I shoudl be able to land an unity8 change by running the tests on a reproducible / fast / scalable environment before I even try it on a real GPU | 13:33 |
| lool | with more tooling too | 13:33 |
| lool | like, rotating the screen | 13:33 |
| tvoss | lool, so what we would need are graphics drivers for the virtual machines we want to consider | 13:34 |
| tvoss | lool, those drivers typically allow for injecting events like "rotate screen", too | 13:34 |
| lool | tvoss: hmmm | 13:36 |
| lool | tvoss: virtual machine we are working on | 13:36 |
| lool | goldfish | 13:36 |
| lool | but it has GL passthrough | 13:36 |
| lool | so it's not really hardware independnet | 13:36 |
| lool | also, vms are a bit heavy | 13:36 |
| lool | when you compare to Xvfb | 13:37 |
| tvoss | lool, xvfb is not hardware independent either | 13:37 |
| lool | is it not? | 13:37 |
| lool | how so? | 13:37 |
| lool | I thought it was creating a fake in memory surface; that it worked without a hardware GPU | 13:38 |
| tvoss | well, it depends | 13:38 |
| tvoss | however, I do not see the advantage of a "pure" software solution in small-scale integration testing. What we have right now is a way to run Mir without real-hw backend in integratoin and acceptance testing scenarios. Unity (or unity-mir) could use that knob, too | 13:40 |
| lool | tvoss: can we take screenshots from it? | 13:40 |
| lool | I guess we could live without screenshots | 13:41 |
| tvoss | lool, nope, it's state observable though | 13:41 |
| tvoss | lool, that's what we use to mock out things for our CI runs | 13:41 |
| lool | maybe fake non-rendering backend + goldfish are enough to cover our needs | 13:41 |
| lool | the xvfb like solutoin would be a bit in between I guess | 13:41 |
| lool | where's the fake non-rendering backend? I looked into mir/src/server/graphics/ but I'm not sure I can tell how it's named | 13:44 |
| tvoss | lool, searching | 13:46 |
| alf_ | lool: tvoss: there no dedicated "null" backend at the moment, it's just dummy classes inside our test framework (e.g. see in tests/mir_test_framework/testing_server_options.cpp) | 13:48 |
| lool | ok | 13:50 |
| kgunn | alan_g: alf_ anyone?....https://code.launchpad.net/~mir-team/mir/development-branch/+merge/191652 | 14:36 |
| alan_g | kgunn: looking | 14:37 |
| alf_ | alan_g: is this going into a phone release? | 14:38 |
| alf_ | kgunn: ^^ | 14:38 |
| kgunn | alf_: alan_g nope, won't make phone release | 14:38 |
| * alan_g thought so | 14:38 | |
| alf_ | kgunn: so, when are we going to be working directly on trunk again? | 14:39 |
| kgunn | alf_: i spoke to didrocks about it, and seems the api control we have in place is working good... | 14:41 |
| kgunn | alf_: so until we get our api distilled down | 14:41 |
| kgunn | alf_: we'll have to stay on the dev branch | 14:41 |
| alf_ | :/ | 14:42 |
| kgunn | alf_: what's the complaint besides speed (of which...i am probably 1/2 that problem :) | 14:42 |
| === pete-woods-brb is now known as pete-woods | ||
| alan_g | kgunn: the problem is tracking the source of problems - think about "bisecting" trunk changes | 14:45 |
| kgunn | alan_g: yeah...true | 14:45 |
| kgunn | racarr: can you resume the api distillation activity ?? ^ this will help us return to trunk | 14:46 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g|tea | ||
| alf_ | alan_g|tea: that was a quick lunch ;) | 14:47 |
| alf_ | kgunn: I think our API will begin to stabilize only after the scenegraph/model rework | 14:47 |
| kgunn | alf_: that makes a lot of sense....so really, should we just forego the distillation process with what we have today & prioritize the scenegraph work ? | 14:49 |
| kgunn | alf_: altho...doing some gross distillation wouldn't hurt | 14:49 |
| kgunn | we could bump api/abi slightly less | 14:49 |
| kgunn | today i see a header in include/server....by technical rights...i need to bump (even tho i know the likelihood is really low) | 14:50 |
| kgunn | i suppose tackling scenegraph will depend on greyback's availability ....and i know he may be sidelined for about 3 weeks doing the right-edge navigation proto | 14:51 |
| kgunn | greyback: could someone else do the proto ? | 14:51 |
| kgunn | albert maybe ? | 14:51 |
| === alan_g|tea is now known as alan_g | ||
| alf_ | kgunn: I think that the upcoming changes will drastically alter what we expose to the shell, so much of the distillation work will be wasted. We also need to decide what privatization scheme we are going to use. | 14:55 |
| alan_g | ^ +1 | 14:55 |
| kgunn | alf_: "which scheme"....can you elaborate ? i'm kind of simple minded...i was thinking you got abunch of headers wit pv func's and some needed enums/structs in them | 14:56 |
| alf_ | kgunn: I am referring to the discussion in the the "privatize" MP series email thread | 14:57 |
| kgunn | btw, gonna miss stand up..i have to sit in for olli at some meeting | 14:57 |
| kgunn | alf_: ah...again, am i missing something ? but isn't it a rather simple argument to conclude which directories (feel free to educate me) | 14:58 |
| * kgunn realizes there were some responses to my mail...i meant to go back and read :) | 14:58 | |
| === dandrader_ is now known as dandrader|afk | ||
| greyback | an accidental "make -j44" brought my machine to its knees | 15:12 |
| greyback | kgunn: fastest way to do the prototype is probably to use the app-screenshot hack we're using for app switching. Disadvantage of that is previews will not be live. But that task will require the screenshot-save-to-disk work we need anyway | 15:16 |
| greyback | kgunn: yes someone else could certainly take that on | 15:17 |
| greyback | kgunn: that prototype could be educated to use live previews when available, as the scenegraph task progresses a bit | 15:18 |
| greyback | kgunn: I need to write up a doc with what scenegraph works I think needs to be done, and what I think Mir might need. I need to spend time understanding how the two can work together tho | 15:19 |
| * greyback quite needy at the moment :) | 15:19 | |
| greyback | I'll also need a volunteer from the Mir team who is happy to discuss the Mir-side compositor with me, to explain hardware compositing drawbacks to me, and so I can bounce ideas off | 15:22 |
| === dandrader|afk is now known as dandrader | ||
| kdub | greyback, i might be able to help there | 15:26 |
| greyback | kdub: great, thanks! Prepare for a barrage of idiotic questions and sky-high ideas :D | 15:29 |
| kdub | :D | 15:29 |
| alf_ | greyback: 'make -j' is also fun :) | 15:33 |
| greyback | alf_: that it is, but for some reason my Ctrl+C reflex kicks in for that immediately.. :) | 15:34 |
| kgunn | greyback: was busy, and thanks for the responses....great minds think alike....i wanted to ask you to write up some thots....maybe you and kdub (and whomever else) could spend some quality time early next week on it | 15:51 |
| greyback | kgunn: sure | 15:52 |
| === jfunk is now known as jfunk-afk | ||
| greyback | kdub: as a first question, I'd like to learn more about what various hardware compositors can do, just to get a grip on the basics. Would you know of any docs that I could start out on? | 16:28 |
| kdub | docs, not really | 16:29 |
| greyback | kdub: even an API of some hardware compositor would give me something. I've found a little on the hardware compositor in the raspberry pi, but mot much | 16:30 |
| kdub | oh, let me point to the api | 16:30 |
| kdub | greyback, https://android.googlesource.com/platform/hardware/libhardware/+/android-4.3.1_r1/include/hardware/hwcomposer.h | 16:31 |
| greyback | kdub: are there similar for nvidia/intel/amd chips? Or is it quite chip specific? | 16:32 |
| kdub | the whirlwind tour is that you can set various transforms you want to do in composition (basic ones) certain alpha modes, 90-degree rotation, cropping, blits, scaling | 16:33 |
| kdub | then you ask the hardware, and it tells you 'i can do that' or 'i can't' | 16:33 |
| kdub | if the hardware can't do it, you have to do that in opengl | 16:33 |
| kdub | greyback, only talking about android at the moment | 16:33 |
| greyback | kdub: sure, I'm just thinking about desktop further down the road | 16:34 |
| kdub | right, with desktop... i think? there's just the cursor that's an overlay | 16:35 |
| kdub | alf_, is that right, or wrong? :) | 16:35 |
| alf_ | kdub: KMS has the concept of planes (=hardware overlay), but we are not using them at the moment, not even sure how well they are actually supported by the drivers | 16:36 |
| kdub | oh yeah... i don't hear about them very often, i'd guess the support is hit-or-miss | 16:37 |
| greyback | so sounds like there's little to no hardware compositing abilities on desktop chips | 16:38 |
| kdub | i guess.... i mean, there are some different tricks we might want to try | 16:39 |
| kdub | like, composition happens on the 2nd gpu core (for laptops with an integrated and discrete core) | 16:39 |
| greyback | cool | 16:39 |
| * greyback eod | 16:47 | |
| === dandrader is now known as dandrader|lunch | ||
| w-flo | are there any known issues with mir and android hwc11 (whatever that is)? mir 0.14 used to work after some patching, mir 0.15 crashes in hwcomposer.so after a call from mir in commit_frame() in HWC11Device. Now I'm wondering if the special qcom/display for my phone is broken, or if there's something wrong with mir 0.15 and "hwc11" :) | 17:03 |
| kdub | uhoh | 17:04 |
| kdub | nexus 4? | 17:04 |
| w-flo | nope | 17:04 |
| w-flo | HTC Desire Z | 17:04 |
| w-flo | nexus4 uses that hwc11 code, too? then it must be something in the hwcomposer code for my phone I guess... | 17:05 |
| kdub | w-flo, haven't tried it... but i am doing improvements around that area currently | 17:05 |
| kdub | i'd expect them to be different | 17:06 |
| kdub | but is there a backtrace or something? might be a difficult issue to debug w/o a device though | 17:06 |
| w-flo | kdub, http://pastebin.ubuntu.com/6252062/ is the backtrace. The code for libhwcomposer is not the same as in ubuntu/cyanogenmod, so no need to fix anything :) | 17:08 |
| kdub | w-flo, still would be good to fix... maybe i'll have a branch or two to try over the next week (or two :) ) | 17:09 |
| kdub | i'll keep you posted | 17:09 |
| === alan_g is now known as alan_g|EOD | ||
| w-flo | kdub, well, don't waste your time with it. might be a bug in the inofficial cyanogenmod port for the device, this is the repo: https://github.com/Andromadus/android_hardware_qcom_display/blob/cm10.1/libhwcomposer/hwc.cpp | 17:11 |
| w-flo | anyway, thanks a lot kdub, I'll let you know if I get it to work somehow :) | 17:11 |
| tvoss | kdub, hey there :) happy release day | 17:39 |
| kdub | happy release day tvoss :D | 17:39 |
| * kdub start refactoring | 17:41 | |
| tvoss | kdub, thanks :) so I commented on the uevent spam bug | 17:41 |
| tvoss | kdub, seems like we miss a call to the android poewr HAL that is a no-op on mako, but should help on maguro | 17:41 |
| tvoss | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743/comments/37 | 17:41 |
| ubot5 | Ubuntu bug 1234743 in systemd (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [High,Fix committed] | 17:41 |
| kdub | ah, hmm | 17:42 |
| kdub | okay, i guess we should add that hal to mir | 17:43 |
| kdub | we can add that to a bp somewhere | 17:45 |
| tvoss | kdub, yup :) kgunn, can you help here? | 17:47 |
| tvoss | not sure which bp is approprate | 17:47 |
| kgunn | alan_g|EOD: dang...i did not realize you were unavailable...but the sprint timing was kind of tied to strehl's team as well | 18:01 |
| kgunn | alan_g|EOD: that ended up being a really good week for his team too | 18:01 |
| === dandrader|lunch is now known as dandrader | ||
| racarr | Lonnnn....don? | 18:21 |
| racarr | I'm glad we are getting an architecture sprint even if it's going to be cold | 18:21 |
| ogra_ | could be worse ... | 18:22 |
| ogra_ | oslo in january for example | 18:22 |
| kgunn | alan_g|EOD: i'm gonna poke strehel and see if we could change to that nov 18-22 week...but i'm doubting it | 18:25 |
| racarr | kgunn: *deep breath and exhale* I guess I should go back to ABI now? | 18:36 |
| kgunn | racarr: so alf_ and i discussed earlier....he was suggesting that changes may come wrt api/abi from scenegraph as well ...he was thinking drastic | 18:38 |
| kgunn | racarr: question is how long that may take, and even if that's the case i was wondering...isn't some | 18:39 |
| kgunn | kgunn: kind of coarse api distillation still useful ? (e.g. at least limit the number of headers out there in public) | 18:39 |
| racarr | hmm | 18:39 |
| racarr | yes that's true. wrt scenegraph | 18:40 |
| racarr | kgunn: Ok I guess, so let's actually split the issue in to two | 18:40 |
| kgunn | racarr: in other words, alf_ was sort of questioning whether its worth distilling the api right now priori to that | 18:40 |
| racarr | 1. ABI is hard to maintain. 2. API is hard to maintain | 18:40 |
| kgunn | racarr: whereas i was thinking...some effort would be good | 18:40 |
| kgunn | racarr: yep | 18:40 |
| racarr | the ABI is hard to maintain because we have unity8 using concrete classes, and the sheer number of things we expose (which could be internal) | 18:41 |
| racarr | the API is hard to maintain, because of it's shape, i.e. the way we require unity8 to implement many many interfaces | 18:41 |
| racarr | hmm | 18:43 |
| racarr | alf may be right depending on when we really | 18:43 |
| racarr | crack down on the scene graph | 18:43 |
| kgunn | racarr: right, i'd like to dive in and try to make headway asap, i think greyback is going to spend some time working with kudb and you to put toghether a vision of what really needs to get done to incorporate qtscenegraph | 18:46 |
| racarr | ok yeah my thoughts kind of trailed off this way... | 18:46 |
| racarr | we really need to think about that | 18:46 |
| racarr | I think maybe | 18:46 |
| racarr | I need to do a deeper dive in to Qt/QML | 18:47 |
| greyback | racarr: if you have a little patience, I'll write up a doc explaining the internal workings of the Qt SG | 18:47 |
| greyback | as that's pretty important for you guys to have a decent understanding of, before we get anywhere | 18:48 |
| racarr | Ok. | 18:48 |
| kgunn | ug...i everytime i start thinking about it then i think...oh crap, we're gonna need parent-child relations, modality....calgon take me away | 18:48 |
| greyback | washing machines live longer with..calgon. *bing* | 18:49 |
| greyback | Now I remember why I don't have a TV | 18:49 |
| racarr | I feel like I need to understand the QML side more perhaps though... | 18:49 |
| racarr | because I still don't understand the objective outside of | 18:49 |
| racarr | tautologically, i.e. "use the QT scene graph" | 18:49 |
| * kgunn now on a mission to over-use the word tautologically | 18:50 | |
| greyback | racarr: the benefit for us is to be able to position/size and apply transformations/rotations to Mir's surfaces using QML's syntax | 18:50 |
| greyback | racarr: that then means we can easily animate too | 18:51 |
| greyback | racarr: so ideally a mir surface will be a Surface{} type, with properties like a Rectangle{} | 18:51 |
| racarr | greyback: This is what I don't understand though | 18:51 |
| racarr | can't a surface be a Surface{} type and have properties like | 18:52 |
| racarr | width and height and support transformations and such | 18:52 |
| racarr | and even be a QQuickItem (we reach the boundaries of me knowing what I am talking about) | 18:52 |
| greyback | for simple properties yes | 18:52 |
| racarr | and does Qt "scene graph" even have to be | 18:52 |
| racarr | part of that? | 18:52 |
| greyback | but transformations and clipping can depend on their parent's transformations & clipping | 18:53 |
| kgunn | racarr: i think part of the point is....something on the qt/qml side will need that just for the qml portion to "talk" in those terms | 18:53 |
| kgunn | before it "knows" about mir | 18:54 |
| racarr | greyback: That's true | 18:54 |
| racarr | Isn't it kind of a small number of things though? | 18:54 |
| greyback | racarr: so what I need to determine is if I can calculate the total transformation | 18:54 |
| greyback | and clipping | 18:55 |
| greyback | it could be, but during a complex animation like the proposed right-edge swipe to show all windows animation, it could also be non-trivial | 18:55 |
| racarr | ? | 18:55 |
| racarr | I lost a thread | 18:55 |
| racarr | hmm, yes I mean there can be a lot of stuff going on | 18:56 |
| racarr | but it's a quite simple language of stuff | 18:56 |
| racarr | there are items that can be rendered, they have transformations, clips, shaders, a few visual properties (width, height, opacity, position, etc...) | 18:56 |
| greyback | we can also write shaders in qml to appy to elements, but yeah, that's a good chunk of the list | 18:57 |
| racarr | My thought is that improving the mir data model to support the needed things (like parent child relationships with cumulative transformations) | 18:58 |
| racarr | and then binding that out to QML | 18:58 |
| racarr | is going to be much easier and more fruitful than trying to change the mir data model to be the Qt scene graph | 18:58 |
| racarr | + the whole rendering set of questions | 18:58 |
| greyback | That's not what I am asking for | 18:58 |
| racarr | ? | 18:59 |
| greyback | I want to give Mir a list of surfaces, plus their transforamtions, positions etc | 19:00 |
| greyback | I just need Mir to support the surface properties that QML will demand | 19:00 |
| greyback | then Mir can composite away | 19:01 |
| racarr | *can sort of see it* | 19:02 |
| racarr | I still have some concern over thinking about it like "want to give mir a list of surfaces though" | 19:02 |
| greyback | On the QML side, I want to be able to manipulate a QQuickItem, which represents a mirsurface. Then I want to be able to extract the correct information about that QQuichItem from the scenegraph to give to mir | 19:02 |
| racarr | because if you are always giving mir a list of surfaces, then you are the mir data model, it's just you are protected by a cache that you atomically update | 19:02 |
| racarr | so then you have to worry about synchronization between what you have and everything | 19:03 |
| racarr | on the other side | 19:03 |
| greyback | What will be in Qt/QML will only represent the Mir surface. Qt won't be owning it, Mir will | 19:03 |
| racarr | Ok so it's more like an adapter scene graph | 19:04 |
| greyback | so let me rephrase, I want to set all the properties of Mir's list of surfaces | 19:04 |
| racarr | XD | 19:05 |
| racarr | Ok now we are getting somewhere | 19:05 |
| greyback | but there are things I am worried about with this approach. | 19:05 |
| greyback | One is, I'd like to draw a window shadow in QML. I can do that by surrounding the Surface{} element with something which draws the shadow - so Qt draws the shadow | 19:06 |
| racarr | one thing that concerns me slightly is your ability to just like | 19:06 |
| racarr | right | 19:06 |
| greyback | but if a partly-transparent window is above another window with a shadow, how can I draw the "covered" shadows? | 19:07 |
| racarr | I thinkkkk | 19:08 |
| kgunn | meaning shadow (of the underneath) blended with the window on top | 19:08 |
| kgunn | right | 19:08 |
| racarr | ok so the most immediately correct, but | 19:08 |
| greyback | yep | 19:08 |
| racarr | obviously not satisfactory solution | 19:08 |
| greyback | same with window decorations | 19:08 |
| racarr | is | 19:09 |
| racarr | that creating this element around the Surface{} element | 19:09 |
| racarr | makes a new 'surface' (let's call this new thing, a layer actually, and say that a surface is also a layer) | 19:09 |
| racarr | and it gets rendered by QML, then the compositor composites it, etc | 19:09 |
| racarr | but this is way too horribly | 19:09 |
| racarr | ineffecient | 19:09 |
| greyback | right, so now Qt is rendering an extra surface for every non-opaque mir surface | 19:09 |
| racarr | i.e. a full window sized buffer which is mostly empty for each shadow | 19:09 |
| greyback | which it can probably do... but yeah | 19:10 |
| racarr | right, it's no good. | 19:10 |
| racarr | so, if we could trick QML in to sharing OpenGL contexts in a friendly fashion | 19:10 |
| greyback | oh | 19:10 |
| racarr | we could do this without the memory overhead right, i.e. the 'layer' | 19:10 |
| racarr | isnt backed by a memory buffer | 19:11 |
| greyback | that could be do-able | 19:11 |
| racarr | and we just have QML draw in | 19:11 |
| racarr | the compositors context | 19:11 |
| greyback | interesting | 19:11 |
| racarr | i.e. mir invokes layer->render() | 19:11 |
| racarr | and layer is a MirQMLQtQuickAdapterBridgePRoxyItem | 19:11 |
| racarr | :p | 19:11 |
| greyback | lol | 19:11 |
| greyback | but that is an idea | 19:11 |
| racarr | I think this would be pretty cool, but I knwo people looked at sharing the opengl contexts in the past and it was deemed | 19:11 |
| racarr | non trivial but maybe with the new | 19:12 |
| racarr | renderer | 19:12 |
| racarr | it's a more reasonable task | 19:12 |
| racarr | or maybe it's just, a non trivial task that we should undertake | 19:12 |
| racarr | I think if we can share opengl contexts, like that, this all becomes way easier | 19:12 |
| greyback | people do this when mixing qml with things like vtk and other viz toolkits. Qt even addded api in 5.2 to let it reset its own context so it can continue | 19:12 |
| racarr | ok | 19:12 |
| racarr | I have a feeling we can probably make this approach work then. | 19:13 |
| greyback | me too | 19:13 |
| racarr | the other idea I had is that with things like | 19:13 |
| racarr | shadows, etc. | 19:13 |
| greyback | that works around one of my main concerns | 19:13 |
| racarr | you could probably use some sort of accumulation buffer and | 19:13 |
| racarr | a front to back | 19:13 |
| racarr | rendering trick... | 19:13 |
| racarr | and just always QML draws on top | 19:13 |
| racarr | but I dunno | 19:13 |
| racarr | lol | 19:13 |
| greyback | I prefer the first idea :) | 19:13 |
| greyback | well, every idea is worth thinking about before dismissing anyway | 19:14 |
| racarr | yeah, first idea is way better. XD | 19:14 |
| greyback | yep | 19:15 |
| racarr | um...hmm, yeah, I feel better about this. | 19:15 |
| racarr | one thing I don't understand is how | 19:15 |
| racarr | like, this idea that when you surround the Surface{} element with a ShadowBox{} element | 19:15 |
| kgunn | greyback: racarr so i think i follow in the shadow example...you avoid creating another seperate surface...but the original underneath window(surface) would need to be larger thatn it thinks right? in order to accomodate the extra shadow content | 19:15 |
| racarr | kgunn: No, the shadow will be drawn during compositing | 19:15 |
| racarr | directly on to the framebuffer | 19:15 |
| racarr | or whatever buffer you are compositing too I guess | 19:15 |
| racarr | greyback: What...um... | 19:16 |
| racarr | greyback: I need to understand what the C++ side of QML looks like more I guess | 19:16 |
| racarr | I don't understand how the actual mechanism will line up here, but it can't be too bad. | 19:16 |
| greyback | racarr: start with QQuickItem then, as that represents the Item{} type | 19:16 |
| greyback | qtdeclarative/src/quick/items/ in the qt5 source tree | 19:17 |
| racarr | ok | 19:17 |
| racarr | this still isn't ideal from a rendering perspective :( | 19:17 |
| racarr | ideally the window and it's shadow would be part of the same | 19:17 |
| greyback | qtdeclarative/src/quick/scenegraph/ for renderer | 19:17 |
| racarr | larger than window size buffer | 19:17 |
| racarr | like kgunn is talking about | 19:17 |
| racarr | so that you can still use | 19:18 |
| racarr | hardware composer/overlays | 19:18 |
| racarr | well, you can still use sommmme overlays this way | 19:18 |
| racarr | but not full out hardware composition | 19:18 |
| greyback | for shadows/window decoration, why care about hardware compositing/overlay? They don't change much | 19:18 |
| racarr | which is probably fine because on mobile we don't have most of these things all the time | 19:18 |
| racarr | greyback: But I mean, as soon as one window has a shadow | 19:19 |
| racarr | then we have tos witch to drawing the whole framebuffer with GL | 19:19 |
| greyback | gotcha | 19:19 |
| racarr | instead of using the hardware compositor | 19:19 |
| greyback | well we'll have shadows only on desktop (maybe) | 19:19 |
| racarr | but, I guess on mobile this is really only the path for when effects are happening | 19:19 |
| racarr | and stuff | 19:19 |
| racarr | right | 19:19 |
| racarr | and on desktop | 19:19 |
| greyback | in which case, only overlays really, right? | 19:19 |
| racarr | ...*shrug* | 19:19 |
| racarr | yeah. I guess. we can still use some kinds of video overlays, etc | 19:20 |
| racarr | and it should be fine | 19:20 |
| racarr | not sure we even care that much on desktop | 19:20 |
| greyback | I don't want to add shadows to all Mir surfaces, as then every mir surface is not opaque, so compositing will not be that efficient | 19:20 |
| greyback | and I like this approach as then we'd have server side decoration, and Mir wouldn't have to care about it | 19:21 |
| racarr | its going to be really hard | 19:22 |
| racarr | to squeeze the last drops | 19:22 |
| racarr | of effeciency out this way... | 19:22 |
| racarr | thinking like. | 19:22 |
| racarr | well, our ideal shadow rendering path | 19:22 |
| racarr | is probably | 19:22 |
| racarr | the window texture, is the same size as the window | 19:22 |
| racarr | and it's drawn on a slightly larger than normal quad | 19:23 |
| racarr | and a shader | 19:23 |
| racarr | procedurally draws the shadow/places the window texture in the center of the quad | 19:23 |
| racarr | but all of a sudden the shadow is no no longer a qt item in the scene graph with nice properties, etc...all the details are hidden inside the shader | 19:24 |
| racarr | not sure about how to express those sorts of things... | 19:24 |
| greyback | which would be a pity, but not end of world either. It's a optimization... | 19:24 |
| === dandrader is now known as dandrader|afk | ||
| racarr | yes | 19:25 |
| racarr | there are some appealing optimizations though | 19:26 |
| racarr | like in the case of a desktop with a few non transformed windows | 19:26 |
| racarr | but, can have some things like shadows (perhaps even decorations) | 19:26 |
| greyback | well we can always create a custom QML element that could maybe encompass that? | 19:26 |
| racarr | we could get away with rendering the whole desktop in a single call out to the GPU | 19:26 |
| racarr | on a single quad | 19:27 |
| racarr | yeah. that's what I am thinking now | 19:27 |
| racarr | we can probably do it anyway | 19:27 |
| greyback | sure | 19:27 |
| racarr | we are a long way out from that I guess :p | 19:27 |
| greyback | Well when you're in the gutter, it's good to look up at the stars | 19:28 |
| racarr | greyback: Ah, in the US we say "When you're in the gutter, curl up in a ball and cry" | 19:28 |
| racarr | yours is nice too though | 19:28 |
| kgunn | racarr: greyback (distracted as usual) wrt overlay / using a shared gl context to render direct to the comp layer.... | 19:29 |
| kgunn | you would still be ok, right...i mean whatever buffer you might directly render into | 19:29 |
| kgunn | would just be an input buffer to the overlay/hwcomposer layer | 19:29 |
| tvoss | kgunn, if we are fine with compositing the main image with gles, and only use the hwc to blit to screen, correct? | 19:31 |
| * tvoss wonders if we could be clever and move the indicator surface to its own hwc layer | 19:31 | |
| kgunn | tvoss: right...and most of the overlays subsystems are driven by true 2d blitting activity (can't do 3d effect...like a shadow that you might want to do with a shader) | 19:33 |
| greyback | tvoss: we do plan to have the launcher/dash/indicators will all have their own surfaces. Think that work almost ready. So moving one to hwc layer will do-able | 19:33 |
| kgunn | tvoss: yes...very interesting idea | 19:33 |
| kgunn | android panel is exactly done this way from the main view | 19:34 |
| tvoss | racarr, greyback, kgunn ^, why don't we just move panel/indicator to its own hwc layer? with that, we could be way more aggressive in terms of composite bypassing on the main layer, too | 19:34 |
| tvoss | kgunn, yup ;) | 19:34 |
| racarr | tvoss: Ideally we could | 19:35 |
| greyback | kgunn: Yes, just want input buffer to the overlay/hwc layer. | 19:35 |
| racarr | I mean that's the thing, we could render everything in to an input buffer, then hand it off to hwcomposer | 19:35 |
| racarr | but actually in many situations mir shouldn't have to use OpenGL at all | 19:35 |
| tvoss | racarr, let's keep it simple in the beginning | 19:36 |
| tvoss | I think we will get the biggest bang for the buck with 2 or 3 hwc layers | 19:36 |
| greyback | tvoss: my lack on knowedge on hwc poking up here. Are we limited to the number of hwc layers? On desktop, I thought there were 4 | 19:36 |
| tvoss | greyback, there are definitely limits | 19:36 |
| kgunn | racarr: greyback tvoss ...no matter what, you have to keep the gl fallback 100% of the time....its concevable altho unlikely hw might not have an overlay | 19:36 |
| tvoss | greyback, but I don't know the exact number off the top of my head | 19:36 |
| greyback | kgunn: indeed | 19:36 |
| racarr | Oh definitely | 19:36 |
| racarr | you need the GL fallback, and many times need to switch | 19:37 |
| tvoss | kgunn, yup, graceful fallback has to be possible | 19:37 |
| racarr | i.e. all of a sudden there is a lot visible | 19:37 |
| racarr | or, all of a sudden we are using | 19:37 |
| racarr | the dash blur | 19:37 |
| kgunn | right...you must in the instance where you do true 3d (perspective) transitions | 19:37 |
| kgunn | right | 19:37 |
| kgunn | actually dash blur might be ok | 19:37 |
| tvoss | to me, it's just an implementation of surface, whether it is associated to an hwc layer | 19:37 |
| tvoss | +detail | 19:38 |
| tvoss | it's actually 0..* from the hwclayer perspective | 19:38 |
| kgunn | tvoss: right...i was going to say...to the android comment, its "that way" because of how they implemented the ui | 19:38 |
| racarr | tvoss: Well, the bit that is coming up though, is 'surfaces' (say layers) which are not backed | 19:38 |
| greyback | racarr: mad idea you'll probably hate, for case when the hwc says no, how about having QtSG does the whole render (i.e. grabs texture ids from Mir) itself? | 19:38 |
| racarr | by a hardware buffer, much less an HWC layer | 19:38 |
| tvoss | racarr, sure, but that should be handled by the impl without hte consumer of the surface api having to know | 19:38 |
| tvoss | greyback, valid | 19:39 |
| racarr | but instead, involve Qt rendering directly in to the compositor context | 19:39 |
| tvoss | greyback, I think we want a custom renderer for the scenegraph though | 19:39 |
| tvoss | greyback, one that knows about mir | 19:39 |
| racarr | tvoss: I know, but I am saying if rendering with OpenGL directly in to the framebuffer | 19:39 |
| tvoss | racarr, the custom qt scenegraph renderer should take over the compositor | 19:39 |
| racarr | becomes the 'common' case, i.e. say | 19:39 |
| racarr | well all the time | 19:40 |
| racarr | then you effectively lose your ability to use the HWC effectively | 19:40 |
| racarr | because you always have to composite things with GL first | 19:40 |
| tvoss | racarr, the renderer could just be clever enough, I wouldn't invest too much time in special casing | 19:40 |
| kgunn | right but we talked about this....it might need to check with some hw/overlay first | 19:41 |
| tvoss | racarr, I know what you mean, just saying that we can easily have hwc-awareness in a custom qt scenegraph renderer that we implement, too | 19:41 |
| tvoss | kgunn, yup, ^ :) | 19:41 |
| kgunn | tvoss: precisely! | 19:41 |
| === dandrader|afk is now known as dandrader | ||
| racarr | Ok but now I am confused again | 19:41 |
| kgunn | :)) | 19:41 |
| racarr | because I thought we weren't actually using Qt scene graph, and just mir was exposing things out so QML could manipulate the mir data model in terms of QQuickItems | 19:42 |
| greyback | tvoss: well that involves teaching QtSG renderer about HWC. I had expected that Mir would isolate that from me. I was more thinking: QtSG sets a bunch of properties on Mir's Surfaces. Mir sees if HWC will do it. If not, QtSG can render whole scene with GL directly to the framebuffer, so Mir's compositor doesn't have to | 19:42 |
| racarr | if not, is the Qt scene graph actually the mir data model? Or is it a copy of the mir data model. | 19:42 |
| kgunn | greyback: sure...mir could hide hwc/overlays....with an interface like "hey try this"...if it can't then you go do gl | 19:43 |
| kgunn | that's effectively what sf is doing in dorid | 19:43 |
| kgunn | or droid even | 19:43 |
| kgunn | racarr: i guess as i have been watching you guys chat & think about it....i would think it could be the mir data model (e.g. its just a common data model) | 19:45 |
| greyback | it reduces the 2 step: "Qt doing some rendering, then Mir doing compositing" into single step "Qt composites" | 19:45 |
| greyback | is idea I want to think about more tho | 19:45 |
| racarr | kgunn: But the mir data model also has all these synchronization responsibilities between other partso | 19:45 |
| racarr | of mir right | 19:45 |
| racarr | which are totally outside the scope of Qt | 19:45 |
| racarr | so I guess I have some doubts that the Qt scene graph will work as the mir data model. | 19:46 |
| kgunn | racarr: are we lumping control/execution in with data modeling ? | 19:46 |
| kgunn | ...or maybe you guys see some tightcoupling concerns i don't get | 19:46 |
| racarr | kgunn: Well, I mean only as much as you have to | 19:46 |
| racarr | execution is based on state right | 19:46 |
| kgunn | racarr: totally....and from a composition pov that should be a one way street (e.g. what is executed won't effect the state/model) | 19:47 |
| racarr | Right but we have to present different synchronized views out of the data model | 19:48 |
| racarr | i.e. one to the compositor (in this case it's a scene graph) | 19:48 |
| kgunn | well...at least the only info back is timing of avialability of the fb | 19:48 |
| racarr | one to input, one to shell surface control, one to the frontend | 19:48 |
| racarr | so the data model is kind of a larger thing | 19:49 |
| racarr | than a scene graph you see? | 19:49 |
| * kgunn reads over and over trying to see | 19:50 | |
| kgunn | racarr: i guess i see that you mean the data model might be used in a lot of diff places...but would it really be "different synch'd views"....meaning, wouldn't they all be looking at the same data model at any one instance in time ? | 19:52 |
| racarr | well, they really are different views right even if it's the same data | 19:53 |
| tvoss | greyback, will follow up tomorrow | 19:53 |
| racarr | but they need to be in synchronization, and I think our experiences so far | 19:53 |
| === tvoss is now known as tvoss|eod | ||
| racarr | with...difficulty in synchronization XD | 19:53 |
| racarr | kind of indicate that we are going to need some sort of smarter | 19:53 |
| kgunn | racarr: ok, i see what you mean by view... | 19:53 |
| racarr | data model with support for some sort of transactional idea or | 19:53 |
| racarr | well, some sort of smart synchronization, to take all the commands and control over a given frame and present | 19:54 |
| racarr | consistent views to all the consumers | 19:54 |
| kgunn | racarr: mmmm....transactions like "input available/input handle", "app surf changed", "composition run", "fb avail /vsync" | 19:55 |
| racarr | well, or maybe you need to do a series of things | 19:55 |
| racarr | atomically | 19:55 |
| racarr | i.e., get the main surface of a session and then deliver it focus | 19:56 |
| racarr | or | 19:56 |
| racarr | query things to conclude which rendering technique you need to use, or | 19:56 |
| racarr | select the targets of touch events | 19:57 |
| racarr | and, I mean, qt scene graph (for example) can select targets of touch events inside the scene graph, etc | 19:57 |
| racarr | but the rules for input dispatch inside Qt, are not the same at all as the rules for input dispatch in mir | 19:58 |
| racarr | At this point about 50% of what I am saying is nonsense though because it's just way too abstract | 19:58 |
| racarr | greyback and I are going to work on some first steps :) | 19:58 |
| kgunn | no worries...its fun to think about | 19:58 |
| racarr | Haha yesi | 20:01 |
| racarr | it's pleasant to think lofty thoughts about ideal rendering paths | 20:01 |
| racarr | after a long bit of thinking not so lofty thoughts about | 20:01 |
| racarr | autopilot tests and power buttons and launching applications | 20:01 |
| racarr | lol | 20:01 |
| racarr | and phones | 20:01 |
| racarr | I finally switched my SIM card last night :) | 20:02 |
| * greyback eod properly this time | 20:11 | |
| racarr | *waves* | 20:11 |
| racarr | kgunn: Despite the rampant confusion greyback and I had a good talk elsewhere and I think we have at least a high level plan and some first steps. | 20:12 |
| racarr | and I understand the goal now lol | 20:12 |
| kgunn | racarr: awesome | 20:13 |
| kgunn | thomi: hey...so i'm collecting work items, and i remembered at least 2 ...i added them here....do you have more? https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity-ui-windowmanager | 20:24 |
| thomi | kgunn: we (meaning QA) actually have a list - we were gonna talk to you about it in Oakland | 20:24 |
| kgunn | thomi: ack..so you wanna wait :) | 20:26 |
| thomi | kgunn: I assume most of the planning stuff will happen at Oakland, so I figured it made sense to wait till then... | 20:26 |
| thomi | I mean, unless you have people twiddling their thumbs right now :) | 20:26 |
| kgunn | thomi: more like recovery via inebriation | 20:26 |
| thomi | yeah, I'd rather have sober developers work on this stuff, if it's all the same to you :P | 20:27 |
| racarr | I was thinking about that, one of the worst things about this distributed working is I feel like on a day like today | 20:27 |
| racarr | the whole team should be in the bar with a licensed psychologist | 20:27 |
| racarr | but it's just not feasible | 20:27 |
| kgunn | no doubt | 20:28 |
| thomi | should all fly to NZ, we'll go hiking in the hills :) | 20:28 |
| kgunn | racarr: fwiw...i sat in for olli today on rick's meeting | 20:28 |
| kgunn | even he looked & acted exhausted | 20:28 |
| racarr | yeaaah :) | 20:30 |
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!