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

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?

*crashes

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.

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?

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

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

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

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

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?

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

Okay, all updated as requested.

> Okay, all updated as requested.

I'll try again tomorrow.

Looks good now. Please remove this line too:

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

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

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

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.

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

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

Okay, should be all fixed.

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

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

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.

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

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

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

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

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

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

@Sam, how many lines of code?

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

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.

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

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

> review: Approve

Hurra \o/

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

I think he mentioned Intel HD 4000 above ^^

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.

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

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

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

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

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

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

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

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

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

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

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

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)

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

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.

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

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

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

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

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

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

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

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.