[RFC] wl_surface scale and crop protocol extension

[Bill Spitzak]

Daniel Stone wrote:

>> I also think all of wl_shell should be a core requirement.
> 
> Not all compositors are user sessions.  Think about nested compositors
> for browsers, or capture, or also very stripped-down usecases where
> they really don't want to have to deal with this kind of thing.

For simple displays like one that is a single full-screen window always, 
the api "works" in that raises determine which window is visible, and 
attempts to resize or turn off full-screen are ignored.

Though nested compositors are an interesting idea, it is clear from how 
the subsurfaces are being designed that it is not felt that nested 
compositors are not really useful. The biggest problem I see is that the 
nested compositor probably loses any high-speed optimizations that only 
the real compositor can do. I really suspect the only use of a nested 
compositor will be to test a wayland server inside a window on another one.

> I don't think it's an unreasonable requirement, and really like the
> design it has at the moment, where attaching the scaler object
> suppresses the resize-on-attach behaviour, and destroying it reverts
> to previous.  It's pretty elegant, and totally in the vein of
> wl_shell_surface stacking on top of wl_surface.  I don't see how
> inventing more elaborate extension mechanisms on top of our existing
> extension mechanism helps anything.

No what I propose is to figure out how to document it so that the 
wayland api documentation is easier to follow. Make the rules for these 
sub-api objects match. Then I would expect to see the set-scaling listed 
under the wl_surface api. There would be a small indication that this 
api is through the wl_scaler subapi and the rest of the details would be 
  defined in a single section of the wayland documentation.