[RFC] wl_surface scale and crop protocol extension

[Daniel Stone]

Hi,
Again I fear we're drifting massively off-topic, but here we go ...

On 3 May 2013 18:50, Bill Spitzak <spitzak at gmail.com> wrote:
> Daniel Stone wrote:
>> Subsurfaces are being designed for in-process cases, such as a media
>> player inside a browser.  Foreign surfaces are intended for
>> cross-process buffer/surface sharing, but I think nested compositors
>> is actually better for the usecase I had in mind, which is WebKit2.
>> So it would be nice if they weren't unnecessarily complex to
>> implement.
>
> The final compositor is able to do the fully optimized compositing of
> surfaces into the output frame buffer, including all the work various people
> have done to not composite obscured areas. I fail to see how a nested
> compositor can take advantage of this except by transmitting all the
> individual surfaces to the final compositor.

If that's the goal, then yes. For some usecases however, doing the
compositing before and sending one large buffer to the compositor is
desirable.

> This means that buffers and buffer allocation have to be transparently
> passed through the intermediate compositors. I don't think this has been
> addressed, and it seems really difficult compared to just reusing the
> existing single connection to the server.

Again, yes, sometimes.  For most stacks, passing the allocation
through is fairly trivial, as the allocation is client-driven anyway:
the client creates the buffer and then just tells the compositor how
to access it.  EGL implementations can already proxy buffer allocation
with zero interference from us, however: they already have a
connection to the parent compositor's display, so they can just pass
all allocation requests they might get, up the chain.

We do need a little bit more API to support this, but nothing too
catastrophic, and nothing more implementationally onerous than the
stream-of-buffers foreign surface proposal demanded.

> The proposal where the parent task creates subsurfaces and then does some
> setup so the child task can draw them seems far more like what webkit is
> going to want and use.

I really don't think it is.

>> I don't think having 'sub-extensions' makes anything more clear: in
>> fact, exactly the opposite.
>
> I'm not describing this right. What I want is to be able to read the
> documentation, and see a list of "all the things you can do to a
> wl_surface".
>
> Currently one of the things you can do to a wl_surface is that you can find
> the wl_shell object and ask it to create a wl_shell_surface object given a
> wl_surface id, and then you can do things to this wl_shell_surface object.
> However this is not listed under wl_surface, instead it is listed under two
> other sections with no links to them (there are backward links but that is
> pretty useless): wl_shell and wl_shell_surface. I think this is extremely
> confusing and was probably one of the biggest obstacles I had trying to
> figure wayland out.
>
> What I would like to see is that under wl_surface you see a section that
> says something like "wl_scaler:". Listed under that are the methods that are
> currently listed under wl_surface_scaler. The title "wl_scaler:" implies all
> this information: the actual calling convention is to find the global
> wl_scaler object, call a method called get_scaler_surface with the
> wl_surface id, and that returns a new object called a wl_scaler_surface, and
> you call the listed methods on *this* object. The documentation is now where
> a user can find it, and a lot of boilerplate is elided.
>
> One thing that would help a lot is for there to be a standard as to whether
> a wl_foo global object, when asked to create an object for a wl_bar object,
> that the object is called wl_foo_bar and not wl_bar_foo. Currently the
> wl_shell and wl_scaler disagree about this. Since wl_shell_surface is in
> much more than wl_surface_scaler use I recommend standardizing on putting
> the global object's type first.

OK, so it pretty much looks like just cosmetic/documentation changes -
none of which I'm against at all.  Obviously we can't break existing
protocol though (such as renaming wl_shell_surface to
wl_surface_shell), but we can improve the documentation.  I'm sure
patches for that would be gratefully accepted.

Cheers,
Daniel