[RFC] wl_surface scale and crop protocol extension

[Daniel Stone]

Hi,

On 2 May 2013 20:33, Bill Spitzak <spitzak at gmail.com> wrote:
> 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.

Sure, it's a thing you can do, but it's a lot more typing and
intrinsically discourages people from making nested or even just
simple compositors.  We want to lower the barrier to entry here,
rather than essentially just forcing everyone to use Weston always.

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

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.

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

I don't think having 'sub-extensions' makes anything more clear: in
fact, exactly the opposite.

Cheers,
Daniel