I was thinking that we needed a surface-state-snapshot type, and that MirSurfaceSpec could be it, but on reflection I don't think we *do* need one.
For the specific case of Kevin's MirBufferStream bypass work, the introspection API is only necessary to ease testing - clients are perfectly capable of maintaining their own stacking and positioning state.
I'm in favour of doing the mir_connection_spec_for_* for surface type morphing - I'd maintain the requirement to set mir_pixel_format to the correct value, because that's entirely under the control of the client, but having a guard mir_dimension_last = -1 for width/height seems least ugly.
With that, I don't mind the useless MirConnection parameter to spec_for_changes :).
Why does mir_surface_apply_spec return a MirWaitHandle? I don't particularly mind it doing so, but as (extensively!) discussed, there's nothing useful a client can do with it.
I'm conceptually happy with this.
I was thinking that we needed a surface- state-snapshot type, and that MirSurfaceSpec could be it, but on reflection I don't think we *do* need one.
For the specific case of Kevin's MirBufferStream bypass work, the introspection API is only necessary to ease testing - clients are perfectly capable of maintaining their own stacking and positioning state.
I'm in favour of doing the mir_connection_ spec_for_ * for surface type morphing - I'd maintain the requirement to set mir_pixel_format to the correct value, because that's entirely under the control of the client, but having a guard mir_dimension_last = -1 for width/height seems least ugly.
With that, I don't mind the useless MirConnection parameter to spec_for_changes :).
Why does mir_surface_ apply_spec return a MirWaitHandle? I don't particularly mind it doing so, but as (extensively!) discussed, there's nothing useful a client can do with it.