[RFC] wl_surface scale and crop protocol extension

[Bill Spitzak]

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.

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.

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 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.