| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| smspillaz | duflu: what's wrong with changing the if condition as I suggested in your MRQ ? | 06:25 |
|---|---|---|
| duflu | smspillaz: I could not see any way we could do so without regressing something. So regressing support for !XShape seemed least evil | 06:26 |
| smspillaz | duflu: you didn't answer my quesiton | 06:27 |
| smspillaz | as I mentioned, those if checks were only there for the !XShape case, so you should just be able to put them in an else block | 06:28 |
| duflu | smspillaz: Your suggested solution regressed something. I will have to review again to remember | 06:28 |
| smspillaz | okay, keep looking into it | 06:29 |
| smspillaz | BTW, the way the fake minimization code is supposed to work is that we change the input and bounding shape on the client window | 06:29 |
| smspillaz | which is automatically updated to be reflected in the frame window | 06:29 |
| smspillaz | so there shouldn't be any problems there - I tested the life out of it | 06:29 |
| duflu | smspillaz: Hmm, I think I was assuming XShape keeps working with fake-minimize, but obviously it does not (hence the bug) | 06:30 |
| smspillaz | indeed | 06:30 |
| duflu | Ok... | 06:30 |
| smspillaz | uhh oh actually | 06:30 |
| smspillaz | depends on what you're referring to | 06:30 |
| smspillaz | if the window changes shape while we've removed it, we automatically catch that and save the new shape, then restore the "null" input shape | 06:30 |
| duflu | smspillaz: Right, so there's still a risk in the old logic that a dead zone could appear... ? | 06:31 |
| smspillaz | duflu: can you explain further? | 06:32 |
| duflu | smspillaz: I mean how do we not get an XShape while the window is fake-minimized? | 06:32 |
| duflu | Just pure luck that it does not resize during that | 06:33 |
| smspillaz | duflu: we do get them | 06:33 |
| duflu | ? | 06:33 |
| duflu | So... the potential regression you raised is already an issue right now. Not a new problem | 06:33 |
| smspillaz | I ... didn't raise a potential regression ? | 06:34 |
| smspillaz | unless you're talking about the if (w->minimized ()) thing | 06:34 |
| smspillaz | in which case, that's different | 06:34 |
| duflu | smspillaz: Ok, too confusing. I will implement your suggestion and see if anything breaks | 06:34 |
| smspillaz | evidently so ... | 06:34 |
| * duflu has had little sleep and so far today been too unwell to go get the food he needs for dinner. Not thinking well | 06:35 | |
| duflu | smspillaz: How/why do we not get a shape during fake minimize? | 06:40 |
| duflu | It hinges on that | 06:40 |
| smspillaz | duflu: during the fake minimize ? | 06:40 |
| smspillaz | duflu: unity is calling XShapeSelectInput (... NoEventMask) | 06:40 |
| duflu | smspillaz: Ok, ta | 06:41 |
| duflu | A simple explanation | 06:41 |
| smspillaz | I believe we do that so that we don't get a feedback loop | 06:41 |
| smspillaz | and call XSendEvent instead | 06:41 |
| smspillaz | (so we can tell when we shaped ourselves) | 06:41 |
| duflu | Though it means we have (already) some nasty assumption coupled to Unity | 06:41 |
| smspillaz | inside of compiz ? | 06:41 |
| duflu | Yeah | 06:41 |
| smspillaz | what's the assumption ? | 06:42 |
| smspillaz | that we're not going to get a shape event ? | 06:42 |
| duflu | If some other plugin implemented a fake minimize without disabling the shape then we'd have big problems. So we're assuming it is done along with XShapeSelectInput | 06:42 |
| smspillaz | not really | 06:42 |
| smspillaz | so the only reason why we call XShapeSelectInput with NoEventMask in unity is because | 06:43 |
| smspillaz | we need to be able to tell the difference between when we shaped a window and when someone else did | 06:43 |
| smspillaz | BUT compiz needs to know that the window was shaped | 06:43 |
| smspillaz | so, in unity we call XSendEvent and send a fake ShapeNotify on that window | 06:43 |
| smspillaz | and then compiz gets it shape event | 06:43 |
| smspillaz | and when unity gets it, it can tell it was just the same one that it sent, because it checks the send_event field | 06:44 |
| smspillaz | It might be better to implement that through XNextRequest and checking the event serial | 06:45 |
| smspillaz | but it would be similar | 06:45 |
| smspillaz | duflu: anyways, the bottom line is that when the window is fake-minimized, compiz should definitely get a shape event, because unity will have sent one | 06:46 |
| duflu | smspillaz: Right but we're relying on XShapeGetRectangles returning nInput = 0 | 06:46 |
| smspillaz | indeed, and that will happen | 06:46 |
| duflu | Ok | 06:47 |
| smspillaz | because the window will have been shaped :) | 06:47 |
| duflu | I think it's ugly but want to minimize what gets touched right now | 06:47 |
| smspillaz | the current implementation? yes it is :) | 06:47 |
| smspillaz | if I knew about XNextRequest and event serials when I wrote it I would have used that | 06:47 |
| duflu | smspillaz: Now the boundingShape is empty during minimize. So the window is missing during the minimize animation. That's why both the old code and my proposal has to treat bounding and input shapes differently :P | 07:13 |
| smspillaz | duflu: right, we remove both shapes | 07:18 |
| smspillaz | duflu: though, I would imagine the logic you'd use for both would be the same | 07:18 |
| smspillaz | if !XShape -> assume both have one rect each | 07:18 |
| smspillaz | if XShape -> query rectangles, apply to frame window | 07:18 |
| duflu | smspillaz: I will try hacking the old behaviour back in... fall back to the unshaped boundingShape if not available | 07:19 |
| smspillaz | uh ? | 07:19 |
| smspillaz | duflu: that doesn't make any sense to me | 07:19 |
| smspillaz | all you want to do, is just, in the case that xshape is supported, query both the bounding and input shapes on the client window and apply them to the frame window respectively | 07:20 |
| smspillaz | and if it isn't support, assume that the bounding and input shapes exactly match the window geometry | 07:20 |
| smspillaz | *supported | 07:20 |
| duflu | Ok, I went too far down the track of cleaning up the whole function | 07:21 |
| duflu | Should just do what you mentioned | 07:21 |
| duflu | smspillaz: BTW, non-XShape seems to work much better if you set priv->[input]region = geom | 07:22 |
| smspillaz | duflu: show me the change you've made afterwards just so I can see if we're on the same page | 07:22 |
| smspillaz | duflu: at resizing? I would imagine so | 07:22 |
| duflu | smspillaz: I mean no gaps any more | 07:22 |
| smspillaz | gaps ? | 07:22 |
| duflu | smspillaz: I think it improved https://bugs.launchpad.net/compiz/+bug/1087198 | 07:23 |
| ubot5 | Launchpad bug 1087198 in Compiz "When XShape is disabled, many windows open with their contents partially missing on the right hand edge" [Medium,Triaged] | 07:23 |
| duflu | But should double check | 07:23 |
| smspillaz | ah | 07:24 |
| duflu | priv->region = geom as the fallback looks like it might be more correct | 07:24 |
| duflu | smspillaz: With XShape, it still looks like you have to fall back for region, but never for inputRegion. You need to fall back for region to ensure the window is not blank during animation. And you can't fall back for inputRegion because doing so causes the dead zone bug | 07:32 |
| smspillaz | ah | 07:35 |
| smspillaz | hmm | 07:35 |
| duflu | smspillaz: As the old code and my proposal do | 07:36 |
| duflu | So a new proposal needs such an ugly inconsistency too | 07:36 |
| smspillaz | duflu: I remember that unity removed both the input and bounding shape, but now that I think of it, that approach is probably incorrect | 07:37 |
| smspillaz | it should just remove the former | 07:37 |
| duflu | Great | 07:37 |
| duflu | So both projects needs fixing | 07:37 |
| smspillaz | though I remember I had some weird side effects when I didn't remove both | 07:37 |
| smspillaz | (like with chromium for instance) | 07:38 |
| duflu | smspillaz: I've had enough for the year. Approving the revert and you think about proper fixes if you feel so inclined | 07:38 |
| smspillaz | okay, have a good holidays :) | 07:38 |
| duflu | Well, enough of this issue for the year | 07:38 |
| smspillaz | duflu: I remember when I first wrote the fake minimization code for unity, some of the xshape paths in the server were broken | 07:39 |
| smspillaz | that was fun | 07:39 |
| smspillaz | duflu: the fact that the fake minimization code worked the whole time even though we didn't remove the bounding shape from the frame window certainly is telling though | 07:41 |
| duflu | smspillaz: My only real concern was you understanding that inconsistency. Now you do I think I can actually propose a super-fix | 07:41 |
| smspillaz | duflu: a super-fix ? | 07:41 |
| duflu | smspillaz: It worked because of the copy-paste bug! | 07:41 |
| smspillaz | well, it didn't work *because of* it, it just meant that removing the bounding shape from the client window was largely ineffective anyways | 07:41 |
| smspillaz | since we don't unreparent fake minimized windows | 07:42 |
| duflu | smspillaz: I will propose something. Then you decide what to do with it | 07:42 |
| smspillaz | duflu: what are you proposing ? | 07:42 |
| duflu | smspillaz: A rewrite of the function to cover all bases without reverting | 07:42 |
| duflu | May as well I guess | 07:42 |
| duflu | Just won't respond to any reviews :) | 07:43 |
| smspillaz | I'll give the unity thing a try in the meantime to see if the fake minimization code works the way I expect without removing the bounding shape | 07:43 |
| duflu | smspillaz: Don't worry too much. It sounds like there's no much support for keeping the Unity side much longer | 07:44 |
| duflu | Not sure | 07:44 |
| Mirv | ok then, we'll aim straight to the compiz 0.9.7.12 (with unredirect enabled by default) for 12.04 | 07:51 |
| Mirv | when we have it in the PPA, testing can commence :) | 07:52 |
| Mirv | enough workarounds, blacklists etc start to be in place | 07:52 |
| smspillaz | duflu: actually now that I think of it, its probably because of the typo you identified that I had such wonky behaviour with applications that set the bounding shape | 07:53 |
| duflu | smspillaz: Yes. And if it wasn't for the slow resizing I would not have gone looking at XShape-related code :) | 07:57 |
| smspillaz | duflu: if you're still around I've confirmed to have got fake minimization working without setting ShapeBounding with your fix applied | 08:15 |
| duflu | smspillaz: Only physically around. I suspect | 08:16 |
| smspillaz | duflu: okay, I'll put both fixes in my experimental ppa | 08:18 |
| smspillaz | so we can get some testing | 08:18 |
| duflu | smspillaz: I would prefer we just had a snapshot or icon for minimized windows and removed the complexity. But if the bugs are fixed then there's less argument for removing it | 08:24 |
| smspillaz | duflu: live previews aren't really that complicated | 08:24 |
| duflu | Not now that we have spent several days over the past year or two fixing the bugs | 08:24 |
| duflu | But removing complexity is about being nice to the future of humanity... | 08:25 |
| smspillaz | well, this is the first time we've had to touch the code in quite some time | 08:25 |
| duflu | Yeah true. The pain of when it used to crash is still with me somehow | 08:26 |
| smspillaz | duflu: that being said, I think compiz is the only WM right now that has a relatively bug-free implementation | 08:26 |
| smspillaz | I remember mutter and kwin implemented it (in different ways) and it was a complete nightmare for them | 08:27 |
| smspillaz | they didn't use xshape, they used stacking tricks instead | 08:27 |
| duflu | smspillaz: I would not say that in too many public forums, given the resize/move performance and decorator glitches | 08:27 |
| duflu | But it's improving a lot | 08:27 |
| duflu | smspillaz: Oh... relatively bug free live minimize preview... yes. | 08:28 |
| smspillaz | duflu: well, my WIP change has been reported to completely eliminate movement perf problems for those who tested it :) | 08:29 |
| duflu | smspillaz: It was awesome on the old Atom | 08:29 |
| smspillaz | I'm still letting it get more testing though just to see if there are any other weird corner cases | 08:29 |
| duflu | smspillaz: I think the Nexus 7 needs the move/resize improvements desperately. Have not tried them there yet I think | 08:30 |
| smspillaz | duflu: BTW, the buffer_age stuff is awesome. I know glxgears is not a benchmark, but I get something like +200FPS | 08:30 |
| smspillaz | can't wait until its supported in other drivers | 08:31 |
| duflu | smspillaz: What is it relative to copy subbuffer? | 08:31 |
| smspillaz | duflu: haven't checked | 08:31 |
| duflu | The same at least I would hope. Maybe better because you can still use SwapInterval for concurrent rendering | 08:31 |
| duflu | (or on Nvidia, avoiding glCopyPixels) | 08:32 |
| smspillaz | duflu: indeed | 08:32 |
| smspillaz | duflu: I can check now if you want | 08:32 |
| duflu | smspillaz: Don't really want to know. I have too much to deal with yet | 08:33 |
| duflu | today... | 08:33 |
| duflu | smspillaz: But you did get Phoronix excited | 08:34 |
| smspillaz | :p | 08:37 |
| smspillaz | duflu: unity is still having an impact, even though I thought it did nothing when damage regions didn't intersect the shell | 08:37 |
| duflu | smspillaz: Yes I noticed a similar problem on the Nexus this week. I think it's paintDisplay'ing too much | 08:38 |
| smspillaz | duflu: showRepaint says its damageScreening on every frame but that doesn't seem right | 08:39 |
| duflu | smspillaz: Very bad. | 08:39 |
| duflu | smspillaz: Look at r2872. It fixes flickering but maybe that's why I never had such a call in the original regionalDamage work. | 08:40 |
| duflu | Like something is getting queued in UnityScreen::compizDamageNux despite not intersecting | 08:42 |
| smspillaz | duflu: the panel is redrawing on every frame | 08:42 |
| smspillaz | being called from UBusServer::DispatchMessages -> OnBackgroundUpdate | 08:42 |
| smspillaz | how is our battery life /not/ screwed | 08:42 |
| smspillaz | uhh right | 08:43 |
| smspillaz | so ubus is spamming us every frame telling us the background color changed | 08:43 |
| duflu | smspillaz: What?! | 08:43 |
| === apinheiro is now known as apinheiro_afk | ||
| Mirv | smspillaz: yeah, really cool blog post | 09:21 |
| === duflu is now known as duflu|vacation | ||
| smspillaz | Mirv: :) | 09:27 |
| smspillaz | Mirv: sadly, its still going to be slow on unity. The fact that we reverted regionalDamage and replaced it with (if something_nux_drawn) damageScreen (); means theres a feedback loop causing the screen to be damaged every frame regardless of whether unity drew | 09:27 |
| smspillaz | I'm trying to see if we can unrevert that safely | 09:28 |
| sil2100 | regionalDamage got reverted? | 09:30 |
| didrocks | hey sil2100, do you have a little status now that you've merged some tests about which ones are still broken? | 09:37 |
| sil2100 | didrocks: yes, one moment - I'll just fetch the list | 09:38 |
| didrocks | thanks ;) | 09:39 |
| sil2100 | didrocks: so, currently from the latest test result, 2 test failures are probably gone for good, 2 are being worked on, 4 are actual regressions (;p) and one of them seems to be hm, a singular case I wasn't able to figure out | 09:40 |
| didrocks | sil2100: so, we'll just have one remaining when then 2+4 are fixed? That's awesome \o/ | 09:41 |
| didrocks | sil2100: do you have time to track those and ensure it's done by end of next week? (not sure about your schedule and holidays) | 09:41 |
| sil2100 | didrocks: yes! Well, I even think that one failed test will anyway not fail next time I hope, probably a single case of a failure due to 'bad luck'? | 09:41 |
| didrocks | sil2100: let's see ;) | 09:42 |
| sil2100 | didrocks: no problem, I hope to finish those till this EOW | 09:42 |
| didrocks | sil2100: you rock! I won't be there next week, but just drop me an email if possible so that once I'm back from holidays, I don't bother you :) | 09:42 |
| sil2100 | didrocks: I'm just doing some formalities regarding the compiz SRU for precise, like bug descriptions | 09:42 |
| didrocks | sweet ;) | 09:42 |
| sil2100 | didrocks: np! Will do so! | 09:42 |
| didrocks | thanks again sil2100, that's a life saver to have those tests running for stacks! :) | 09:43 |
| axyz | hello | 10:29 |
| axyz | currently, if I have let's say 4 skype (or any other app) windows opened, when i click on launcher i will see them arranged on the screen | 10:30 |
| axyz | i want to see only their titles, like in windows/kde | 10:30 |
| axyz | is this possible ? | 10:30 |
| axyz | anyone here ? | 10:34 |
| sil2100 | smspillaz: hi, are you around ;) ? | 10:50 |
| === _salem is now known as salem_ | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| fginther | mhr3, ping | 14:15 |
| mhr3 | fginther, pong | 14:15 |
| fginther | mhr3, I resolved the non-srcdir build issues in https://code.launchpad.net/~fginther/dee/add-code-coverage/+merge/139586, would you like to review? | 14:16 |
| mhr3 | fginther, it was merged 5hours ago ;) | 14:16 |
| fginther | ackk! thanks. I should learn to refresh my web pages :-) | 14:17 |
| === rsalveti_ is now known as rsalveti | ||
| fginther | Trevinho, ping | 15:22 |
| sil2100 | larsu: hi! | 15:28 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === sil2100_ is now known as sil2100 | ||
| Trevinho | fginther: hi | 16:36 |
| fginther | Trevinho, can you recommend a reviewer for https://code.launchpad.net/~fginther/bamf/add-code-coverage/+merge/138590? | 16:37 |
| Trevinho | fginther: someone from distro, or I can do that | 16:39 |
| fginther | Trevinho, I'm looking for someone familiar with bamf to make sure I've added coverage to the right places and didn't break any existing work-flow | 16:43 |
| Trevinho | fginther: well, I am familiar with it | 16:47 |
| Trevinho | fginther: quite EOW for me... But I'll try to give it a look on next days | 16:47 |
| fginther | Trevinho, no rush. Thanks in advance | 16:48 |
| === gatox_ultra is now known as gatox | ||
| didrocks | sil2100: hey, before I'm going on holidays, do you have any good news on the test fronts? | 17:27 |
| didrocks | now, the plumbings are connected here, so it's just a question to get the list of failure for indicators down to 0 \o/ | 17:27 |
| didrocks | mterry: cyphermox: just confirming that I disabled the daily landing on purpose before going on holidays | 17:28 |
| cyphermox | ack | 17:28 |
| mhr3 | didrocks, oh, you're leaving us already? | 17:33 |
| mhr3 | didrocks, enjoy christmas then! | 17:33 |
| didrocks | mhr3: thanks a lot! will do, you too when you will be on holidays :) | 17:34 |
| didrocks | (still here for 30 minutes before holidays, finishing some catching up) | 17:34 |
| mhr3 | didrocks, you're doing it wrong, no need to catch up before going away :P | 17:34 |
| didrocks | ahah :) | 17:35 |
| mhr3 | you need to catch up when you come back :) | 17:35 |
| didrocks | well, let's say it's to have *less* to catch up :) | 17:35 |
| didrocks | I see that seb128 is emptying his old emails to answer as well :p | 17:35 |
| seb128 | didrocks, that's correct! | 17:36 |
| mhr3 | i'm sure he just implemented a new bot! ;) | 17:36 |
| didrocks | heh | 17:36 |
| didrocks | mhr3: with what I received, it's very much possible :p | 17:36 |
| mhr3 | you guys know that an intelligent system is just an aggregation of simple parts? one day lp will become self aware and it'll be because of your bots! | 17:38 |
| didrocks | heh ;) | 17:41 |
| mterry | whoops, just missed didrocks | 17:49 |
| alo21 | hi. When a new lens' idea could be imported into standard Ubuntu installation? | 18:16 |
| gatox | hi, quick question...... unity is building in raring? | 18:27 |
| gatox | well...... i see it's building..... but i was looking for the recipe to see the dependencies listed there | 18:29 |
| bregma | gatox, if you want to see the Unity build dependencies for raring, look in lp:unity in the file debian/control ... they're listed under Build-Depends: | 18:59 |
| gatox | bregma, thx... yes. i see the problem was i was based my recipe in an older debian/control it seems | 18:59 |
| gatox | bregma, thx | 18:59 |
| smspillaz | bregma: hey, how is it going? do you think I might be able to get some of the people on your team to do some reviews ? | 19:20 |
| bregma | ask bschaefer for reviews, but we've already got a big backlog and a lot of people gone for the holidays | 19:21 |
| bregma | so don't get too impatient | 19:22 |
| smspillaz | yeah I saw XD | 19:22 |
| smspillaz | bregma: maybe someone should clean up the +activereviews page its getting a bit big | 19:22 |
| smspillaz | just reject everything that's not had any activity for > 2 months | 19:22 |
| bregma | on my list, but, I'm supposed to be on vacation myself | 19:22 |
| smspillaz | heh, I'm not supposed to be "working", though I do need a desktop that doesn't lag like crazy ... and now that I have some free time I felt like actually going and doing that :p | 19:23 |
| smspillaz | since everyone is so busy :) | 19:24 |
| bschaefer | smspillaz, you need a review? | 19:44 |
| === mhall119_ is now known as mhall119 | ||
| === hggdh_ is now known as hggdh | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!