Merge lp:~smspillaz/unity/unity.fix_1080947.2 into lp:unity

[Sam Spilsbury]

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)

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.

[Andrea Azzarone (azzar1)]

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?

[Andrea Azzarone (azzar1)]

*crashes

[Sam Spilsbury (smspillaz)]

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.

[Sam Spilsbury (smspillaz)]

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?

[Andrea Azzarone (azzar1)]

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! :)

[Sam Spilsbury (smspillaz)]

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.
>

[Andrea Azzarone (azzar1)]

> 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.
> >

[Sam Spilsbury (smspillaz)]

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

[Andrea Azzarone (azzar1)]

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?

[Sam Spilsbury (smspillaz)]

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.
>

[Sam Spilsbury (smspillaz)]

Okay, all updated as requested.

[Andrea Azzarone (azzar1)]

> Okay, all updated as requested.

I'll try again tomorrow.

[Andrea Azzarone (azzar1)]

Looks good now. Please remove this line too:

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

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

[Sam Spilsbury (smspillaz)]

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

[Sam Spilsbury (smspillaz)]

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.

[Andrea Azzarone (azzar1)]

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

[Sam Spilsbury (smspillaz)]

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

[Sam Spilsbury (smspillaz)]

Okay, should be all fixed.

[Andrea Azzarone (azzar1)]

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

[Sam Spilsbury (smspillaz)]

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.
>

[Alfred E. Neumayer (beidl)]

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.

[Sam Spilsbury (smspillaz)]

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

[Alfred E. Neumayer (beidl)]

> 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.

[Sam Spilsbury (smspillaz)]

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

[Andrea Azzarone (azzar1)]

> 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. :)

[Sam Spilsbury (smspillaz)]

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

[Andrea Azzarone (azzar1)]

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

@Sam, how many lines of code?

[Sam Spilsbury (smspillaz)]

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

[Alfred E. Neumayer (beidl)]

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.

[Andrea Azzarone (azzar1)]

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

[Andrea Azzarone (azzar1)]

review: Approve

[Sam Spilsbury (smspillaz)]

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

[MC Return (mc-return)]

> review: Approve

Hurra \o/

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

I think he mentioned Intel HD 4000 above ^^

[Sam Spilsbury (smspillaz)]

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.

[Alfred E. Neumayer (beidl)]

> > 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

[Andrea Azzarone (azzar1)]

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

[MC Return (mc-return)]

> 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 ?

[Sam Spilsbury (smspillaz)]

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

[Sam Spilsbury (smspillaz)]

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

[Andrea Azzarone (azzar1)]

> > 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.

[Alfred E. Neumayer (beidl)]

> 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.

[Andrea Azzarone (azzar1)]

> > 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?

[Alfred E. Neumayer (beidl)]

> > > 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. :)

[MC Return (mc-return)]

> 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 ?

[Sam Spilsbury (smspillaz)]

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

[Esokrates (esokrarkose)]

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)

[Sam Spilsbury (smspillaz)]

> 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.

[Sam Spilsbury (smspillaz)]

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.

[MC Return (mc-return)]

> 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/

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3259
http://jenkins.qa.ubuntu.com/job/unity-ci/9/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/9/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/9/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/9/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/9/rebuild

review: Needs Fixing (continuous-integration)

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3260
http://jenkins.qa.ubuntu.com/job/unity-ci/14/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/14/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/14/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/14/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/14/rebuild

review: Needs Fixing (continuous-integration)

[Marco Trevisan (Treviño) (3v1n0)]

> 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! :/

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3261
http://jenkins.qa.ubuntu.com/job/unity-ci/15/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/15/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/15/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/15/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/15/rebuild

review: Needs Fixing (continuous-integration)

[Sam Spilsbury (smspillaz)]

Is there a udev event that happens on VT switching?

On Mon, Apr 15, 2013 at 9:10 PM, Marco Trevisan (Treviño)
<[e-mail]> 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 (smspillaz)]

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)
> <[e-mail]> 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

[Sam Spilsbury (smspillaz)]

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

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3267
http://jenkins.qa.ubuntu.com/job/unity-ci/50/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/50/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/50/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/50/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/50/rebuild

review: Needs Fixing (continuous-integration)

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3269
http://jenkins.qa.ubuntu.com/job/unity-ci/52/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/52/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/52/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/52/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/52/rebuild

review: Needs Fixing (continuous-integration)

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3271
http://jenkins.qa.ubuntu.com/job/unity-ci/57/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/57/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/57/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/57/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/57/rebuild

review: Needs Fixing (continuous-integration)

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3272
http://jenkins.qa.ubuntu.com/job/unity-ci/59/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/59/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/59/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/59/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/59/rebuild

review: Needs Fixing (continuous-integration)

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3273
http://jenkins.qa.ubuntu.com/job/unity-ci/69/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/73/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/69/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/69/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/69/rebuild

review: Needs Fixing (continuous-integration)

[PS Jenkins bot (ps-jenkins)]

FAILED: Continuous integration, rev:3275
http://jenkins.qa.ubuntu.com/job/unity-ci/91/
Executed test runs:
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-amd64-ci/95/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-armhf-ci/91/console
    FAILURE: http://jenkins.qa.ubuntu.com/job/unity-raring-i386-ci/91/console

Click here to trigger a rebuild:
http://s-jenkins:8080/job/unity-ci/91/rebuild

review: Needs Fixing (continuous-integration)

=== modified file 'launcher/MockLauncherIcon.h'
--- launcher/MockLauncherIcon.h	2013-05-17 16:02:09 +0000
+++ launcher/MockLauncherIcon.h	2013-05-20 16:09:26 +0000
@@ -365,6 +365,8 @@
       g_error_free(error);
     }
 
+    gtk_icon_info_free(info);
+
     return result;
   }
 
 
=== modified file 'launcher/XdndCollectionWindowImp.cpp'
--- launcher/XdndCollectionWindowImp.cpp	2013-04-11 05:15:36 +0000
+++ launcher/XdndCollectionWindowImp.cpp	2013-05-20 16:09:26 +0000
@@ -38,6 +38,10 @@
     auto uscreen = UScreen::GetDefault();
     SetGeometry(uscreen->GetScreenGeometry());
 
+    // We are not calling ShowWindow () as this window
+    // isn't really visible
+    PushToBack();
+
     if (nux::GetWindowThread()->IsEmbeddedWindow())
     {
       // Hack to create the X Window as soon as possible.
 
=== modified file 'plugins/unityshell/src/unityshell.cpp'
--- plugins/unityshell/src/unityshell.cpp	2013-05-10 05:16:07 +0000
+++ plugins/unityshell/src/unityshell.cpp	2013-05-20 16:09:26 +0000
@@ -79,6 +79,8 @@
 /* Set up vtable symbols */
 COMPIZ_PLUGIN_20090315(unityshell, unity::UnityPluginVTable);
 
+namespace cgl = compiz::opengl;
+
 namespace unity
 {
 using namespace launcher;
@@ -140,6 +142,7 @@
   , allowWindowPaint(false)
   , _key_nav_mode_requested(false)
   , _last_output(nullptr)
+  , force_draw_countdown_ (0)
   , grab_index_ (0)
   , painting_tray_ (false)
   , last_scroll_event_(0)
@@ -149,6 +152,9 @@
   , scale_just_activated_(false)
   , big_tick_(0)
   , screen_introspection_(screen)
+  , ignore_redraw_request_(false)
+  , dirty_helpers_on_this_frame_(false)
+  , back_buffer_age_(0)
 {
   Timer timer;
 #ifndef USE_GLES
@@ -403,6 +409,11 @@
     XSelectInput(display, GDK_ROOT_WINDOW(), PropertyChangeMask);
     LOG_INFO(logger) << "UnityScreen constructed: " << timer.ElapsedSeconds() << "s";
 
+    UScreen::GetDefault()->resuming.connect([this]() {
+      /* Force paint 10 frames on resume */
+      this->force_draw_countdown_ += 10;
+    });
+
     panel::Style::Instance().changed.connect(sigc::mem_fun(this, &UnityScreen::OnPanelStyleChanged));
 
     minimize_speed_controller_.DurationChanged.connect(
@@ -412,8 +423,13 @@
     WindowManager& wm = WindowManager::Default();
     wm.initiate_spread.connect(sigc::mem_fun(this, &UnityScreen::OnInitiateSpread));
     wm.terminate_spread.connect(sigc::mem_fun(this, &UnityScreen::OnTerminateSpread));
+    wm.initiate_expo.connect(sigc::mem_fun(this, &UnityScreen::DamagePanelShadow));
+    wm.terminate_expo.connect(sigc::mem_fun(this, &UnityScreen::DamagePanelShadow));
 
     AddChild(&screen_introspection_);
+
+    /* Track whole damage on the very first frame */
+    cScreen->damageScreen();
   }
 }
 
@@ -488,6 +504,27 @@
   UnityWindow::CleanupSharedTextures();
 }
 
+void UnityScreen::DamagePanelShadow()
+{
+  CompRect panelShadow;
+
+  for (CompOutput const& output : screen->outputDevs())
+  {
+    FillShadowRectForOutput(panelShadow, output);
+    cScreen->damageRegion(CompRegion(panelShadow));
+  }
+}
+
+void UnityScreen::OnViewHidden(nux::BaseWindow *bw)
+{
+  /* Count this as regular damage */
+  nux::Geometry geometry(bw->GetAbsoluteGeometry());
+  cScreen->damageRegion(CompRegion (geometry.x,
+                                    geometry.y,
+                                    geometry.width,
+                                    geometry.height));
+}
+
 void UnityScreen::EnsureSuperKeybindings()
 {
   for (auto action : _shortcut_actions)
@@ -579,6 +616,20 @@
   panel_shadow_matrix_ = matrix;
 }
 
+void UnityScreen::FillShadowRectForOutput(CompRect         &shadowRect,
+                                          CompOutput const &output)
+{
+  if (_shadow_texture.empty ())
+    return;
+
+  float panel_h = static_cast<float>(panel_style_.panel_height);
+  float shadowX = output.x();
+  float shadowY = output.y() + panel_h;
+  float shadowWidth = output.width();
+  float shadowHeight = _shadow_texture[0]->height();
+  shadowRect.setGeometry(shadowX, shadowY, shadowWidth, shadowHeight);
+}
+
 void UnityScreen::paintPanelShadow(CompRegion const& clip)
 {
   // You have no shadow texture. But how?
@@ -606,11 +657,8 @@
       return;
   }
 
-  int shadowX = output->x();
-  int shadowY = output->y() + panel_style_.panel_height;
-  int shadowWidth = output->width();
-  int shadowHeight = _shadow_texture[0]->height();
-  CompRect shadowRect(shadowX, shadowY, shadowWidth, shadowHeight);
+  CompRect shadowRect;
+  FillShadowRectForOutput(shadowRect, *output);
 
   CompRegion redraw(clip);
   redraw &= shadowRect;
@@ -650,10 +698,10 @@
       float y2 = r.y2();
 
       // Texture coordinates of the above rectangle:
-      float tx1 = (x1 - shadowX) / shadowWidth;
-      float ty1 = (y1 - shadowY) / shadowHeight;
-      float tx2 = (x2 - shadowX) / shadowWidth;
-      float ty2 = (y2 - shadowY) / shadowHeight;
+      float tx1 = (x1 - shadowRect.x()) / shadowRect.width();
+      float ty1 = (y1 - shadowRect.y()) / shadowRect.height();
+      float tx2 = (x2 - shadowRect.x()) / shadowRect.width();
+      float ty2 = (y2 - shadowRect.y()) / shadowRect.height();
 
       vertexData = {
         x1, y1, 0,
@@ -717,25 +765,37 @@
 
   DrawPanelUnderDash();
 
-  if (BackgroundEffectHelper::HasDirtyHelpers())
+  /* Bind the currently bound draw framebuffer to the read framebuffer binding.
+   * The reason being that we want to use the results of nux images being
+   * drawn to this framebuffer in glCopyTexSubImage2D operations */
+  GLint current_draw_binding, old_read_binding;
+#ifndef USE_GLES
+  glGetIntegerv(GL_READ_FRAMEBUFFER_BINDING_EXT, &old_read_binding);
+  glGetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING_EXT, &current_draw_binding);
+  if (old_read_binding != current_draw_binding)
+    (*GL::bindFramebuffer) (GL_READ_FRAMEBUFFER_BINDING_EXT, current_draw_binding);
+#endif
+
+  /* If we have dirty helpers re-copy the backbuffer
+   * into a texture
+   *
+   * TODO: Make this faster by only copying the bits we
+   * need as opposed to the whole readbuffer */
+  if (dirty_helpers_on_this_frame_)
   {
     auto gpu_device = nux::GetGraphicsDisplay()->GetGpuDevice();
     auto graphics_engine = nux::GetGraphicsDisplay()->GetGraphicsEngine();
-
-    nux::ObjectPtr<nux::IOpenGLTexture2D> bg_texture =
-      graphics_engine->CreateTextureFromBackBuffer(0, 0,
-                                                   screen->width(),
-                                                   screen->height());
-    gpu_device->backup_texture0_ = bg_texture;
+    gpu_device->backup_texture0_ =
+      graphics_engine->CreateTextureFromBackBuffer(0, 0, screen->width(), screen->height());
+    back_buffer_age_ = 0;
   }
 
   nux::Geometry outputGeo(output->x (), output->y (), output->width (), output->height ());
   BackgroundEffectHelper::monitor_rect_.Set(0, 0, screen->width(), screen->height());
 
-  GLint fboID;
-  // Nux renders to the referenceFramebuffer when it's embedded.
-  glGetIntegerv(GL_FRAMEBUFFER_BINDING, &fboID);
-  wt->GetWindowCompositor().SetReferenceFramebuffer(fboID, outputGeo);
+  wt->GetWindowCompositor().SetReferenceFramebuffer(current_draw_binding,
+                                                    old_read_binding,
+                                                    outputGeo);
 
   nuxPrologue();
   wt->RenderInterfaceFromForeignCmd (&outputGeo);
@@ -1223,6 +1283,7 @@
   doShellRepaint = force ||
                    ( !region.isEmpty() &&
                      ( !wt->GetDrawList().empty() ||
+                       !wt->GetPresentationListGeometries().empty() ||
                        (mask & PAINT_SCREEN_FULL_MASK)
                      )
                    );
@@ -1258,10 +1319,143 @@
                                            unsigned int mask)
 {
   allowWindowPaint = false;
+
+  /* PAINT_SCREEN_FULL_MASK means that we are ignoring the damage
+   * region and redrawing the whole screen, so we should make all
+   * nux windows be added to the presentation list that intersect
+   * this output.
+   *
+   * However, damaging nux has a side effect of notifying compiz
+   * through onRedrawRequested that we need to queue another frame.
+   * In most cases that would be desirable, and in the case where
+   * we did that in damageCutoff, it would not be a problem as compiz
+   * does not queue up new frames for damage that can be processed
+   * on the current frame. However, we're now past damage cutoff, but
+   * a change in circumstances has required that we redraw all the nux
+   * windows on this frame. As such, we need to ensure that damagePending
+   * is not called as a result of queuing windows for redraw, as that
+   * would effectively result in a damage feedback loop in plugins that
+   * require screen transformations (eg, new frame -> plugin redraws full
+   * screen -> we reach this point and request another redraw implicitly)
+   */
+  if (mask & PAINT_SCREEN_FULL_MASK)
+  {
+    ignore_redraw_request_ = true;
+    compizDamageNux(CompRegionRef(output->region()));
+    ignore_redraw_request_ = false;
+
+    /* Fetch all the presentation list geometries - this will have the side
+     * effect of clearing any built-up damage state */
+    std::vector<nux::Geometry> dirty = wt->GetPresentationListGeometries();
+  }
+
   gScreen->glPaintTransformedOutput(attrib, transform, region, output, mask);
   paintPanelShadow(region);
 }
 
+void UnityScreen::updateBlurDamage()
+{
+  /* If there are enabled helpers, we want to apply damage
+   * based on how old our tracking fbo is since we may need
+   * to redraw some of the blur regions if there has been
+   * damage since we last bound it
+   *
+   * XXX: Unfortunately there's a nasty feedback loop here, and not
+   * a whole lot we can do about it. If part of the damage from any frame
+   * intersects a nux window, we have to mark the entire region that the
+   * nux window covers as damaged, because nux does not have any concept
+   * of geometry clipping. That damage will feed back to us on the next frame.
+   */
+  if (BackgroundEffectHelper::HasEnabledHelpers())
+  {
+    cScreen->applyDamageForFrameAge (back_buffer_age_);
+
+    /*
+     * Prioritise user interaction over active blur updates. So the general
+     * slowness of the active blur doesn't affect the UI interaction performance.
+     *
+     * Also, BackgroundEffectHelper::ProcessDamage() is causing a feedback loop
+     * while the dash is open. Calling it results in the NEXT frame (and the
+     * current one?) to get some damage. This GetDrawList().empty() check avoids
+     * that feedback loop and allows us to idle correctly.
+     *
+     * We are doing damage processing for the blurs here, as this represents
+     * the most up to date compiz damage under the nux windows.
+     */
+    if (wt->GetDrawList().empty())
+    {
+      CompRect::vector const& rects(buffered_compiz_damage_this_frame_.rects());
+      for (CompRect const& r : rects)
+      {
+        nux::Geometry geo(r.x(), r.y(), r.width(), r.height());
+        BackgroundEffectHelper::ProcessDamage(geo);
+      }
+    }
+  }
+}
+
+void UnityScreen::damageCutoff()
+{
+  if (force_draw_countdown_)
+  {
+    typedef nux::WindowCompositor::WeakBaseWindowPtr WeakBaseWindowPtr;
+
+    /* We have to force-redraw the whole scene because
+     * if a bug in the nvidia driver that causes framebuffers
+     * to be trashed on resume for a few swaps */
+    wt->GetWindowCompositor ()
+        .OnAllBaseWindows ([](WeakBaseWindowPtr const &w) {
+      w->QueueDraw ();
+    });
+
+    force_draw_countdown_--;
+  }
+
+  /* At this point we want to take all of the compiz damage
+   * for this frame and use it to determine which blur regions
+   * need to be redrawn. We don't want to do this any later because
+   * the nux damage is logically on top of the blurs and doesn't
+   * affect them */
+  updateBlurDamage();
+
+  /* Determine nux region damage last */
+  cScreen->damageCutoff();
+
+  CompRegion damage_buffer, last_damage_buffer;
+
+  do
+  {
+    last_damage_buffer = damage_buffer;
+
+    /* First apply any damage accumulated to nux to see
+     * what windows need to be redrawn there */
+    compizDamageNux(buffered_compiz_damage_this_frame_);
+
+    /* Apply the redraw regions to compiz so that we can
+     * draw this frame with that region included */
+    determineNuxDamage(damage_buffer);
+
+    /* We want to track the nux damage here as we will use it to
+     * determine if we need to present other nux windows too */
+    cScreen->damageRegion(damage_buffer);
+
+    /* If we had to put more damage into the damage buffer then
+     * damage compiz with it and keep going */
+  } while (last_damage_buffer != damage_buffer);
+
+  /* Clear damage buffer */
+  buffered_compiz_damage_last_frame_ = buffered_compiz_damage_this_frame_;
+  buffered_compiz_damage_this_frame_ = CompRegion();
+
+  /* Tell nux that any damaged windows should be redrawn on the next
+   * frame and not this one */
+  wt->ForeignFrameCutoff();
+
+  /* We need to track this per-frame to figure out whether or not
+   * to bind the contents fbo on each monitor pass */
+  dirty_helpers_on_this_frame_ = BackgroundEffectHelper::HasDirtyHelpers();
+}
+
 void UnityScreen::preparePaint(int ms)
 {
   cScreen->preparePaint(ms);
@@ -1275,8 +1469,6 @@
   didShellRepaint = false;
   panelShadowPainted = CompRegion();
   firstWindowAboveShell = NULL;
-
-  compizDamageNux(cScreen->currentDamage());
 }
 
 void UnityScreen::donePaint()
@@ -1290,11 +1482,22 @@
    * I think this is a Nux bug. ClearDrawList should ideally also mark all
    * the queued views as draw_cmd_queued_=false.
    */
+
+  /* To prevent any potential overflow problems, we are assuming here
+   * that compiz caps the maximum number of frames tracked at 10, so
+   * don't increment the age any more than 11 */
+  if (back_buffer_age_ < 11)
+    ++back_buffer_age_;
+
   if (didShellRepaint)
     wt->ClearDrawList();
 
+  /* Tell nux that a new frame is now beginning and any damaged windows should
+   * now be painted on this frame */
+  wt->ForeignFrameEnded();
+
   if (animation_controller_->HasRunningAnimations())
-    nuxDamageCompiz();
+    onRedrawRequested();
 
   std::list <ShowdesktopHandlerWindowInterface *> remove_windows;
 
@@ -1318,124 +1521,50 @@
 
 void UnityScreen::compizDamageNux(CompRegion const& damage)
 {
-  if (!launcher_controller_)
-    return;
-
-  /*
-   * Prioritise user interaction over active blur updates. So the general
-   * slowness of the active blur doesn't affect the UI interaction performance.
-   *
-   * Also, BackgroundEffectHelper::ProcessDamage() is causing a feedback loop
-   * while the dash is open. Calling it results in the NEXT frame (and the
-   * current one?) to get some damage. This GetDrawList().empty() check avoids
-   * that feedback loop and allows us to idle correctly.
+  /* Ask nux to present anything in our damage region
+   *
+   * Note: This is using a new nux API, to "present" windows
+   * to the screen, as opposed to drawing them. The difference is
+   * important. The former will just draw the window backing texture
+   * directly to the screen, the latter will re-draw the entire window.
+   *
+   * The former is a lot faster, do not use QueueDraw unless the contents
+   * of the window need to be re-drawn.
    */
-  if (wt->GetDrawList().empty() && BackgroundEffectHelper::HasDamageableHelpers())
-  {
-    CompRect::vector const& rects(damage.rects());
-    for (CompRect const& r : rects)
-    {
-      nux::Geometry geo(r.x(), r.y(), r.width(), r.height());
-      BackgroundEffectHelper::ProcessDamage(geo);
-    }
-  }
-
-  auto const& launchers = launcher_controller_->launchers();
-  for (auto const& launcher : launchers)
-  {
-    if (!launcher->Hidden())
-    {
-      nux::Geometry const& geo = launcher->GetAbsoluteGeometry();
-      CompRegion launcher_region(geo.x, geo.y, geo.width, geo.height);
-
-      if (damage.intersects(launcher_region))
-        launcher->QueueDraw();
-
-      nux::ObjectPtr<nux::View> const& tooltip = launcher->GetActiveTooltip();
-
-      if (tooltip)
-      {
-        nux::Geometry const& g = tooltip->GetAbsoluteGeometry();
-        CompRegion tip_region(g.x, g.y, g.width, g.height);
-
-        if (damage.intersects(tip_region))
-          tooltip->QueueDraw();
-      }
-
-      nux::ObjectPtr<LauncherDragWindow> const& dragged_icon = launcher->GetDraggedIcon();
-
-      if (dragged_icon)
-      {
-        nux::Geometry const& g = dragged_icon->GetAbsoluteGeometry();
-        CompRegion icon_region(g.x, g.y, g.width, g.height);
-
-        if (damage.intersects(icon_region))
-          dragged_icon->QueueDraw();
-      }
-    }
-  }
-
-  std::vector<nux::View*> const& panels(panel_controller_->GetPanelViews());
-  for (nux::View* view : panels)
-  {
-    nux::Geometry const& geo = view->GetAbsoluteGeometry();
-
-    CompRegion panel_region(geo.x, geo.y, geo.width, geo.height);
-
-    if (damage.intersects(panel_region))
-      view->QueueDraw();
-  }
-
-  QuicklistManager* qm = QuicklistManager::Default();
-  if (qm)
-  {
-    auto const& view = qm->Current();
-
-    if (view)
-    {
-      nux::Geometry const& geo = view->GetAbsoluteGeometry();
-      CompRegion quicklist_region(geo.x, geo.y, geo.width, geo.height);
-
-      if (damage.intersects(quicklist_region))
-        view->QueueDraw();
-    }
-  }
-
-  if (switcher_controller_ && switcher_controller_->Visible())
-  {
-    auto const& view = switcher_controller_->GetView();
-
-    if (G_LIKELY(view))
-    {
-      nux::Geometry const& geo = view->GetAbsoluteGeometry();
-      CompRegion switcher_region(geo.x, geo.y, geo.width, geo.height);
-
-      if (damage.intersects(switcher_region))
-        view->QueueDraw();
-    }
+  CompRect::vector rects (damage.rects());
+  for (const CompRect &r : rects)
+  {
+    nux::Geometry g (r.x(), r.y(), r.width(), r.height());
+    wt->PresentWindowsIntersectingGeometryOnThisFrame(g);
   }
 }
 
 /* Grab changed nux regions and add damage rects for them */
-void UnityScreen::nuxDamageCompiz()
+void UnityScreen::determineNuxDamage(CompRegion &nux_damage)
 {
-  /*
-   * If Nux is going to redraw anything then we have to tell Compiz to
-   * redraw everything. This is because Nux has a bad habit (bug??) of drawing
-   * more than just the regions of its DrawList. (LP: #1036519)
-   *
-   * Forunately, this does not happen on most frames. Only when the Unity
-   * Shell needs to redraw something.
-   *
-   * TODO: Try to figure out why redrawing the panel makes the launcher also
-   *       redraw even though the launcher's geometry is not in DrawList, and
-   *       stop it. Then maybe we can revert back to the old code below #else.
-   */
-  if (!wt->GetDrawList().empty() || animation_controller_->HasRunningAnimations())
+  /* Fetch all the dirty geometry from nux and aggregate it */
+  std::vector<nux::Geometry> dirty = wt->GetPresentationListGeometries();
+
+  for (auto const& geo : dirty)
+    nux_damage += CompRegion(geo.x, geo.y, geo.width, geo.height);
+
+  /* Special case, we need to redraw the panel shadow on panel updates */
+  for (auto const& panel_geo : panel_controller_->GetGeometries())
   {
-    cScreen->damageRegionSetEnabled(this, false);
-    cScreen->damageScreen();
-    cScreen->damageRegionSetEnabled(this, true);
+    CompRect panel_rect (panel_geo.x,
+                         panel_geo.y,
+                         panel_geo.width,
+                         panel_geo.height);
+
+    if (nux_damage.intersects(panel_rect))
+    {
+      foreach (CompOutput const& o, screen->outputDevs())
+      {
+        CompRect shadowRect;
+        FillShadowRectForOutput(shadowRect, o);
+        nux_damage += shadowRect;
+      }
+    }
   }
 }
 
@@ -1675,7 +1804,7 @@
 
 void UnityScreen::damageRegion(const CompRegion &region)
 {
-  compizDamageNux(region);
+  buffered_compiz_damage_this_frame_ += region;
   cScreen->damageRegion(region);
 }
 
@@ -2965,11 +3094,14 @@
   nux::ColorLayer background(nux::color::Transparent);
   static_cast<nux::WindowThread*>(thread)->SetWindowBackgroundPaintLayer(&background);
   LOG_INFO(logger) << "UnityScreen::initUnity: " << timer.ElapsedSeconds() << "s";
+
+  nux::GetWindowCompositor().sigHiddenViewWindow.connect (sigc::mem_fun(self, &UnityScreen::OnViewHidden));
 }
 
 void UnityScreen::onRedrawRequested()
 {
-  nuxDamageCompiz();
+  if (!ignore_redraw_request_)
+    cScreen->damagePending();
 }
 
 /* Handle option changes and plug that into nux windows */
@@ -3159,6 +3291,8 @@
                     << " h=" << primary_monitor_().height;
 
   needsRelayout = false;
+
+  DamagePanelShadow ();
 }
 
 /* Handle changes in the number of workspaces by showing the switcher
 
=== modified file 'plugins/unityshell/src/unityshell.h'
--- plugins/unityshell/src/unityshell.h	2013-04-11 05:53:30 +0000
+++ plugins/unityshell/src/unityshell.h	2013-05-20 16:09:26 +0000
@@ -97,9 +97,11 @@
 
   /* nux draw wrapper */
   void paintDisplay();
-  void paintPanelShadow(const CompRegion& clip);
+  void paintPanelShadow(CompRegion const& clip);
   void setPanelShadowMatrix(const GLMatrix& matrix);
 
+  void updateBlurDamage();
+  void damageCutoff();
   void preparePaint (int ms);
   void paintFboForOutput (CompOutput *output);
   void donePaint ();
@@ -215,7 +217,7 @@
   void initLauncher();
 
   void compizDamageNux(CompRegion const& region);
-  void nuxDamageCompiz();
+  void determineNuxDamage(CompRegion &nux_damage);
 
   void onRedrawRequested();
   void Relayout();
@@ -237,6 +239,12 @@
   void OnInitiateSpread();
   void OnTerminateSpread();
 
+  void DamagePanelShadow();
+
+  void OnViewHidden(nux::BaseWindow *bw);
+
+  void RestoreWindow(GVariant* data);
+
   bool SaveInputThenFocus(const guint xid);
 
   void OnPanelStyleChanged();
@@ -245,6 +253,8 @@
 
   void DrawPanelUnderDash();
 
+  void FillShadowRectForOutput(CompRect &shadowRect,
+                               CompOutput const &output);
   unsigned CompizModifiersToNux(unsigned input) const;
   unsigned XModifiersToNux(unsigned input) const;
 
@@ -304,6 +314,12 @@
   bool    _key_nav_mode_requested;
   CompOutput* _last_output;
 
+  /* a small count-down work-a-around
+   * to force full redraws of the shell
+   * a certain number of frames after a
+   * suspend / resume cycle */
+  unsigned int force_draw_countdown_;
+
   CompRegion panelShadowPainted;
   CompRegion nuxRegion;
   CompRegion fullscreenRegion;
@@ -341,6 +357,13 @@
   UBusManager ubus_manager_;
   glib::SourceManager sources_;
 
+  CompRegion buffered_compiz_damage_this_frame_;
+  CompRegion buffered_compiz_damage_last_frame_;
+  bool       ignore_redraw_request_;
+  bool       dirty_helpers_on_this_frame_;
+
+  unsigned int back_buffer_age_;
+
   friend class UnityWindow;
 };
 
 
=== modified file 'unity-shared/OverlayWindowButtons.cpp'
--- unity-shared/OverlayWindowButtons.cpp	2013-04-22 19:09:26 +0000
+++ unity-shared/OverlayWindowButtons.cpp	2013-05-20 16:09:26 +0000
@@ -43,6 +43,10 @@
   AddChild(window_buttons_.GetPointer());
   UpdateGeometry();
   SetBackgroundColor(nux::color::Transparent);
+
+  window_buttons_->queue_draw.connect([&] (nux::Layout* /*layout*/) {
+    QueueDraw();
+  });
 }
 
 void OverlayWindowButtons::UpdateGeometry()