Merge lp:~alan-griffiths/mir/scene-can-identify-surface-under-cursor into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Alan Griffiths on 2015-02-20 |
| Approved revision: | 2337 |
| Merged at revision: | 2331 |
| Proposed branch: | lp:~alan-griffiths/mir/scene-can-identify-surface-under-cursor |
| Merge into: | lp:mir |
| Diff against target: |
340 lines (+112/-32) 11 files modified
include/server/mir/scene/surface_coordinator.h (+4/-0) src/server/scene/surface_controller.cpp (+6/-0) src/server/scene/surface_controller.h (+2/-0) src/server/scene/surface_stack.cpp (+33/-0) src/server/scene/surface_stack.h (+2/-0) src/server/scene/surface_stack_model.h (+5/-1) src/server/symbols.map (+7/-31) tests/include/mir_test_doubles/mock_surface_coordinator.h (+1/-0) tests/unit-tests/scene/test_application_session.cpp (+4/-0) tests/unit-tests/scene/test_surface_controller.cpp (+1/-0) tests/unit-tests/scene/test_surface_stack.cpp (+47/-0) |
| To merge this branch: | bzr merge lp:~alan-griffiths/mir/scene-can-identify-surface-under-cursor |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Daniel van Vugt | 2015-02-13 | Needs Fixing on 2015-02-20 | |
| Robert Carr (community) | Approve on 2015-02-19 | ||
| Alberto Aguirre | Approve on 2015-02-19 | ||
| PS Jenkins bot | continuous-integration | Approve on 2015-02-19 | |
| Andreas Pokorny (community) | Abstain on 2015-02-19 | ||
| Alexandros Frantzis (community) | Approve on 2015-02-17 | ||
| Alan Griffiths | Abstain on 2015-02-17 | ||
| Chris Halse Rogers | Approve on 2015-02-17 | ||
|
Review via email:
|
|||
Commit Message
scene: Introduce mechanism to find the surface under a cursor
Description of the Change
scene: Introduce mechanism to find the surface under a cursor
There'll be an acceptance test along shortly to expose this functionality for window management, but this bit splits off cleanly.
| Daniel van Vugt (vanvugt) wrote : | # |
Sounds redundant. We already have such logic to send input events to the right window. Can we just reuse that?
| Daniel van Vugt (vanvugt) wrote : | # |
Oh you are using that logic already :)
70 + if (surface-
71 + result = surface;
but that's only a rectangle.
I think the right answer is to test the free-form input region, which we have a setter for but no getter yet:
virtual void set_input_
It's not a big deal, but if we wanted to support custom shaped surfaces properly then we would test the region and not just the bounding rectangle.
| Daniel van Vugt (vanvugt) wrote : | # |
Aha. The right function already exists.
Instead of:
surface-
we want something like:
surface-
which will test the region proper and also checks the visible() flag properly.
Furthermore, we don't need to pay attention to this flag:
67 + if (surface-
68 + MirSurfaceVisib
Instead just make sure you're walking the stack from top-to-bottom (reverse?), and break out of the loop when you find the first hit.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2323
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Daniel van Vugt (vanvugt) wrote : | # |
Looks good. Just missing server ABI bump to 30 due to the ABI break.
| Alan Griffiths (alan-griffiths) wrote : | # |
Actually, as Daniel indirectly pointed out on another thread, this shouldn't be scanning for the input area under the cursor but for the whole (visible) surface area.
| Alan Griffiths (alan-griffiths) wrote : | # |
> Looks good. Just missing server ABI bump to 30 due to the ABI break.
Done.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2326
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
- 2327. By Alan Griffiths on 2015-02-17
-
Update debian/*
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2327
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
| Alexandros Frantzis (afrantzis) wrote : | # |
>361 + stub_surface1-
... etc
Not needed.
- 2328. By Alan Griffiths on 2015-02-17
-
Update debian/*
- 2329. By Alan Griffiths on 2015-02-17
-
Remove unnecessary setup
| Alan Griffiths (alan-griffiths) wrote : | # |
> >361 + stub_surface1-
> MirSurfaceVisib
> ... etc
>
> Not needed.
Fixed, but the diff refuses to show it
- 2330. By Alan Griffiths on 2015-02-17
-
Empty checkin to fool lp
| Alexandros Frantzis (afrantzis) wrote : | # |
> Fixed, but the diff refuses to show it
Oh, no, we have broken LP! :)
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2328
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2330
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Daniel van Vugt (vanvugt) wrote : | # |
This is now incorrect:
133 + if (surface->visible() &&
134 + geom::Rectangle
135 + return surface;
A shaped surface occupies less space than its rectangle (e.g. try mir_demo_
Then again, I think we lack any client API to express an input shape at all yet...
| Alan Griffiths (alan-griffiths) wrote : | # |
> This is now incorrect:
>
> 133 + if (surface->visible() &&
> 134 + geom::Rectangle
> surface-
> 135 + return surface;
>
> A shaped surface occupies less space than its rectangle (e.g. try
> mir_demo_
> shaped surfaces that express a reduced input region. Using
> input_area_
What I want is the surface visible under the cursor position, not the input area. Using is wrong as you described yourself at lp:~alan-griffiths/mir/canonical-window-manager/+merge/249849/comments/619311
"BTW, if you're resizing then the input area the client has designated is probably irrelevant. Instead you want to consider the whole surface rectangle..."
> Then again, I think we lack any client API to express an input shape at all
> yet...
The region I want here includes, for example, decorations that are not part of the input area - maybe we can refine the implementation in future, but the proposed algorithm is more correct than using nput_area_
- 2331. By Alan Griffiths on 2015-02-18
-
TODO comment explaining implementation choice
- 2332. By Alan Griffiths on 2015-02-18
-
merge lp:mir
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2332
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
FAILURE: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Robert Carr (robertcarr) wrote : | # |
I think using input_area_contains is probably correct.
The origin of the input area was to allow unity8 (pre qt-compositor) to punch an input hole in the always on top shell surface. If client API were added I imagine it would also be used for things like a circular clock app e.g. the X shape extension...
Essentially it seems like a bit of a misnomer to say a surface is under the cursor when cursor events will pass through the surface.
| Alberto Aguirre (albaguirre) wrote : | # |
"A shaped surface occupies less space than its rectangle (e.g. try mir_demo_
After a brief scan of the code, I don't see how input_area_contains tracks client opacity. It would be just as broken if the proposed implementation "used input_area_
@Robert,
A shell surface like that sounds like it should have it's own type or state.
@Alan,
Perhaps we can have:
std:
And then the demo window manager can have the simple implementation proposed here.
| Robert Carr (robertcarr) wrote : | # |
>> A shell surface like that sounds like it should have it's own type or state.
Sure I was just outlining the history of the code. I think the upcoming use case of say a circular clock app is valid though.
| Robert Carr (robertcarr) wrote : | # |
The suggestion not being that input_area_contains will track opacity but rather that the client will have the option of updating its input area via specifying a set of rectangles.
Perhaps this should be it's input/output area. I know at least OSX (Circa 2009 lol) and X11 support setting input shape exclusively.
| Daniel van Vugt (vanvugt) wrote : | # |
Alberto says:
"After a brief scan of the code, I don't see how input_area_contains tracks client opacity. It would be just as broken if the proposed implementation "used input_area_
That's right. It's a feature and not a bug. Monitoring pixel opacity could be prohibitively expensive if done regularly. It's just the client's responsibility to designate an input area that matches its visibly opaque area.
As Robert points out, this is based on X11's input area. The goal is noble, but the implementation can be expensive, because in both X11 and Mir the input area is designated by a set of rectangles. But we don't need to be tied to the set-of-rectangles implementation everyone uses right now. The beauty of input_area_
Long term, I suggest a nice solution would be to resample pixel opacity once per surface resize and use that as a mask for the default input region (which then can be any shape). You can also optimize for the common case of rectangular clients so only surfaces that are actually shaped need to have a mask stored for them.
At least input_area_
That said, testing a single rectangle might make sense for a purely tiling shell, for ease of use. By definition of the tiling shell there are no "gaps". But a traditional floating window shell should honour surface shapes more accurately.
| Andreas Pokorny (andreas-pokorny) wrote : | # |
oh a classic you cannot to this but you also cannot do the opposite.
Hm most of what was proposed and discussed here might fit.. based on the ambivalent nature of mir::scene::Surface and its processing components.
What I do not like about the MP is that we are running into scene and surface locks while dispatching user input. But I will not block based on that. We can still drive that onto a different implementation path, while keeping the interface.
- 2333. By Alan Griffiths on 2015-02-19
-
Revert debian/* changes
- 2334. By Alan Griffiths on 2015-02-19
-
Fix symbol map without updating to MIR_SERVER_30
- 2335. By Alan Griffiths on 2015-02-19
-
Back to surface-
>input_ area_contains( cursor) with a note of misgivings - 2336. By Alan Griffiths on 2015-02-19
-
merge lp:mir
| Alan Griffiths (alan-griffiths) wrote : | # |
I'm not yet convinced that input_area_
But input_area_
I've also reverted the ABI bump as that's causing CI problems and can be landed separately.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:2336
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild:
http://
- 2337. By Alan Griffiths on 2015-02-19
-
Forgotten reverts
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2337
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Alan Griffiths (alan-griffiths) wrote : | # |
> What I do not like about the MP is that we are running into scene and surface
> locks while dispatching user input. But I will not block based on that. We can
> still drive that onto a different implementation path, while keeping the
> interface.
The scene needs some re-architecting to reduce lock contention. Having C++14 sharable mutexes will help I think (as only the shell should be updating the scene).
| Alan Griffiths (alan-griffiths) wrote : | # |
> Perhaps we can have:
>
> std::shared_
> ms::SurfaceStac
>
> And then the demo window manager can have the simple implementation proposed
> here.
I don't think it makes sense for the window manager to decide which surface is under a click. At least not until we understand how decorations are represented in the scene.
| Alberto Aguirre (albaguirre) wrote : | # |
OK.
LGTM then. We can improve this as we enhance the scene.
| Andreas Pokorny (andreas-pokorny) wrote : | # |
> > What I do not like about the MP is that we are running into scene and
> surface
> > locks while dispatching user input. But I will not block based on that. We
> can
> > still drive that onto a different implementation path, while keeping the
> > interface.
>
> The scene needs some re-architecting to reduce lock contention. Having C++14
> sharable mutexes will help I think (as only the shell should be updating the
> scene).
I think our scenes are rather small we can avoid contention-free acquiring of a lot of locks. So I thought of transforming the grand central scene to an input scene when changes happen. the reduced input scene would be for input dispatch & input related window management only.
| Alan Griffiths (alan-griffiths) wrote : | # |
> I think our scenes are rather small we can avoid contention-free acquiring of
> a lot of locks. So I thought of transforming the grand central scene to an
> input scene when changes happen. the reduced input scene would be for input
> dispatch & input related window management only.
We digress, but input can also update an input scene model what it needs on the basis of observers instead of transforming the grand central scene whenever changes happen.
| Robert Carr (robertcarr) wrote : | # |
>> I think our scenes are rather small we can avoid contention-free acquiring of a lot of locks. So I >> thought of transforming the grand central scene to an input scene when changes happen. the reduced >> input scene would be for input dispatch & input related window management only.
Android actually uses an approach like this...we used to use..InputDispa
| Daniel van Vugt (vanvugt) wrote : | # |
I think we're almost there. Not too concerned about input on decorations as I've recently come to the realization that might be more the shell's job to detect (Unity8 does already). In fact, I already started designing for that and stopped (see TODOs in basic_surface.cpp).
Probable needs fixing: Functions removed from symbols.map without an ABI bump :)
| Alan Griffiths (alan-griffiths) wrote : | # |
> Probable needs fixing: Functions removed from symbols.map without an ABI bump
> :)
I think not:
1. these functions couldn't be used as they don't appear in pubic headers; and,
2. most (if not all) were not actually exported because the symbols were not generated.

PASSED: Continuous integration, rev:2320 jenkins. qa.ubuntu. com/job/ mir-ci/ 2978/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/1304 jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/1303 jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/1260 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 975 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 975/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 1260 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 1260/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -runner- mako/4297 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 18069
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/mir- ci/2978/ rebuild
http://