Merge lp:~nick-dedekind/qtmir/lp1475678.surface-occlude into lp:qtmir
| Status: | Merged |
|---|---|
| Approved by: | Daniel d'Andrada on 2015-10-20 |
| Approved revision: | 390 |
| Merged at revision: | 401 |
| Proposed branch: | lp:~nick-dedekind/qtmir/lp1475678.surface-occlude |
| Merge into: | lp:qtmir |
| Diff against target: |
638 lines (+294/-49) 12 files modified
debian/control (+1/-1) src/modules/Unity/Application/mirsurface.cpp (+48/-14) src/modules/Unity/Application/mirsurface.h (+11/-3) src/modules/Unity/Application/mirsurfaceinterface.h (+4/-2) src/modules/Unity/Application/mirsurfaceitem.cpp (+17/-4) src/modules/Unity/Application/mirsurfaceitem.h (+1/-0) tests/modules/CMakeLists.txt (+2/-2) tests/modules/SurfaceManager/CMakeLists.txt (+6/-4) tests/modules/SurfaceManager/mirsurface_test.cpp (+107/-0) tests/modules/SurfaceManager/mirsurfaceitem_test.cpp (+54/-5) tests/modules/common/fake_mirsurface.h (+42/-14) tests/modules/common/fake_session.h (+1/-0) |
| To merge this branch: | bzr merge lp:~nick-dedekind/qtmir/lp1475678.surface-occlude |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Daniel d'Andrada (community) | 2015-10-05 | Approve on 2015-10-20 | |
| PS Jenkins bot | continuous-integration | Needs Fixing on 2015-10-20 | |
|
Review via email:
|
|||
Commit Message
Support server->client visibility change to stop rendering (lp:#1475678)
Description of the Change
Support server->client visibility change to stop rendering (lp:#1475678)
* Are there any related MPs required for this MP to build/function as expected? Please list.
https:/
https:/
https:/
* Did you perform an exploratory manual test run of your code change and any related functionality?
* If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
| Daniel d'Andrada (dandrader) wrote : | # |
One thing to look at is to what happens when MirSurfaceItem:
Another thing to consider is what happens when there are multiple MirSurfaceItems displaying the same MirSurface? It will only get occluded if *all* items showing it are hidden. In other words: the MirSurface will be exposed as long as there's some visible MirSurfaceItem in the scene displaying it.
- 380. By Nick Dedekind on 2015-10-12
-
Aggregate the surface visibility
| Nick Dedekind (nick-dedekind) wrote : | # |
> One thing to look at is to what happens when MirSurfaceItem:
> called and the MirSurfaceItem in question is already hidden. You have to synce
> the visibility of MirSurface with the one of its MirSurfaceItem inside
> setSurface().
It did already, but I've updated since (view registration).
>
> Another thing to consider is what happens when there are multiple
> MirSurfaceItems displaying the same MirSurface? It will only get occluded if
> *all* items showing it are hidden. In other words: the MirSurface will be
> exposed as long as there's some visible MirSurfaceItem in the scene displaying
> it.
I've added surface visibility aggregation through view registration.
- 381. By Nick Dedekind on 2015-10-12
-
only log on change
- 382. By Nick Dedekind on 2015-10-12
-
use isEmpty
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:381
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
- 383. By Nick Dedekind on 2015-10-12
-
use isEmpty
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:383
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Daniel d'Andrada (dandrader) wrote : | # |
Please remove the cyclic dependency between MirSurfaceItem and MirSurface.
- 384. By Nick Dedekind on 2015-10-13
-
remove circ dep
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:384
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Daniel d'Andrada (dandrader) wrote : | # |
"""
+int MirSurface:
"""
It would be better if it took the view id as a parameter, like this:
void MirSurface:
That way MirSurfaceItem could simply do:
m_surface-
and not have to bother storing any id at all. Afterall, MirSurface::m_views is already storing them. So no need to store on both ends.
Sorry, I should have clarified that when you sent me http://
| Daniel d'Andrada (dandrader) wrote : | # |
I think you can remove that from tests/modules/
"""
+#include <QDebug>
"""
| Nick Dedekind (nick-dedekind) wrote : | # |
> """
> +int MirSurface:
> """
>
> It would be better if it took the view id as a parameter, like this:
> void MirSurface:
>
>
> That way MirSurfaceItem could simply do:
> m_surface-
>
> and not have to bother storing any id at all. Afterall, MirSurface::m_views is
> already storing them. So no need to store on both ends.
>
> Sorry, I should have clarified that when you sent me
> http://
> missing parameter in that draft (and I didn't notice it was returning an int).
I don't think that's very good coding practice. It requires the caller to be responsible for choosing a value unique to another class (even if it's its mem address, it's still the assumption). Most registration mechanisms do it my way, for good reason.
- 385. By Nick Dedekind on 2015-10-14
-
removed debug
| Nick Dedekind (nick-dedekind) wrote : | # |
> I think you can remove that from tests/modules/
>
> """
> +#include <QDebug>
> """
Done.
| Daniel d'Andrada (dandrader) wrote : | # |
On 14/10/2015 11:57, Nick Dedekind wrote:
>> """
>> +int MirSurface:
>> """
>>
>> It would be better if it took the view id as a parameter, like this:
>> void MirSurface:
>>
>>
>> That way MirSurfaceItem could simply do:
>> m_surface-
>>
>> and not have to bother storing any id at all. Afterall, MirSurface::m_views is
>> already storing them. So no need to store on both ends.
>>
>> Sorry, I should have clarified that when you sent me
>> http://
>> missing parameter in that draft (and I didn't notice it was returning an int).
> I don't think that's very good coding practice. It requires the caller to be responsible for choosing a value unique to another class (even if it's its mem address, it's still the assumption). Most registration mechanisms do it my way, for good reason.
mir::graphics:
generate_
(CompositorID being "void const*") as well, if you want an exmaple.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:385
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Gerry Boland (gerboland) wrote : | # |
> > """
> > +int MirSurface:
> > """
> >
> > It would be better if it took the view id as a parameter, like this:
> > void MirSurface:
> >
> >
> > That way MirSurfaceItem could simply do:
> > m_surface-
> >
> > and not have to bother storing any id at all. Afterall, MirSurface::m_views
> is
> > already storing them. So no need to store on both ends.
> >
> > Sorry, I should have clarified that when you sent me
> > http://
> the
> > missing parameter in that draft (and I didn't notice it was returning an
> int).
>
> I don't think that's very good coding practice. It requires the caller to be
> responsible for choosing a value unique to another class (even if it's its mem
> address, it's still the assumption). Most registration mechanisms do it my
> way, for good reason.
You're right in that this way is strictly better, especially if you don't have control over the clients registering. For now, we do have control over the clients, so we can ensure they behave correctly.
Re-using "this" memory address as unique identifier means there's one less variable to worry about.
Since we control the clients, I don't think we need the complexity of the correct approach just now. If third parties start using qtmir MirSurface directly, then we will need to rethink it.
| Daniel d'Andrada (dandrader) wrote : | # |
On 14/10/2015 13:41, Gerry Boland wrote:
>>> """
>>> +int MirSurface:
>>> """
>>>
>>> It would be better if it took the view id as a parameter, like this:
>>> void MirSurface:
>>>
>>>
>>> That way MirSurfaceItem could simply do:
>>> m_surface-
>>>
>>> and not have to bother storing any id at all. Afterall, MirSurface::m_views
>> is
>>> already storing them. So no need to store on both ends.
>>>
>>> Sorry, I should have clarified that when you sent me
>>> http://
>> the
>>> missing parameter in that draft (and I didn't notice it was returning an
>> int).
>>
>> I don't think that's very good coding practice. It requires the caller to be
>> responsible for choosing a value unique to another class (even if it's its mem
>> address, it's still the assumption). Most registration mechanisms do it my
>> way, for good reason.
> You're right in that this way is strictly better, especially if you don't have control over the clients registering. For now, we do have control over the clients, so we can ensure they behave correctly.
>
> Re-using "this" memory address as unique identifier means there's one less variable to worry about.
>
> Since we control the clients, I don't think we need the complexity of the correct approach just now. If third parties start using qtmir MirSurface directly, then we will need to rethink it.
qtmir::
internal qtmir API.
- 386. By Nick Dedekind on 2015-10-19
-
use qintptr for viewId
| Nick Dedekind (nick-dedekind) wrote : | # |
> On 14/10/2015 13:41, Gerry Boland wrote:
> >>> """
> >>> +int MirSurface:
> >>> """
> >>>
> >>> It would be better if it took the view id as a parameter, like this:
> >>> void MirSurface:
> >>>
> >>>
> >>> That way MirSurfaceItem could simply do:
> >>> m_surface-
> >>>
> >>> and not have to bother storing any id at all. Afterall,
> MirSurface::m_views
> >> is
> >>> already storing them. So no need to store on both ends.
> >>>
> >>> Sorry, I should have clarified that when you sent me
> >>> http://
> >> the
> >>> missing parameter in that draft (and I didn't notice it was returning an
> >> int).
> >>
> >> I don't think that's very good coding practice. It requires the caller to
> be
> >> responsible for choosing a value unique to another class (even if it's its
> mem
> >> address, it's still the assumption). Most registration mechanisms do it my
> >> way, for good reason.
> > You're right in that this way is strictly better, especially if you don't
> have control over the clients registering. For now, we do have control over
> the clients, so we can ensure they behave correctly.
> >
> > Re-using "this" memory address as unique identifier means there's one less
> variable to worry about.
> >
> > Since we control the clients, I don't think we need the complexity of the
> correct approach just now. If third parties start using qtmir MirSurface
> directly, then we will need to rethink it.
>
> qtmir::
> internal qtmir API.
Done.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:386
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Daniel d'Andrada (dandrader) wrote : | # |
MirSurface should call deleteLater() if the last MirSurfaceItem unregisters from it and it's no longer live() or pointed to by a session.
Ie, this code should be kept:
"""
if (m_viewCount == 0) {
[..]
if (m_session.isNull() || !m_live) {
}
}
"""
| Daniel d'Andrada (dandrader) wrote : | # |
Kept in MirSurface:
- 387. By Nick Dedekind on 2015-10-20
-
Re-added deleteLater
- 388. By Nick Dedekind on 2015-10-20
-
Added test for Surface deleteLater on deregister
| Nick Dedekind (nick-dedekind) wrote : | # |
> MirSurface should call deleteLater() if the last MirSurfaceItem unregisters
> from it and it's no longer live() or pointed to by a session.
>
> Ie, this code should be kept:
>
> """
> if (m_viewCount == 0) {
> [..]
> if (m_session.isNull() || !m_live) {
> deleteLater();
> }
> }
> """
Yikes, my bad. don't know how that happened.
re-added.
I also added a MirSurface test (to test the delete on unregister) and moved the surface related tests to a "SurfaceManager" test folder. Most other things are hosted under their Management related folders (App & Session tests). We should be adding SurfaceManager tests anyway. Guess this will come with multi-window support.
- 389. By Nick Dedekind on 2015-10-20
-
added missing file
- 390. By Nick Dedekind on 2015-10-20
-
removed line
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:388
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:390
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
- 391. By Nick Dedekind on 2015-10-21
-
merged with trunk
- 392. By Nick Dedekind on 2015-10-26
-
merged with trunk
- 393. By Nick Dedekind on 2015-10-26
-
bump libunity-api version

FAILED: Continuous integration, rev:379 jenkins. qa.ubuntu. com/job/ qtmir-ci/ 481/ jenkins. qa.ubuntu. com/job/ qtmir-vivid- amd64-ci/ 177/console jenkins. qa.ubuntu. com/job/ qtmir-vivid- armhf-ci/ 177/console jenkins. qa.ubuntu. com/job/ qtmir-vivid- i386-ci/ 59/console jenkins. qa.ubuntu. com/job/ qtmir-wily- amd64-ci/ 214/console jenkins. qa.ubuntu. com/job/ qtmir-wily- armhf-ci/ 214/console jenkins. qa.ubuntu. com/job/ qtmir-wily- i386-ci/ 59/console
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/qtmir- ci/481/ rebuild
http://