Merge lp:~unity-team/unity/unity.fix_1080947.2.1 into lp:unity

Proposed by Christopher Townsend
Status: Merged
Approved by: Christopher Townsend
Approved revision: no longer in the source branch.
Merged at revision: 3591
Proposed branch: lp:~unity-team/unity/unity.fix_1080947.2.1
Merge into: lp:unity
Diff against target: 848 lines (+317/-140)
15 files modified
CMakeLists.txt (+1/-1)
debian/control (+4/-4)
launcher/CairoBaseWindow.cpp (+0/-6)
launcher/CairoBaseWindow.h (+0/-1)
launcher/Launcher.cpp (+0/-6)
launcher/Launcher.h (+0/-3)
launcher/LauncherController.cpp (+4/-4)
launcher/XdndCollectionWindowImp.cpp (+4/-0)
panel/PanelView.cpp (+0/-6)
panel/PanelView.h (+0/-3)
plugins/unityshell/src/unityshell.cpp (+276/-100)
plugins/unityshell/src/unityshell.h (+25/-2)
unity-shared/BackgroundEffectHelper.cpp (+1/-1)
unity-shared/PlacesOverlayVScrollBar.cpp (+1/-2)
unity-shared/PluginAdapter.cpp (+1/-1)
To merge this branch: bzr merge lp:~unity-team/unity/unity.fix_1080947.2.1
Reviewer Review Type Date Requested Status
PS Jenkins bot (community) continuous-integration Approve
Stephen M. Webb (community) Approve
Christopher Townsend Approve
Brandon Schaefer (community) Approve
Esokrates testing Pending
Andrea Azzarone Pending
Sam Spilsbury Pending
Alfred E. Neumayer Pending
Review via email: mp+193286@code.launchpad.net

This proposal supersedes a proposal from 2013-05-26.

Commit message

Don't re-present all of our windows on every frame. Only do that if damage intersects it.

Use the new APIs exposed by compiz and nux to intelligently determine which windows need to be presented per-frame and only register damage for those windows. This fixes two things:

1. BaseWindows being redrawn from scratch every time damage was registered over them. That was incorrect and should only be done in the case of background blurs.
2. BaseWindows being drawn to the screen on every frame, regardless of whether or not they needed to be. Now they will only be drawn if some damage intersects beneath them. Note that unity will expand the damage region to accomadate the base window since nux does not support geometry clipping. So if there is a partial intersection of the launcher for example, the area of the screen which contains the launcher will be re-painted (but the launcher itself won't be redrawn, just its texture)

(LP: #1080947)

Description of the change

Don't re-present all of our windows on every frame. Only do that if damage intersects it.

Use the new APIs exposed by compiz and nux to intelligently determine which windows need to be presented per-frame and only register damage for those windows. This fixes two things:

1. BaseWindows being redrawn from scratch every time damage was registered over them. That was incorrect and should only be done in the case of background blurs.
2. BaseWindows being drawn to the screen on every frame, regardless of whether or not they needed to be. Now they will only be drawn if some damage intersects beneath them. Note that unity will expand the damage region to accomadate the base window since nux does not support geometry clipping. So if there is a partial intersection of the launcher for example, the area of the screen which contains the launcher will be re-painted (but the launcher itself won't be redrawn, just its texture).

This also uses the framebuffer blitting API from compiz to quickly copy the non-blurred regions of the screen back to the backbuffer.

(LP: #1080947)

This branch depends on two others:

1. https://code.launchpad.net/~smspillaz/nux/nux.fix_1091589/+merge/147543 (WindowThread::PresentWindowsIntersectingGeometryOnThisFrame, WindowThread::ForeignFrameCutoff, WindowThread::ForeignFrameEnded)
2. https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1024304/+merge/147540 (composite::Frameroster)

Update: test results here: http://www.ucc.asn.au/~smspillaz/phoronix-test-suite/composite.xml

I was careful to modify phoronix-test-suite to run tests in windowed mode only, and those were the only three tests I was able to get to run in windowed mode. Of particular interest was the fact that the unigine demos had a 5x performance improvement, probably because the driver was spending less time filling redundant pixels from the compositor. In other areas we had a roughly 5FPS boost.

Compiz framerate graph:

http://www.ucc.asn.au/~smspillaz/compiz-perf-graph.png

You'll see that especially on the last test, it drops off quite a bit on the non buffer_age case, and is generally speaking lower across the board.

To post a comment you must log in.
Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

Ok it builds here. But I get two main regressions here:
#. Dragging launcher icons creates artifacts on the screen
#. Unity crash dragging files (e.g. nautilus files).

Can you reproduce there?

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

*crashes

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Hey Andrea, thanks for testing. I'll look into those two as soon as possible.

I suspect the latter was a crash that existed upstream already, or at least, it happened in an area of the code I didn't touch.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Hey Again,

So the trails issue was really because nux wasn't keeping track of both the old and new geometries when posting the damage region. I've fixed it to do that now, so you should pull from the nux branch.

Worryingly - trying to drag any launcher icon on nvidia results in the paint loop simply ceasing to work. We still paint everything and call glXSwapBuffers, but nothing ends up on-screen. Not sure why it does that - can someone double check with trunk on an nvidia machine?

As for the crash - I can't reproduce that. Can you grab a stracktrace?

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

8 - ShowWindow(true);
9 + // We are not calling ShowWindow () as this window
10 + // isn't really visible

Reverting this change seems to fix the issue. Btw the dnd issue with launcher icons is gone! :)

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Hmm. Okay. I'll have a brief look into that, the input window needs to be
"hidden" otherwise it gets damaged on every from (eg fullscreen damage)
On 26/03/2013 3:13 AM, "Andrea Azzarone" <email address hidden> wrote:

> 8 - ShowWindow(true);
> 9 + // We are not calling ShowWindow () as this window
> 10 + // isn't really visible
>
> Reverting this change seems to fix the issue. Btw the dnd issue with
> launcher icons is gone! :)
> --
>
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
>

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

> Hmm. Okay. I'll have a brief look into that, the input window needs to be
> "hidden" otherwise it gets damaged on every from (eg fullscreen damage)

What about:

ShowWindow(true);
ShowWindow(false);

just to force the creation of the X window?

> On 26/03/2013 3:13 AM, "Andrea Azzarone" <email address hidden> wrote:
>
> > 8 - ShowWindow(true);
> > 9 + // We are not calling ShowWindow () as this window
> > 10 + // isn't really visible
> >
> > Reverting this change seems to fix the issue. Btw the dnd issue with
> > launcher icons is gone! :)
> > --
> >
> >
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> > You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
> >

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Tue, Mar 26, 2013 at 8:08 AM, Andrea Azzarone <email address hidden> wrote:
>> Hmm. Okay. I'll have a brief look into that, the input window needs to be
>> "hidden" otherwise it gets damaged on every from (eg fullscreen damage)
>
> What about:
>
> ShowWindow(true);
> ShowWindow(false);
>
> just to force the creation of the X window?

That could work - does the X window need to be mapped ?

>
>> On 26/03/2013 3:13 AM, "Andrea Azzarone" <email address hidden> wrote:
>>
>> > 8 - ShowWindow(true);
>> > 9 + // We are not calling ShowWindow () as this window
>> > 10 + // isn't really visible
>> >
>> > Reverting this change seems to fix the issue. Btw the dnd issue with
>> > launcher icons is gone! :)
>> > --
>> >
>> >
>> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
>> > You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
>> >
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

59 + //directly_drawable_fbo_.reset (cgl::createBlittableFramebufferObjectWithFallback(*screen,
60 + // gScreen));

Remove these lines please if you don't need them ;)

83 + for (CompOutput &output : screen->outputDevs())
84 + {
85 + FillShadowRectForOutput(panelShadow, &output);
86 + cScreen->damageRegion(CompRegion(panelShadow));
87 + }

What about CompOutput const&? You will need to make this change too: from

 +void UnityScreen::FillShadowRectForOutput(CompRect &shadowRect,
113 + CompOutput *output)

to

CompOutput const& output.

+ nux::Geometry geometry(bw->GetAbsoluteGeometry());

Just do: nux::Geometry const& geometry = bw->...

100 +void UnityScreen::OnViewShown(nux::BaseWindow *bw)
101 +{
102 +}

Do we really need it?

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Agree on all points. I was going to keep the commented out code as I'd like
to push through the new framebuffer object api, keeping then there would
just ease some of the later porting work but I can remove then if need be.
On 26/03/2013 9:06 AM, "Andrea Azzarone" <email address hidden> wrote:

> 59 + //directly_drawable_fbo_.reset
> (cgl::createBlittableFramebufferObjectWithFallback(*screen,
> 60 + //
> gScreen));
>
> Remove these lines please if you don't need them ;)
>
> 83 + for (CompOutput &output : screen->outputDevs())
> 84 + {
> 85 + FillShadowRectForOutput(panelShadow, &output);
> 86 + cScreen->damageRegion(CompRegion(panelShadow));
> 87 + }
>
> What about CompOutput const&? You will need to make this change too: from
>
> +void UnityScreen::FillShadowRectForOutput(CompRect &shadowRect,
> 113 + CompOutput *output)
>
> to
>
> CompOutput const& output.
>
> + nux::Geometry geometry(bw->GetAbsoluteGeometry());
>
> Just do: nux::Geometry const& geometry = bw->...
>
> 100 +void UnityScreen::OnViewShown(nux::BaseWindow *bw)
> 101 +{
> 102 +}
>
> Do we really need it?
>
>
>
>
> --
>
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
>

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Okay, all updated as requested.

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

> Okay, all updated as requested.

I'll try again tomorrow.

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

Looks good now. Please remove this line too:

164 + printf ("rebind!\n");

Any progress on "jerky" dash (during the scrolling)?

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

So there are two reasons why dash scrolling could be slow:

1) Maybe glCopyTexSubImage2D really is faster than bind -> paint -> unbind -> paint
2) The extra rebinds we have to do as a result of not having the new fbo api available are slowing us down.

For now I'll see if we can just move back to using CopyTexSubImage2D

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Okay, I've gone back to the old glCopyTexSubImage2D method. I suspect that's faster anyways and it works on both nouveau and nvidia. We can easily speed it up by doing partial copies of the backbuffer, but that's work for another branch.

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

/home/andrea/unity/source/unity/plugins/unityshell/src/unityshell.cpp:1461:7: error: ‘back_buffer_age_’ was not declared in this scope

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Ah, sorry about that, must have missed a file in the commit -.-

Why do we not have CI runs on lp:unity?

On Fri, Mar 29, 2013 at 4:52 AM, Andrea Azzarone <email address hidden> wrote:
> /home/andrea/unity/source/unity/plugins/unityshell/src/unityshell.cpp:1461:7: error: ‘back_buffer_age_’ was not declared in this scope
>
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Okay, should be all fixed.

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

Builds now but the dash is still slow. How can I help you debugging it?

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Hmm. That's odd. Is it actually slower compared to trunk? There nothing in
this code which will cause it to paint more.
On 29/03/2013 5:25 PM, "Andrea Azzarone" <email address hidden> wrote:

> Builds now but the dash is still slow. How can I help you debugging it?
> --
>
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
>

Revision history for this message
Alfred E. Neumayer (beidl) wrote : Posted in a previous version of this proposal

Performance wise, it feels a better with games in windowed mode, but what I've noticed:
1) Scrolling through the dash per touchpad appears to be a tiny bit choppier than previously (Intel HD 4000).

2) Also, when switching from the window spread/scale to the dash, everything outside the dash blur is animating quite smoothly, but the blur seems to update its content properly only near the end of the spread animation.
It could well be a problem with the dash/lenses doing IO and blocking the blur redraw until IO is done.
OR it's always been this way and i just did not notice it because the dash used to fade in slower.
Visually the dash appears to fade in instantly, but the blur has to catch up.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Hey Alfred

On Sat, Mar 30, 2013 at 9:52 AM, Alfred Neumayer <email address hidden> wrote:
> Performance wise, it feels a better with games in windowed mode, but what I've noticed:
> 1) Scrolling through the dash per touchpad appears to be a tiny bit choppier than previously (Intel HD 4000).
>

So I'm not sure about this. What it might be worth doing is checking
to see if you still get this choppiness with the blurs turned off. I
did some work yesterday to make sure we're not updating the blur on
unity-only damages, however there could be a case where they are being
updated where they should not be.

> 2) Also, when switching from the window spread/scale to the dash, everything outside the dash blur is animating quite smoothly, but the blur seems to update its content properly only near the end of the spread animation.

Right, there is code inside the dash to only update blurs when we were
not updating the dash content already. If there is a spinner or
something running we won't update them. So it will be out of sync a
little bit. That code has always been there.
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Alfred E. Neumayer (beidl) wrote : Posted in a previous version of this proposal

> So I'm not sure about this. What it might be worth doing is checking
> to see if you still get this choppiness with the blurs turned off. I
> did some work yesterday to make sure we're not updating the blur on
> unity-only damages, however there could be a case where they are being
> updated where they should not be.

Tested with blur turned off and scrolling behaviour is back to normal.
I mean it's really not a deal breaker but it's still a noticable difference, at least for me.

>
> > 2) Also, when switching from the window spread/scale to the dash, everything
> outside the dash blur is animating quite smoothly, but the blur seems to
> update its content properly only near the end of the spread animation.
>
> Right, there is code inside the dash to only update blurs when we were
> not updating the dash content already. If there is a spinner or
> something running we won't update them. So it will be out of sync a
> little bit. That code has always been there.

Makes sense.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Sat, Mar 30, 2013 at 10:13 AM, Alfred Neumayer <email address hidden> wrote:
>> So I'm not sure about this. What it might be worth doing is checking
>> to see if you still get this choppiness with the blurs turned off. I
>> did some work yesterday to make sure we're not updating the blur on
>> unity-only damages, however there could be a case where they are being
>> updated where they should not be.
>
> Tested with blur turned off and scrolling behaviour is back to normal.
> I mean it's really not a deal breaker but it's still a noticable difference, at least for me.

Andrea - this could be those QueueDraw calls within the ScrollView
acting up. I didn't catch blur updates happening just on scrolling
alone, but that could be a cause. Could you check if the blurs are
updating in this case?

--
Sam Spilsbury

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

> On Sat, Mar 30, 2013 at 10:13 AM, Alfred Neumayer <email address hidden> wrote:
> >> So I'm not sure about this. What it might be worth doing is checking
> >> to see if you still get this choppiness with the blurs turned off. I
> >> did some work yesterday to make sure we're not updating the blur on
> >> unity-only damages, however there could be a case where they are being
> >> updated where they should not be.
> >
> > Tested with blur turned off and scrolling behaviour is back to normal.
> > I mean it's really not a deal breaker but it's still a noticable difference,
> at least for me.
>
> Andrea - this could be those QueueDraw calls within the ScrollView
> acting up. I didn't catch blur updates happening just on scrolling
> alone, but that could be a cause. Could you check if the blurs are
> updating in this case?
>
> --
> Sam Spilsbury

Nope, I think he's testing my PPA that does not have the fix for the dash scroll issue. :)

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Sat, Mar 30, 2013 at 5:07 PM, Andrea Azzarone <email address hidden> wrote:
>> On Sat, Mar 30, 2013 at 10:13 AM, Alfred Neumayer <email address hidden> wrote:
>> >> So I'm not sure about this. What it might be worth doing is checking
>> >> to see if you still get this choppiness with the blurs turned off. I
>> >> did some work yesterday to make sure we're not updating the blur on
>> >> unity-only damages, however there could be a case where they are being
>> >> updated where they should not be.
>> >
>> > Tested with blur turned off and scrolling behaviour is back to normal.
>> > I mean it's really not a deal breaker but it's still a noticable difference,
>> at least for me.
>>
>> Andrea - this could be those QueueDraw calls within the ScrollView
>> acting up. I didn't catch blur updates happening just on scrolling
>> alone, but that could be a cause. Could you check if the blurs are
>> updating in this case?

Ah okay.

In any case, I've been doing some work to reduce the amount of pixels
we need to copy around every time the blurs are updated, would it make
sense to have that work in here too? Its somewhat unrelated but
probably useful.

>>
>> --
>> Sam Spilsbury
>
> Nope, I think he's testing my PPA that does not have the fix for the dash scroll issue. :)
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

Ok the PPA should be fine now. Alfred, can you check? Thanks!

@Sam, how many lines of code?

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Sat, Mar 30, 2013 at 6:03 PM, Andrea Azzarone <email address hidden> wrote:
> Ok the PPA should be fine now. Alfred, can you check? Thanks!
>
> @Sam, how many lines of code?

Dunno, still working on it, could be fairly substantial.

I might just split it out.

> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Alfred E. Neumayer (beidl) wrote : Posted in a previous version of this proposal

Yup, I should have told you guys that I'm using the PPA. Don't have enough time for compiling it from scratch atm.
And yes, updated the packages and scrolling is niiiice.

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

@Alfred, nice! :) Can I ask you what graphic card are you using?

Revision history for this message
Andrea Azzarone (azzar1) : Posted in a previous version of this proposal
review: Approve
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Cool.

We'll need to make sure to merge the other ones in order, otherwise
things will break.

On Sat, Mar 30, 2013 at 8:25 PM, Andrea Azzarone <email address hidden> wrote:
> Review: Approve
>
>
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
MC Return (mc-return) wrote : Posted in a previous version of this proposal

> review: Approve

Hurra \o/

> @Alfred, nice! :) Can I ask you what graphic card are you using?

I think he mentioned Intel HD 4000 above ^^

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

I've put the partial back-buffer-copy work into this branch: https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.3/+merge/156260

If you want me to merge it back into this one, just say so.

Revision history for this message
Alfred E. Neumayer (beidl) wrote : Posted in a previous version of this proposal

> > review: Approve
>
> Hurra \o/
>
> > @Alfred, nice! :) Can I ask you what graphic card are you using?
>
> I think he mentioned Intel HD 4000 above ^^

Intel HD 4000 as well as NVidia 640M LE through Bumblebee (those PRIME helper merges in one of the latest kernel revisions leave me wondering if we're going to see some nice Optimus action soon...)
Also, approve before it's too late :)

review: Approve
Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

Due to the imminent release we're going to merge this branch as soon as after the release.

Revision history for this message
MC Return (mc-return) wrote : Posted in a previous version of this proposal

> Due to the imminent release we're going to merge this branch as soon as after
> the release.

Andrea, will Compiz still be the default window manager for Unity in 13.10 ?

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Wed, Apr 3, 2013 at 7:36 PM, Andrea Azzarone <email address hidden> wrote:
> Due to the imminent release we're going to merge this branch as soon as after the release.

Hmm, by release do you mean beta freeze, the current unity release or 13.04?

> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Okay, by "release" Andrea meant 13.04.

That's a real shame, considering that we had plenty of chances to get
this in before feature freeze. It was ready for review in December,
and resources were only allocated to doing so in March after feature
freeze.

I think product-strategy and distro need to have a serious talk about
how they handle these things, because the status of whether or not it
was actually going in has changed about 4 times now. I sense that the
communication lines have broken down somewhere, and the policy that is
being applied is not transparent at all.

If compiz and unity-legacy will not be the default shell in 13.10,
then this has resulted in a huge waste of a contributors time.

On Wed, Apr 3, 2013 at 8:20 PM, Sam Spilsbury <email address hidden> wrote:
> On Wed, Apr 3, 2013 at 7:36 PM, Andrea Azzarone <email address hidden> wrote:
>> Due to the imminent release we're going to merge this branch as soon as after the release.
>
> Hmm, by release do you mean beta freeze, the current unity release or 13.04?
>
>> --
>> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
>> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
>
>
>
> --
> Sam Spilsbury
>
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

> > Due to the imminent release we're going to merge this branch as soon as
> after
> > the release.
>
> Andrea, will Compiz still be the default window manager for Unity in 13.10 ?

We are not sure of the Unity Next state for 13.10.

Revision history for this message
Alfred E. Neumayer (beidl) wrote : Posted in a previous version of this proposal

> Okay, by "release" Andrea meant 13.04.
>
> That's a real shame, considering that we had plenty of chances to get
> this in before feature freeze. It was ready for review in December,
> and resources were only allocated to doing so in March after feature
> freeze.
>
> I think product-strategy and distro need to have a serious talk about
> how they handle these things, because the status of whether or not it
> was actually going in has changed about 4 times now. I sense that the
> communication lines have broken down somewhere, and the policy that is
> being applied is not transparent at all.
>
> If compiz and unity-legacy will not be the default shell in 13.10,
> then this has resulted in a huge waste of a contributors time.
>
> On Wed, Apr 3, 2013 at 8:20 PM, Sam Spilsbury <email address hidden> wrote:
> > On Wed, Apr 3, 2013 at 7:36 PM, Andrea Azzarone <email address hidden> wrote:
> >> Due to the imminent release we're going to merge this branch as soon as
> after the release.
> >
> > Hmm, by release do you mean beta freeze, the current unity release or 13.04?
> >
> >> --
> >>
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> >> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
> >
> >
> >
> > --
> > Sam Spilsbury
> >
> > --
> >
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> > You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
>
>
>
> --
> Sam Spilsbury

I couldn't agree more.
In the meantime, some really questionable changes have been made, literally days ago, which cause trouble in usability, and nobody even cares to look at my bug report.
Something is going wrong here.

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

> > Okay, by "release" Andrea meant 13.04.
> >
> > That's a real shame, considering that we had plenty of chances to get
> > this in before feature freeze. It was ready for review in December,
> > and resources were only allocated to doing so in March after feature
> > freeze.
> >
> > I think product-strategy and distro need to have a serious talk about
> > how they handle these things, because the status of whether or not it
> > was actually going in has changed about 4 times now. I sense that the
> > communication lines have broken down somewhere, and the policy that is
> > being applied is not transparent at all.
> >
> > If compiz and unity-legacy will not be the default shell in 13.10,
> > then this has resulted in a huge waste of a contributors time.
> >
> > On Wed, Apr 3, 2013 at 8:20 PM, Sam Spilsbury <email address hidden> wrote:
> > > On Wed, Apr 3, 2013 at 7:36 PM, Andrea Azzarone <email address hidden>
> wrote:
> > >> Due to the imminent release we're going to merge this branch as soon as
> > after the release.
> > >
> > > Hmm, by release do you mean beta freeze, the current unity release or
> 13.04?
> > >
> > >> --
> > >>
> >
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> > >> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
> > >
> > >
> > >
> > > --
> > > Sam Spilsbury
> > >
> > > --
> > >
> >
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> > > You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
> >
> >
> >
> > --
> > Sam Spilsbury
>
> I couldn't agree more.
> In the meantime, some really questionable changes have been made, literally
> days ago, which cause trouble in usability, and nobody even cares to look at
> my bug report.
> Something is going wrong here.

What changes? Link to bug report?

Revision history for this message
Alfred E. Neumayer (beidl) wrote : Posted in a previous version of this proposal

> > > Okay, by "release" Andrea meant 13.04.
> > >
> > > That's a real shame, considering that we had plenty of chances to get
> > > this in before feature freeze. It was ready for review in December,
> > > and resources were only allocated to doing so in March after feature
> > > freeze.
> > >
> > > I think product-strategy and distro need to have a serious talk about
> > > how they handle these things, because the status of whether or not it
> > > was actually going in has changed about 4 times now. I sense that the
> > > communication lines have broken down somewhere, and the policy that is
> > > being applied is not transparent at all.
> > >
> > > If compiz and unity-legacy will not be the default shell in 13.10,
> > > then this has resulted in a huge waste of a contributors time.
> > >
> > > On Wed, Apr 3, 2013 at 8:20 PM, Sam Spilsbury <email address hidden> wrote:
> > > > On Wed, Apr 3, 2013 at 7:36 PM, Andrea Azzarone <email address hidden>
> > wrote:
> > > >> Due to the imminent release we're going to merge this branch as soon as
> > > after the release.
> > > >
> > > > Hmm, by release do you mean beta freeze, the current unity release or
> > 13.04?
> > > >
> > > >> --
> > > >>
> > >
> >
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> > > >> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
> > > >
> > > >
> > > >
> > > > --
> > > > Sam Spilsbury
> > > >
> > > > --
> > > >
> > >
> >
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> > > > You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
> > >
> > >
> > >
> > > --
> > > Sam Spilsbury
> >
> > I couldn't agree more.
> > In the meantime, some really questionable changes have been made, literally
> > days ago, which cause trouble in usability, and nobody even cares to look at
> > my bug report.
> > Something is going wrong here.
>
> What changes? Link to bug report?

Link to the bug report: https://bugs.launchpad.net/unity/+bug/1163041
The change was specific to the Unity plugin itself, but my point is,
there is this half-done (even though it's a good start) feature that got merged in,
but then these much needed performance improvements get postponed.
It's little confusing to me, a passionate user and promoter of Ubuntu.
(I wished I had enough time digging into C++ and compositors to little more to help out, but I'm just a stupid managed code developer ^^)
But as i can see, Andrea already took care of that bug. :)

Revision history for this message
MC Return (mc-return) wrote : Posted in a previous version of this proposal

> Okay, by "release" Andrea meant 13.04.
>
> That's a real shame, considering that we had plenty of chances to get
> this in before feature freeze. It was ready for review in December,
> and resources were only allocated to doing so in March after feature
> freeze.
>
Something is definitely wrong if MPs of core components do not get looked
at, tested and reviewed in time.
This just tells the contributor: Go away, we have enough work to do without
you - do not try to fix bugs, you are just creating more work for us.

But maybe this is exactly the message someone wants to get across ?

> I think product-strategy and distro need to have a serious talk about
> how they handle these things, because the status of whether or not it
> was actually going in has changed about 4 times now. I sense that the
> communication lines have broken down somewhere, and the policy that is
> being applied is not transparent at all.
>
Well that is definitely true also, but has been that way for some time:
Take a look at Compiz product strategy. First, main priority was to get it
compatible to GLES in 12.10, no matter how finished this port is and no
matter how much core functionality and plugins get broken by that.

Now main priority seems to be to deprecate X/Compiz and replace it with
Mir/Unity-QML, which is another thing that can only come with a ton of
regressions attached and the desktop will be severely hurt with this
move - but hey - we get a cellphone system for the desktop instead ;(

The problem seems to be that people making technical decisions do not
seem to have any idea about the technology they try to decide on...

But I guess all other big companies must be crazy to make different
systems for cell phones and desktop PCs...

> If compiz and unity-legacy will not be the default shell in 13.10,
> then this has resulted in a huge waste of a contributors time.
>
One contributor's time ?

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Oops, I didn't mean to turn this into a debate.

The conversation needs to be had between product-strategy and distro
as to how they are going to handle communication better, but this is a
very specific topic.

On Thu, Apr 4, 2013 at 12:44 PM, MC Return <email address hidden> wrote:
>> Okay, by "release" Andrea meant 13.04.
>>
>> That's a real shame, considering that we had plenty of chances to get
>> this in before feature freeze. It was ready for review in December,
>> and resources were only allocated to doing so in March after feature
>> freeze.
>>
> Something is definitely wrong if MPs of core components do not get looked
> at, tested and reviewed in time.
> This just tells the contributor: Go away, we have enough work to do without
> you - do not try to fix bugs, you are just creating more work for us.
>
> But maybe this is exactly the message someone wants to get across ?
>
>> I think product-strategy and distro need to have a serious talk about
>> how they handle these things, because the status of whether or not it
>> was actually going in has changed about 4 times now. I sense that the
>> communication lines have broken down somewhere, and the policy that is
>> being applied is not transparent at all.
>>
> Well that is definitely true also, but has been that way for some time:
> Take a look at Compiz product strategy. First, main priority was to get it
> compatible to GLES in 12.10, no matter how finished this port is and no
> matter how much core functionality and plugins get broken by that.
>
> Now main priority seems to be to deprecate X/Compiz and replace it with
> Mir/Unity-QML, which is another thing that can only come with a ton of
> regressions attached and the desktop will be severely hurt with this
> move - but hey - we get a cellphone system for the desktop instead ;(
>
> The problem seems to be that people making technical decisions do not
> seem to have any idea about the technology they try to decide on...
>
> But I guess all other big companies must be crazy to make different
> systems for cell phones and desktop PCs...
>
>> If compiz and unity-legacy will not be the default shell in 13.10,
>> then this has resulted in a huge waste of a contributors time.
>>
> One contributor's time ?
>
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Esokrates (esokrarkose) wrote : Posted in a previous version of this proposal

This problem only happens using this branch together with the compiz branch and nvidia drivers (all tested versions):
Logging in one of the tty’s (e.g.: Ctrl + Alt + F1) run a command so that the screen gets filled up (for example find) and switch back (e.g. Ctrl + Alt + F7) then the panel and launcher look like this:
http://ubuntuone.com/3hlErb4cEnRwFSB57EuBLo
http://ubuntuone.com/08yoXGBdaeVwlwGEZWZy3t
(Sometimes it is not even necessary to log in or run a command)

review: Approve (testing)
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

> This problem only happens using this branch together with the compiz branch
> and nvidia drivers (all tested versions):
> Logging in one of the tty’s (e.g.: Ctrl + Alt + F1) run a command so that the
> screen gets filled up (for example find) and switch back (e.g. Ctrl + Alt +
> F7) then the panel and launcher look like this:
> http://ubuntuone.com/3hlErb4cEnRwFSB57EuBLo
> http://ubuntuone.com/08yoXGBdaeVwlwGEZWZy3t
> (Sometimes it is not even necessary to log in or run a command)

Hi,

The nvidia drivers are known to trash framebuffer objects upon VT switches. Sometimes we run into this condition, sometimes we don't. There's not much we can do about it.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Okay, so I've talked to Didier about this and we've come up with a small plan of action. We'll need to give this a week solid of QA at the beginning of the S cycle and then make sure that we don't have any AP regressions. That'll happen in about two weeks.

Revision history for this message
MC Return (mc-return) wrote : Posted in a previous version of this proposal

> Okay, so I've talked to Didier about this and we've come up with a small plan
> of action. We'll need to give this a week solid of QA at the beginning of the
> S cycle and then make sure that we don't have any AP regressions. That'll
> happen in about two weeks.

\o/

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote : Posted in a previous version of this proposal

> This problem only happens using this branch together with the compiz branch
> and nvidia drivers (all tested versions):
> Logging in one of the tty’s (e.g.: Ctrl + Alt + F1) run a command so that the
> screen gets filled up (for example find) and switch back (e.g. Ctrl + Alt +
> F7) then the panel and launcher look like this:
> http://ubuntuone.com/3hlErb4cEnRwFSB57EuBLo
> http://ubuntuone.com/08yoXGBdaeVwlwGEZWZy3t
> (Sometimes it is not even necessary to log in or run a command)

Mh, this is something we need to fix or workaround this in any way, or we'll get a regression for bug #915265, and we don't want that at all! :/

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Is there a udev event that happens on VT switching?

On Mon, Apr 15, 2013 at 9:10 PM, Marco Trevisan (Treviño)
<mail@3v1n0.net> wrote:
>> This problem only happens using this branch together with the compiz branch
>> and nvidia drivers (all tested versions):
>> Logging in one of the tty’s (e.g.: Ctrl + Alt + F1) run a command so that the
>> screen gets filled up (for example find) and switch back (e.g. Ctrl + Alt +
>> F7) then the panel and launcher look like this:
>> http://ubuntuone.com/3hlErb4cEnRwFSB57EuBLo
>> http://ubuntuone.com/08yoXGBdaeVwlwGEZWZy3t
>> (Sometimes it is not even necessary to log in or run a command)
>
> Mh, this is something we need to fix or workaround this in any way, or we'll get a regression for bug #915265, and we don't want that at all! :/
> --
> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.

--
Sam Spilsbury

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Actually, nevermind. I can see why this would happen.

We'll just need to QueueDraw () everything on a VT switch - we used to
QueueDraw () a little overzealously before which would effectively
mask the presence of this problem. Easy enough to do, I'll see if I
can do it tonight.

On Mon, Apr 15, 2013 at 10:30 PM, Sam Spilsbury <email address hidden> wrote:
> Is there a udev event that happens on VT switching?
>
> On Mon, Apr 15, 2013 at 9:10 PM, Marco Trevisan (Treviño)
> <mail@3v1n0.net> wrote:
>>> This problem only happens using this branch together with the compiz branch
>>> and nvidia drivers (all tested versions):
>>> Logging in one of the tty’s (e.g.: Ctrl + Alt + F1) run a command so that the
>>> screen gets filled up (for example find) and switch back (e.g. Ctrl + Alt +
>>> F7) then the panel and launcher look like this:
>>> http://ubuntuone.com/3hlErb4cEnRwFSB57EuBLo
>>> http://ubuntuone.com/08yoXGBdaeVwlwGEZWZy3t
>>> (Sometimes it is not even necessary to log in or run a command)
>>
>> Mh, this is something we need to fix or workaround this in any way, or we'll get a regression for bug #915265, and we don't want that at all! :/
>> --
>> https://code.launchpad.net/~smspillaz/unity/unity.fix_1080947.2/+merge/154847
>> You are the owner of lp:~smspillaz/unity/unity.fix_1080947.2.
>
>
>
> --
> Sam Spilsbury

--
Sam Spilsbury

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

I've noticed that there's a slight race condition that can happen where override redirect windows don't seem to get added to past damage buffers.

Also I think there is a little bit of scope to get some of this code into unit tests, so its worth trying.

review: Needs Fixing
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
MC Return (mc-return) wrote : Posted in a previous version of this proposal

News:
http://support.amd.com/us/kbarticles/Pages/amdcatalyst13-6linbetadriver.aspx

AMD's fglrx 13.6 Beta driver now also supports GLX_EXT_buffer_age extension !!! \o/

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Brandon Schaefer (brandontschaefer) wrote :

LGTM

review: Approve
Revision history for this message
Christopher Townsend (townsend) wrote :

Works well for me. +1

review: Approve
Revision history for this message
Stephen M. Webb (bregma) wrote :

Dependency bump is OK.

review: Approve
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) :
review: Approve (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) :
review: Approve (continuous-integration)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'CMakeLists.txt'
2--- CMakeLists.txt 2013-11-06 06:24:49 +0000
3+++ CMakeLists.txt 2013-11-07 16:27:31 +0000
4@@ -230,7 +230,7 @@
5 libbamf3>=0.5.0
6 libnotify
7 libstartup-notification-1.0
8- nux-4.0>=4.0.1
9+ nux-4.0>=4.0.4
10 sigc++-2.0
11 unity-misc>=0.4.0
12 xpathselect=1.4
13
14=== modified file 'debian/control'
15--- debian/control 2013-11-06 06:24:49 +0000
16+++ debian/control 2013-11-07 16:27:31 +0000
17@@ -3,7 +3,7 @@
18 Priority: optional
19 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
20 Build-Depends: cmake,
21- compiz-dev (>= 1:0.9.10),
22+ compiz-dev (>= 1:0.9.11),
23 debhelper (>= 9.0.0~),
24 dbus-test-runner,
25 dh-migrations,
26@@ -18,7 +18,7 @@
27 libboost-serialization-dev,
28 libcairo2-dev,
29 libdbus-1-dev,
30- libcompizconfig0-dev (>= 1:0.9.10),
31+ libcompizconfig0-dev (>= 1:0.9.11),
32 libdbusmenu-glib-dev (>= 0.3.91),
33 libdee-dev (>= 1.2.6),
34 libgee-dev (>= 0.5.0),
35@@ -36,7 +36,7 @@
36 libnih-dbus-dev,
37 libnih-dev,
38 libnotify-dev,
39- libnux-4.0-dev (>= 4.0.2+13.10.20130718.1),
40+ libnux-4.0-dev (>= 4.0.4),
41 libpango1.0-dev,
42 libsigc++-2.0-dev,
43 libstartup-notification0-dev,
44@@ -148,7 +148,7 @@
45 libunity-core-6.0-8 (= ${binary:Version}),
46 libglib2.0-dev,
47 libsigc++-2.0-dev,
48- libnux-4.0-dev (>= 4.0.2),
49+ libnux-4.0-dev (>= 4.0.4),
50 libunity-dev (>= 7.1.0~),
51 libdee-dev,
52 Description: Core library for the Unity interface - development files
53
54=== modified file 'launcher/CairoBaseWindow.cpp'
55--- launcher/CairoBaseWindow.cpp 2013-09-30 15:08:09 +0000
56+++ launcher/CairoBaseWindow.cpp 2013-11-07 16:27:31 +0000
57@@ -74,12 +74,6 @@
58 return use_blurred_background_;
59 }
60
61-void CairoBaseWindow::NeedSoftRedraw()
62-{
63- compute_blur_bkg_ = true;
64- QueueDraw();
65-}
66-
67 void CairoBaseWindow::Draw(nux::GraphicsEngine& gfxContext, bool forceDraw)
68 {
69 nux::Geometry base(GetGeometry());
70
71=== modified file 'launcher/CairoBaseWindow.h'
72--- launcher/CairoBaseWindow.h 2013-09-30 15:08:09 +0000
73+++ launcher/CairoBaseWindow.h 2013-11-07 16:27:31 +0000
74@@ -36,7 +36,6 @@
75 virtual void Show();
76 virtual void Hide();
77
78- void NeedSoftRedraw() override;
79 bool HasBlurredBackground() const;
80
81 protected:
82
83=== modified file 'launcher/Launcher.cpp'
84--- launcher/Launcher.cpp 2013-10-29 16:05:57 +0000
85+++ launcher/Launcher.cpp 2013-11-07 16:27:31 +0000
86@@ -2402,12 +2402,6 @@
87 unity::graphics::PopOffscreenRenderTarget();
88 }
89
90-// FIXME: This will need to be removed when the Unity performance branch is merged.
91-void Launcher::NeedSoftRedraw()
92-{
93- QueueDraw();
94-}
95-
96 #ifdef NUX_GESTURES_SUPPORT
97 nux::GestureDeliveryRequest Launcher::GestureEvent(const nux::GestureEvent &event)
98 {
99
100=== modified file 'launcher/Launcher.h'
101--- launcher/Launcher.h 2013-10-29 16:05:57 +0000
102+++ launcher/Launcher.h 2013-11-07 16:27:31 +0000
103@@ -151,9 +151,6 @@
104
105 void RenderIconToTexture(nux::GraphicsEngine&, nux::ObjectPtr<nux::IOpenGLBaseTexture> const&, AbstractLauncherIcon::Ptr const&);
106
107- // FIXME: This will need to be removed when the Unity performance branch is merged.
108- void NeedSoftRedraw() override;
109-
110 #ifdef NUX_GESTURES_SUPPORT
111 virtual nux::GestureDeliveryRequest GestureEvent(const nux::GestureEvent &event);
112 #endif
113
114=== modified file 'launcher/LauncherController.cpp'
115--- launcher/LauncherController.cpp 2013-11-01 07:24:38 +0000
116+++ launcher/LauncherController.cpp 2013-11-07 16:27:31 +0000
117@@ -1064,7 +1064,7 @@
118 , multiple_launchers(true)
119 , pimpl(new Impl(this, xdnd_manager, edge_barriers))
120 {
121- multiple_launchers.changed.connect([&](bool value) -> void {
122+ multiple_launchers.changed.connect([this] (bool value) {
123 UScreen* uscreen = UScreen::GetDefault();
124 auto monitors = uscreen->GetMonitors();
125 int primary = uscreen->GetPrimaryMonitor();
126@@ -1163,7 +1163,7 @@
127 {
128 pimpl->launcher_key_press_time_ = when;
129
130- auto show_launcher = [&]()
131+ auto show_launcher = [this]
132 {
133 if (pimpl->keyboard_launcher_.IsNull())
134 pimpl->keyboard_launcher_ = pimpl->CurrentLauncher();
135@@ -1176,7 +1176,7 @@
136 };
137 pimpl->sources_.AddTimeout(options()->super_tap_duration, show_launcher, local::KEYPRESS_TIMEOUT);
138
139- auto show_shortcuts = [&]()
140+ auto show_shortcuts = [this]
141 {
142 if (!pimpl->launcher_keynav)
143 {
144@@ -1232,7 +1232,7 @@
145 {
146 int time_left = local::launcher_minimum_show_duration - ms_since_show;
147
148- auto hide_launcher = [&]()
149+ auto hide_launcher = [this]
150 {
151 if (pimpl->keyboard_launcher_.IsValid())
152 {
153
154=== modified file 'launcher/XdndCollectionWindowImp.cpp'
155--- launcher/XdndCollectionWindowImp.cpp 2013-10-14 15:58:38 +0000
156+++ launcher/XdndCollectionWindowImp.cpp 2013-11-07 16:27:31 +0000
157@@ -38,6 +38,10 @@
158 auto uscreen = UScreen::GetDefault();
159 SetGeometry(uscreen->GetScreenGeometry());
160
161+ // We are not calling ShowWindow () as this window
162+ // isn't really visible
163+ PushToBack();
164+
165 if (nux::GetWindowThread()->IsEmbeddedWindow())
166 {
167 // Hack to create the X Window as soon as possible.
168
169=== modified file 'panel/PanelView.cpp'
170--- panel/PanelView.cpp 2013-10-29 16:05:57 +0000
171+++ panel/PanelView.cpp 2013-11-07 16:27:31 +0000
172@@ -787,10 +787,4 @@
173 return ui::EdgeBarrierSubscriber::Result::NEEDS_RELEASE;
174 }
175
176-// FIXME: This will need to be removed when the Unity performance branch is merged.
177-void PanelView::NeedSoftRedraw()
178-{
179- QueueDraw();
180-}
181-
182 } // namespace unity
183
184=== modified file 'panel/PanelView.h'
185--- panel/PanelView.h 2013-10-29 16:05:57 +0000
186+++ panel/PanelView.h 2013-11-07 16:27:31 +0000
187@@ -78,9 +78,6 @@
188
189 ui::EdgeBarrierSubscriber::Result HandleBarrierEvent(ui::PointerBarrierWrapper* owner, ui::BarrierEvent::Ptr event) override;
190
191- // FIXME: This will need to be removed when the Unity performance branch is merged.
192- void NeedSoftRedraw() override;
193-
194 protected:
195 void Draw(nux::GraphicsEngine& GfxContext, bool force_draw);
196 void DrawContent(nux::GraphicsEngine& GfxContext, bool force_draw);
197
198=== modified file 'plugins/unityshell/src/unityshell.cpp'
199--- plugins/unityshell/src/unityshell.cpp 2013-11-07 11:45:40 +0000
200+++ plugins/unityshell/src/unityshell.cpp 2013-11-07 16:27:31 +0000
201@@ -81,6 +81,8 @@
202 /* Set up vtable symbols */
203 COMPIZ_PLUGIN_20090315(unityshell, unity::UnityPluginVTable);
204
205+namespace cgl = compiz::opengl;
206+
207 namespace unity
208 {
209 using namespace launcher;
210@@ -142,6 +144,7 @@
211 , allowWindowPaint(false)
212 , _key_nav_mode_requested(false)
213 , _last_output(nullptr)
214+ , force_draw_countdown_ (0)
215 , grab_index_ (0)
216 , painting_tray_ (false)
217 , last_scroll_event_(0)
218@@ -151,6 +154,9 @@
219 , scale_just_activated_(false)
220 , big_tick_(0)
221 , screen_introspection_(screen)
222+ , ignore_redraw_request_(false)
223+ , dirty_helpers_on_this_frame_(false)
224+ , back_buffer_age_(0)
225 , is_desktop_active_(false)
226 {
227 Timer timer;
228@@ -392,6 +398,11 @@
229 XSelectInput(display, GDK_ROOT_WINDOW(), PropertyChangeMask);
230 LOG_INFO(logger) << "UnityScreen constructed: " << timer.ElapsedSeconds() << "s";
231
232+ UScreen::GetDefault()->resuming.connect([this]() {
233+ /* Force paint 10 frames on resume */
234+ this->force_draw_countdown_ += 10;
235+ });
236+
237 panel::Style::Instance().changed.connect(sigc::mem_fun(this, &UnityScreen::OnPanelStyleChanged));
238
239 minimize_speed_controller_.DurationChanged.connect(
240@@ -401,8 +412,13 @@
241 WindowManager& wm = WindowManager::Default();
242 wm.initiate_spread.connect(sigc::mem_fun(this, &UnityScreen::OnInitiateSpread));
243 wm.terminate_spread.connect(sigc::mem_fun(this, &UnityScreen::OnTerminateSpread));
244+ wm.initiate_expo.connect(sigc::mem_fun(this, &UnityScreen::DamagePanelShadow));
245+ wm.terminate_expo.connect(sigc::mem_fun(this, &UnityScreen::DamagePanelShadow));
246
247 AddChild(&screen_introspection_);
248+
249+ /* Track whole damage on the very first frame */
250+ cScreen->damageScreen();
251 }
252 }
253
254@@ -477,6 +493,27 @@
255 UnityWindow::CleanupSharedTextures();
256 }
257
258+void UnityScreen::DamagePanelShadow()
259+{
260+ CompRect panelShadow;
261+
262+ for (CompOutput const& output : screen->outputDevs())
263+ {
264+ FillShadowRectForOutput(panelShadow, output);
265+ cScreen->damageRegion(CompRegion(panelShadow));
266+ }
267+}
268+
269+void UnityScreen::OnViewHidden(nux::BaseWindow *bw)
270+{
271+ /* Count this as regular damage */
272+ nux::Geometry geometry(bw->GetAbsoluteGeometry());
273+ cScreen->damageRegion(CompRegion (geometry.x,
274+ geometry.y,
275+ geometry.width,
276+ geometry.height));
277+}
278+
279 void UnityScreen::EnsureSuperKeybindings()
280 {
281 for (auto action : _shortcut_actions)
282@@ -569,6 +606,20 @@
283 panel_shadow_matrix_ = matrix;
284 }
285
286+void UnityScreen::FillShadowRectForOutput(CompRect &shadowRect,
287+ CompOutput const &output)
288+{
289+ if (_shadow_texture.empty ())
290+ return;
291+
292+ float panel_h = static_cast<float>(panel_style_.panel_height);
293+ float shadowX = output.x();
294+ float shadowY = output.y() + panel_h;
295+ float shadowWidth = output.width();
296+ float shadowHeight = _shadow_texture[0]->height();
297+ shadowRect.setGeometry(shadowX, shadowY, shadowWidth, shadowHeight);
298+}
299+
300 void UnityScreen::paintPanelShadow(CompRegion const& clip)
301 {
302 // You have no shadow texture. But how?
303@@ -596,11 +647,8 @@
304 return;
305 }
306
307- int shadowX = output->x();
308- int shadowY = output->y() + panel_style_.panel_height;
309- int shadowWidth = output->width();
310- int shadowHeight = _shadow_texture[0]->height();
311- CompRect shadowRect(shadowX, shadowY, shadowWidth, shadowHeight);
312+ CompRect shadowRect;
313+ FillShadowRectForOutput(shadowRect, *output);
314
315 CompRegion redraw(clip);
316 redraw &= shadowRect;
317@@ -640,10 +688,10 @@
318 float y2 = r.y2();
319
320 // Texture coordinates of the above rectangle:
321- float tx1 = (x1 - shadowX) / shadowWidth;
322- float ty1 = (y1 - shadowY) / shadowHeight;
323- float tx2 = (x2 - shadowX) / shadowWidth;
324- float ty2 = (y2 - shadowY) / shadowHeight;
325+ float tx1 = (x1 - shadowRect.x()) / shadowRect.width();
326+ float ty1 = (y1 - shadowRect.y()) / shadowRect.height();
327+ float tx2 = (x2 - shadowRect.x()) / shadowRect.width();
328+ float ty2 = (y2 - shadowRect.y()) / shadowRect.height();
329
330 vertexData = {
331 x1, y1, 0,
332@@ -707,25 +755,41 @@
333
334 DrawPanelUnderDash();
335
336- if (BackgroundEffectHelper::HasDirtyHelpers())
337+ /* Bind the currently bound draw framebuffer to the read framebuffer binding.
338+ * The reason being that we want to use the results of nux images being
339+ * drawn to this framebuffer in glCopyTexSubImage2D operations */
340+ GLint current_draw_binding = 0,
341+ old_read_binding = 0;
342+#ifndef USE_GLES
343+ glGetIntegerv(GL_READ_FRAMEBUFFER_BINDING_EXT, &old_read_binding);
344+ glGetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING_EXT, &current_draw_binding);
345+ if (old_read_binding != current_draw_binding)
346+ (*GL::bindFramebuffer) (GL_READ_FRAMEBUFFER_BINDING_EXT, current_draw_binding);
347+#else
348+ glGetIntegerv(GL_FRAMEBUFFER_BINDING, &current_draw_binding);
349+ glGetIntegerv(GL_FRAMEBUFFER_BINDING, &old_read_binding);
350+#endif
351+
352+ /* If we have dirty helpers re-copy the backbuffer
353+ * into a texture
354+ *
355+ * TODO: Make this faster by only copying the bits we
356+ * need as opposed to the whole readbuffer */
357+ if (dirty_helpers_on_this_frame_)
358 {
359 auto gpu_device = nux::GetGraphicsDisplay()->GetGpuDevice();
360 auto graphics_engine = nux::GetGraphicsDisplay()->GetGraphicsEngine();
361-
362- nux::ObjectPtr<nux::IOpenGLTexture2D> bg_texture =
363- graphics_engine->CreateTextureFromBackBuffer(0, 0,
364- screen->width(),
365- screen->height());
366- gpu_device->backup_texture0_ = bg_texture;
367+ gpu_device->backup_texture0_ =
368+ graphics_engine->CreateTextureFromBackBuffer(0, 0, screen->width(), screen->height());
369+ back_buffer_age_ = 0;
370 }
371
372 nux::Geometry outputGeo(output->x (), output->y (), output->width (), output->height ());
373 BackgroundEffectHelper::monitor_rect_.Set(0, 0, screen->width(), screen->height());
374
375- GLint fboID;
376- // Nux renders to the referenceFramebuffer when it's embedded.
377- glGetIntegerv(GL_FRAMEBUFFER_BINDING, &fboID);
378- wt->GetWindowCompositor().SetReferenceFramebuffer(fboID, fboID, outputGeo);
379+ wt->GetWindowCompositor().SetReferenceFramebuffer(current_draw_binding,
380+ old_read_binding,
381+ outputGeo);
382
383 nuxPrologue();
384 wt->RenderInterfaceFromForeignCmd (outputGeo);
385@@ -1246,6 +1310,7 @@
386 doShellRepaint = force ||
387 ( !region.isEmpty() &&
388 ( !wt->GetDrawList().empty() ||
389+ !wt->GetPresentationListGeometries().empty() ||
390 (mask & PAINT_SCREEN_FULL_MASK)
391 )
392 );
393@@ -1281,10 +1346,142 @@
394 unsigned int mask)
395 {
396 allowWindowPaint = false;
397+
398+ /* PAINT_SCREEN_FULL_MASK means that we are ignoring the damage
399+ * region and redrawing the whole screen, so we should make all
400+ * nux windows be added to the presentation list that intersect
401+ * this output.
402+ *
403+ * However, damaging nux has a side effect of notifying compiz
404+ * through onRedrawRequested that we need to queue another frame.
405+ * In most cases that would be desirable, and in the case where
406+ * we did that in damageCutoff, it would not be a problem as compiz
407+ * does not queue up new frames for damage that can be processed
408+ * on the current frame. However, we're now past damage cutoff, but
409+ * a change in circumstances has required that we redraw all the nux
410+ * windows on this frame. As such, we need to ensure that damagePending
411+ * is not called as a result of queuing windows for redraw, as that
412+ * would effectively result in a damage feedback loop in plugins that
413+ * require screen transformations (eg, new frame -> plugin redraws full
414+ * screen -> we reach this point and request another redraw implicitly)
415+ */
416+ if (mask & PAINT_SCREEN_FULL_MASK)
417+ {
418+ ignore_redraw_request_ = true;
419+ compizDamageNux(CompRegionRef(output->region()));
420+ ignore_redraw_request_ = false;
421+
422+ /* Fetch all the presentation list geometries - this will have the side
423+ * effect of clearing any built-up damage state */
424+ std::vector<nux::Geometry> dirty = wt->GetPresentationListGeometries();
425+ }
426+
427 gScreen->glPaintTransformedOutput(attrib, transform, region, output, mask);
428 paintPanelShadow(region);
429 }
430
431+void UnityScreen::updateBlurDamage()
432+{
433+ /* If there are enabled helpers, we want to apply damage
434+ * based on how old our tracking fbo is since we may need
435+ * to redraw some of the blur regions if there has been
436+ * damage since we last bound it
437+ *
438+ * XXX: Unfortunately there's a nasty feedback loop here, and not
439+ * a whole lot we can do about it. If part of the damage from any frame
440+ * intersects a nux window, we have to mark the entire region that the
441+ * nux window covers as damaged, because nux does not have any concept
442+ * of geometry clipping. That damage will feed back to us on the next frame.
443+ */
444+ if (BackgroundEffectHelper::HasEnabledHelpers())
445+ {
446+ cScreen->applyDamageForFrameAge(back_buffer_age_);
447+
448+ /*
449+ * Prioritise user interaction over active blur updates. So the general
450+ * slowness of the active blur doesn't affect the UI interaction performance.
451+ *
452+ * Also, BackgroundEffectHelper::ProcessDamage() is causing a feedback loop
453+ * while the dash is open. Calling it results in the NEXT frame (and the
454+ * current one?) to get some damage. This GetDrawList().empty() check avoids
455+ * that feedback loop and allows us to idle correctly.
456+ *
457+ * We are doing damage processing for the blurs here, as this represents
458+ * the most up to date compiz damage under the nux windows.
459+ */
460+ if (wt->GetDrawList().empty())
461+ {
462+ CompRect::vector const& rects(buffered_compiz_damage_this_frame_.rects());
463+ for (CompRect const& r : rects)
464+ {
465+ nux::Geometry geo(r.x(), r.y(), r.width(), r.height());
466+ BackgroundEffectHelper::ProcessDamage(geo);
467+ }
468+ }
469+ }
470+}
471+
472+void UnityScreen::damageCutoff()
473+{
474+ if (force_draw_countdown_)
475+ {
476+ typedef nux::WindowCompositor::WeakBaseWindowPtr WeakBaseWindowPtr;
477+
478+ /* We have to force-redraw the whole scene because
479+ * of a bug in the nvidia driver that causes framebuffers
480+ * to be trashed on resume for a few swaps */
481+ wt->GetWindowCompositor().ForEachBaseWindow([](WeakBaseWindowPtr const &w) {
482+ w->QueueDraw();
483+ });
484+
485+ force_draw_countdown_--;
486+ }
487+
488+ /* At this point we want to take all of the compiz damage
489+ * for this frame and use it to determine which blur regions
490+ * need to be redrawn. We don't want to do this any later because
491+ * the nux damage is logically on top of the blurs and doesn't
492+ * affect them */
493+ updateBlurDamage();
494+
495+ /* Determine nux region damage last */
496+ cScreen->damageCutoff();
497+
498+ CompRegion damage_buffer, last_damage_buffer;
499+
500+ do
501+ {
502+ last_damage_buffer = damage_buffer;
503+
504+ /* First apply any damage accumulated to nux to see
505+ * what windows need to be redrawn there */
506+ compizDamageNux(buffered_compiz_damage_this_frame_);
507+
508+ /* Apply the redraw regions to compiz so that we can
509+ * draw this frame with that region included */
510+ determineNuxDamage(damage_buffer);
511+
512+ /* We want to track the nux damage here as we will use it to
513+ * determine if we need to present other nux windows too */
514+ cScreen->damageRegion(damage_buffer);
515+
516+ /* If we had to put more damage into the damage buffer then
517+ * damage compiz with it and keep going */
518+ } while (last_damage_buffer != damage_buffer);
519+
520+ /* Clear damage buffer */
521+ buffered_compiz_damage_last_frame_ = buffered_compiz_damage_this_frame_;
522+ buffered_compiz_damage_this_frame_ = CompRegion();
523+
524+ /* Tell nux that any damaged windows should be redrawn on the next
525+ * frame and not this one */
526+ wt->ForeignFrameCutoff();
527+
528+ /* We need to track this per-frame to figure out whether or not
529+ * to bind the contents fbo on each monitor pass */
530+ dirty_helpers_on_this_frame_ = BackgroundEffectHelper::HasDirtyHelpers();
531+}
532+
533 void UnityScreen::preparePaint(int ms)
534 {
535 cScreen->preparePaint(ms);
536@@ -1298,8 +1495,6 @@
537 didShellRepaint = false;
538 panelShadowPainted = CompRegion();
539 firstWindowAboveShell = NULL;
540-
541- compizDamageNux(cScreen->currentDamage());
542 }
543
544 void UnityScreen::donePaint()
545@@ -1313,11 +1508,22 @@
546 * I think this is a Nux bug. ClearDrawList should ideally also mark all
547 * the queued views as draw_cmd_queued_=false.
548 */
549+
550+ /* To prevent any potential overflow problems, we are assuming here
551+ * that compiz caps the maximum number of frames tracked at 10, so
552+ * don't increment the age any more than 11 */
553+ if (back_buffer_age_ < 11)
554+ ++back_buffer_age_;
555+
556 if (didShellRepaint)
557 wt->ClearDrawList();
558
559+ /* Tell nux that a new frame is now beginning and any damaged windows should
560+ * now be painted on this frame */
561+ wt->ForeignFrameEnded();
562+
563 if (animation_controller_->HasRunningAnimations())
564- nuxDamageCompiz();
565+ onRedrawRequested();
566
567 for (auto it = ShowdesktopHandler::animating_windows.begin(); it != ShowdesktopHandler::animating_windows.end();)
568 {
569@@ -1341,89 +1547,52 @@
570 cScreen->donePaint();
571 }
572
573-void redraw_view_if_damaged(nux::ObjectPtr<nux::View> const& view, CompRegion const& damage)
574-{
575- if (!view || view->IsRedrawNeeded())
576- return;
577-
578- auto const& geo = view->GetAbsoluteGeometry();
579- CompRegion region(geo.x, geo.y, geo.width, geo.height);
580-
581- if (damage.intersects(region))
582- view->NeedSoftRedraw();
583-}
584-
585 void UnityScreen::compizDamageNux(CompRegion const& damage)
586 {
587- if (!launcher_controller_)
588- return;
589-
590- /*
591- * Prioritise user interaction over active blur updates. So the general
592- * slowness of the active blur doesn't affect the UI interaction performance.
593- *
594- * Also, BackgroundEffectHelper::ProcessDamage() is causing a feedback loop
595- * while the dash is open. Calling it results in the NEXT frame (and the
596- * current one?) to get some damage. This GetDrawList().empty() check avoids
597- * that feedback loop and allows us to idle correctly.
598+ /* Ask nux to present anything in our damage region
599+ *
600+ * Note: This is using a new nux API, to "present" windows
601+ * to the screen, as opposed to drawing them. The difference is
602+ * important. The former will just draw the window backing texture
603+ * directly to the screen, the latter will re-draw the entire window.
604+ *
605+ * The former is a lot faster, do not use QueueDraw unless the contents
606+ * of the window need to be re-drawn.
607 */
608- if (wt->GetDrawList().empty() && BackgroundEffectHelper::HasDamageableHelpers())
609- {
610- CompRect::vector const& rects(damage.rects());
611- for (CompRect const& r : rects)
612- {
613- nux::Geometry geo(r.x(), r.y(), r.width(), r.height());
614- BackgroundEffectHelper::ProcessDamage(geo);
615- }
616- }
617-
618- if (dash_controller_->IsVisible())
619- redraw_view_if_damaged(dash_controller_->Dash(), damage);
620-
621- if (hud_controller_->IsVisible())
622- redraw_view_if_damaged(hud_controller_->HudView(), damage);
623-
624- auto const& launchers = launcher_controller_->launchers();
625- for (auto const& launcher : launchers)
626- {
627- if (!launcher->Hidden())
628- {
629- redraw_view_if_damaged(launcher, damage);
630- redraw_view_if_damaged(launcher->GetActiveTooltip(), damage);
631- redraw_view_if_damaged(launcher->GetDraggedIcon(), damage);
632- }
633- }
634-
635- for (auto const& panel : panel_controller_->panels())
636- redraw_view_if_damaged(panel, damage);
637-
638- if (QuicklistManager* qm = QuicklistManager::Default())
639- redraw_view_if_damaged(qm->Current(), damage);
640-
641- if (switcher_controller_->Visible())
642- redraw_view_if_damaged(switcher_controller_->GetView(), damage);
643+ CompRect::vector rects (damage.rects());
644+ for (const CompRect &r : rects)
645+ {
646+ nux::Geometry g(r.x(), r.y(), r.width(), r.height());
647+ wt->PresentWindowsIntersectingGeometryOnThisFrame(g);
648+ }
649 }
650
651 /* Grab changed nux regions and add damage rects for them */
652-void UnityScreen::nuxDamageCompiz()
653+void UnityScreen::determineNuxDamage(CompRegion &nux_damage)
654 {
655- /*
656- * If Nux is going to redraw anything then we have to tell Compiz to
657- * redraw everything. This is because Nux has a bad habit (bug??) of drawing
658- * more than just the regions of its DrawList. (LP: #1036519)
659- *
660- * Forunately, this does not happen on most frames. Only when the Unity
661- * Shell needs to redraw something.
662- *
663- * TODO: Try to figure out why redrawing the panel makes the launcher also
664- * redraw even though the launcher's geometry is not in DrawList, and
665- * stop it. Then maybe we can revert back to the old code below #else.
666- */
667- if (!wt->GetDrawList().empty() || animation_controller_->HasRunningAnimations())
668+ /* Fetch all the dirty geometry from nux and aggregate it */
669+ std::vector<nux::Geometry> dirty = wt->GetPresentationListGeometries();
670+
671+ for (auto const& geo : dirty)
672+ nux_damage += CompRegion(geo.x, geo.y, geo.width, geo.height);
673+
674+ /* Special case, we need to redraw the panel shadow on panel updates */
675+ for (auto const& panel_geo : panel_controller_->GetGeometries())
676 {
677- cScreen->damageRegionSetEnabled(this, false);
678- cScreen->damageScreen();
679- cScreen->damageRegionSetEnabled(this, true);
680+ CompRect panel_rect(panel_geo.x,
681+ panel_geo.y,
682+ panel_geo.width,
683+ panel_geo.height);
684+
685+ if (nux_damage.intersects(panel_rect))
686+ {
687+ foreach (CompOutput const& o, screen->outputDevs())
688+ {
689+ CompRect shadowRect;
690+ FillShadowRectForOutput(shadowRect, o);
691+ nux_damage += shadowRect;
692+ }
693+ }
694 }
695 }
696
697@@ -1689,7 +1858,7 @@
698
699 void UnityScreen::damageRegion(const CompRegion &region)
700 {
701- compizDamageNux(region);
702+ buffered_compiz_damage_this_frame_ += region;
703 cScreen->damageRegion(region);
704 }
705
706@@ -2985,11 +3154,16 @@
707 nux::ColorLayer background(nux::color::Transparent);
708 static_cast<nux::WindowThread*>(thread)->SetWindowBackgroundPaintLayer(&background);
709 LOG_INFO(logger) << "UnityScreen::initUnity: " << timer.ElapsedSeconds() << "s";
710+
711+ nux::GetWindowCompositor()
712+ .sigHiddenViewWindow.connect(sigc::mem_fun(self,
713+ &UnityScreen::OnViewHidden));
714 }
715
716 void UnityScreen::onRedrawRequested()
717 {
718- nuxDamageCompiz();
719+ if (!ignore_redraw_request_)
720+ cScreen->damagePending();
721 }
722
723 /* Handle option changes and plug that into nux windows */
724@@ -3179,6 +3353,8 @@
725 << " h=" << geo.height;
726
727 needsRelayout = false;
728+
729+ DamagePanelShadow();
730 }
731
732 /* Handle changes in the number of workspaces by showing the switcher
733
734=== modified file 'plugins/unityshell/src/unityshell.h'
735--- plugins/unityshell/src/unityshell.h 2013-11-01 07:24:38 +0000
736+++ plugins/unityshell/src/unityshell.h 2013-11-07 16:27:31 +0000
737@@ -111,9 +111,11 @@
738
739 /* nux draw wrapper */
740 void paintDisplay();
741- void paintPanelShadow(const CompRegion& clip);
742+ void paintPanelShadow(CompRegion const& clip);
743 void setPanelShadowMatrix(const GLMatrix& matrix);
744
745+ void updateBlurDamage();
746+ void damageCutoff();
747 void preparePaint (int ms);
748 void paintFboForOutput (CompOutput *output);
749 void donePaint ();
750@@ -232,7 +234,7 @@
751 void initLauncher();
752
753 void compizDamageNux(CompRegion const& region);
754- void nuxDamageCompiz();
755+ void determineNuxDamage(CompRegion &nux_damage);
756
757 void onRedrawRequested();
758 void Relayout();
759@@ -254,6 +256,12 @@
760 void OnInitiateSpread();
761 void OnTerminateSpread();
762
763+ void DamagePanelShadow();
764+
765+ void OnViewHidden(nux::BaseWindow *bw);
766+
767+ void RestoreWindow(GVariant* data);
768+
769 bool SaveInputThenFocus(const guint xid);
770
771 void OnPanelStyleChanged();
772@@ -262,6 +270,8 @@
773
774 void DrawPanelUnderDash();
775
776+ void FillShadowRectForOutput(CompRect &shadowRect,
777+ CompOutput const &output);
778 unsigned CompizModifiersToNux(unsigned input) const;
779 unsigned XModifiersToNux(unsigned input) const;
780
781@@ -322,6 +332,12 @@
782 bool _key_nav_mode_requested;
783 CompOutput* _last_output;
784
785+ /* a small count-down work-a-around
786+ * to force full redraws of the shell
787+ * a certain number of frames after a
788+ * suspend / resume cycle */
789+ unsigned int force_draw_countdown_;
790+
791 CompRegion panelShadowPainted;
792 CompRegion nuxRegion;
793 CompRegion fullscreenRegion;
794@@ -355,6 +371,13 @@
795 UBusManager ubus_manager_;
796 glib::SourceManager sources_;
797
798+ CompRegion buffered_compiz_damage_this_frame_;
799+ CompRegion buffered_compiz_damage_last_frame_;
800+ bool ignore_redraw_request_;
801+ bool dirty_helpers_on_this_frame_;
802+
803+ unsigned int back_buffer_age_;
804+
805 bool is_desktop_active_;
806
807 friend class UnityWindow;
808
809=== modified file 'unity-shared/BackgroundEffectHelper.cpp'
810--- unity-shared/BackgroundEffectHelper.cpp 2013-04-13 01:26:06 +0000
811+++ unity-shared/BackgroundEffectHelper.cpp 2013-11-07 16:27:31 +0000
812@@ -74,7 +74,7 @@
813 if (bg_effect_helper->cache_dirty || !bg_effect_helper->owner || !bg_effect_helper->enabled)
814 continue;
815
816- if (!geo.Intersect(bg_effect_helper->blur_geometry_).IsNull())
817+ if (geo.IsIntersecting(bg_effect_helper->blur_geometry_))
818 {
819 bg_effect_helper->DirtyCache();
820 }
821
822=== modified file 'unity-shared/PlacesOverlayVScrollBar.cpp'
823--- unity-shared/PlacesOverlayVScrollBar.cpp 2013-09-30 20:16:36 +0000
824+++ unity-shared/PlacesOverlayVScrollBar.cpp 2013-11-07 16:27:31 +0000
825@@ -209,9 +209,8 @@
826 {
827 nux::Geometry const& slider_geo = _slider->GetAbsoluteGeometry();
828 nux::Geometry const& thumb_geo = overlay_window_->GetThumbGeometry();
829- nux::Geometry const& intersection = (thumb_geo.Intersect(slider_geo));
830
831- if (!intersection.IsNull())
832+ if (thumb_geo.IsIntersecting(slider_geo))
833 {
834 ResetConnector();
835 overlay_window_->ThumbInsideSlider();
836
837=== modified file 'unity-shared/PluginAdapter.cpp'
838--- unity-shared/PluginAdapter.cpp 2013-10-11 21:51:32 +0000
839+++ unity-shared/PluginAdapter.cpp 2013-11-07 16:27:31 +0000
840@@ -573,7 +573,7 @@
841 && sibling->isMapped()
842 && sibling->isViewable()
843 && (sibling->state() & MAXIMIZE_STATE) == MAXIMIZE_STATE
844- && !GetWindowGeometry(sibling->id()).Intersect(win_geo).IsNull())
845+ && GetWindowGeometry(sibling->id()).IsIntersecting(win_geo))
846 {
847 return true;
848 }