Merge lp:~kdub/mir/surface-buffer-access into lp:mir
| Status: | Merged |
|---|---|
| Approved by: | Alexandros Frantzis on 2015-06-02 |
| Approved revision: | 2576 |
| Merged at revision: | 2608 |
| Proposed branch: | lp:~kdub/mir/surface-buffer-access |
| Merge into: | lp:mir |
| Diff against target: |
353 lines (+31/-105) 12 files modified
include/server/mir/scene/surface.h (+1/-3) include/server/mir/scene/surface_buffer_access.h (+0/-50) src/server/scene/application_session.cpp (+14/-4) src/server/scene/basic_surface.cpp (+0/-7) src/server/scene/basic_surface.h (+0/-3) src/server/scene/snapshot_strategy.h (+2/-2) src/server/scene/threaded_snapshot_strategy.cpp (+3/-3) src/server/scene/threaded_snapshot_strategy.h (+1/-1) src/server/symbols.map (+0/-6) tests/include/mir_test_doubles/null_snapshot_strategy.h (+1/-1) tests/unit-tests/scene/test_application_session.cpp (+6/-6) tests/unit-tests/scene/test_threaded_snapshot_strategy.cpp (+3/-19) |
| To merge this branch: | bzr merge lp:~kdub/mir/surface-buffer-access |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Kevin DuBois (community) | Abstain on 2015-06-01 | ||
| Alan Griffiths | Approve on 2015-06-01 | ||
| PS Jenkins bot | continuous-integration | Approve on 2015-05-29 | |
| Alexandros Frantzis (community) | Abstain on 2015-05-29 | ||
| Robert Carr (community) | Approve on 2015-05-27 | ||
|
Review via email:
|
|||
Commit Message
Have the mf::BufferStream interface inherit from the ms::SurfaceBuff
Also rename the interface from "SurfaceBufferA
Description of the Change
Have the mf::BufferStream interface inherit from the ms::SurfaceBuff
Also rename the interface from "SurfaceBufferA
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2573
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://
| Alexandros Frantzis (afrantzis) wrote : | # |
> So, needs-info from the team on the question "should I just remove BufferAcccess?".
> The part I need to address in the card I'm working on is the inheritance, but
> removing the interface altogether seems a nice cleanup.
If I have understood the plan correctly, a surface is going to consist of potentially multiple bufferstreams for content (plus other bufferstreams for decoration, but we don't care about them here). So if we want a proper snapshot, the snapshotting code will need to access multiple buffers and should be able to perform some kind of basic blending to provide the final image. In order to combine the buffers, it will at least need to know their positions, so passing buffer streams to the snapshotting code is not enough.
If this is indeed the way we are heading, we probably still need some kind of function at the Surface/
Since the snapshotting code is becoming more complicated (need to combine buffers etc), it's worth ensuring that our downstreams still find it useful and there is no easier alternative they can pursue. I will talk to Gerry about this.
| Alexandros Frantzis (afrantzis) wrote : | # |
> If this is indeed the way we are heading, we probably still need some kind of function at the
> Surface/
> buffers+positions>) or with_most_
Even if we drop the wrap-around idiom and opt for a different/direct approach, the function will still need to be at the Surface level, and a separate interface (like BufferAccess) will still be preferable.
| Daniel van Vugt (vanvugt) wrote : | # |
This is not a review so I won't block anyone with tangential thoughts... But I would prefer to see us use a design that doesn't have the word "Access" as the primary noun in a class name. "Access" is too vague a word and doesn't give the reader any hint of what the class might be for. It's one of those cases where the class name is so useless you just have to treat the name as opaque and infer meaning from the implementation/
| Kevin DuBois (kdub) wrote : | # |
@Alexandros, (recap of irc discussion)
The goal is to have take a snapshot of the Surface, including all bufferstreams contained. We'll avoid having a Surface:
@Daniel,
I think its a good point that every interface provides access to something, and that tagging Access on the end is about the same as tagging Interface on the end... will see if I can come up with a better name while I'm renaming anyways
- 2574. By Kevin DuBois on 2015-05-14
-
use StreamDepiction instead of BufferAccess as the name of the interface
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2574
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 : | # |
17 +class BufferStream : public scene::
It seems the wrong way around for a frontend interface to be extending a scene interface.
Its pre-existing but probably contributes to this oddity that this BufferStream interface is wrong - its isn't specifying the requirements of frontend. Vis:
virtual void add_observer(
virtual void remove_
these functions are not needed by frontend.
I don't think we need scene::
Anything I'm missing in this analysis?
| Robert Carr (robertcarr) wrote : | # |
"mga::BufferAcc
->
"mga::StreamDep
I think we've gone from a name that makes sense to one which is obviously wrong in order to placate review suggestions that add nothing besides being hard to prove incorrect.
| Robert Carr (robertcarr) wrote : | # |
s/placate/respect/
| Robert Carr (robertcarr) wrote : | # |
LGTM though I think mga::BufferAccess was better than mga::StreamDepi
| Kevin DuBois (kdub) wrote : | # |
@bufferstream analysis, the current structure is a bit funny if you look at it in a vacuum, but given the history, we've at least got all the buffer-stream-ish functionality grouped together now in the "mc::BufferStream : mf::BufferStream : ms::StreamDepic
I did try to "flip it" to "mc::BufferStream : ms::StreamDepiction : mf::BufferStream", but the server api gives has more mf::BufferStreams (eg in the Session), so flipping means that we have shift those interfaces around too (for only the benefit of the snapshotting code, really). I'd be fine collapsing the function into mf::BufferStream (as mf::BufferStream has somewhat become the 'public face' of the streams for the server API).
So, I'd be fine with any of:
1) collapsing the only function into mf::BufferStream
2) renaming to StreamDepiction (or any other clever name)
3) dropping "Surface" from "SurfaceBufferA
in order to resolve the standing structural question of 'which stream's buffer should SurfaceBufferAccess access?'
| Alan Griffiths (alan-griffiths) wrote : | # |
> So, I'd be fine with any of:
> 1) collapsing the only function into mf::BufferStream
That seems least bad to me. It is in line with the preexisting problem with this class hierarchy. (Which I wasn't suggesting you fix for this MP.)
| Alexandros Frantzis (afrantzis) wrote : | # |
Ideally I would like us to keep a narrow interface for BufferAccess/
1. I hope the snapshotting code will go away in the short/medium-term (replaced by Qt code in qtmir)
2. *::BufferStream is narrower than Surface, not as hard to mock/stub
3. The hierarchy needs a cleanup, as noted in other comments
- 2575. By Kevin DuBois on 2015-05-29
-
sidestep naming discussion by removing the interface altogether
- 2576. By Kevin DuBois on 2015-05-29
-
rollback an overzealous sed command that also changed mga::BufferAccess
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:2576
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 : | # |
I don't think this gets us to the right place, but it Bob Martin's "boy scouts rule".

IIRC, SurfaceBufferAccess was originally created to avoid the snapshotting code from having access to the full Surface interface just to take a snapshot. Now that the concepts have been teased out a bit, I wouldn't mind just having the snapshotting code take a ptr to mf::BufferStream. mf::BufferStream already has a 'with_most_ recent_ buffer_ do" function on it, so removing the interface would just have the effect of giving the screenshotting code a wider interface.
Removal has been talked about in previous relevant discussions: /code.launchpad .net/~kdub/ mir/surface- interface- reductions/ +merge/ 258493 /code.launchpad .net/~vanvugt/ mir/no- SurfaceBufferAc cess/+merge/ 238376
https:/
https:/
So, needs-info from the team on the question "should I just remove BufferAcccess?". The part I need to address in the card I'm working on is the inheritance, but removing the interface altogether seems a nice cleanup.