cross-client surface references

[Daniel Stone]

Hi,

On 8 July 2015 at 18:46, Bill Spitzak <spitzak at gmail.com> wrote:
> All your objections sounds like you are confusing the implementation with
> the abstraction that the client program sees. A few examples:

No, not at all. On the contrary ...

> On Wed, Jul 8, 2015 at 4:47 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>
>> > Yes this also creates
>> > multiple C structures in the server, to keep track of the actual client
>> > communication, but for most documentation you act as though there is one
>> > "object" that all the clients are "sharing".
>>
>> Please point out that document so it can be burned to the ground and/or
>> fixed.
>
> Description of wl_output:
>
>       This object is published as global during start up, or when a monitor
> is hotplugged.

OK, let's fix that.

> That certainly implies there is one wl_output per monitor. Not one per
> monitor * client. You seem to be thinking about how many "publishing" events
> have been sent by the compositor to all the clients, or perhaps how many
> wl_proxy objects have been created by clients for wl_outputs, but that is
> not a number that anybody, including the person who wrote the above
> documentation, is thinking about. The programmer thinks there is a wl_output
> for each physical monitor, and that since the client program cannot destroy
> or create monitors, and monitors continue to exist when all the clients
> exit, that there is a single shared wl_output object.

>From a compositor implementation point of view, you have one
weston_output structure. This is true, but irrelevant.

>From a protocol point of view, every time a client calls
wl_registry::bind in response to an advertised wl_output global, a new
and unique wl_object is created. If you don't believe me, read the
compositor source, or look at the output of $WAYLAND_DEBUG, or
anything really. They are completely and totally independent objects.

> Also your claim that state is not "shared" is false. Every client will get
> matching geometry events for a given wl_output (or if you insist, it will
> "get a matching geometry event for each wl_proxy that they created using the
> global id that the server advertised for it's internal data structure that
> represents the state that a wl_output created by the client for that id will
> see").

That is not state.

Let's extend your example out a bit. We have one weston_seat with one
weston_pointer. Two clients each create wl_seat and subsequently
wl_pointer objects from the weston_seat and weston_pointer. Each
client then calls wl_pointer::set_cursor with a different cursor. Is
the state shared, or are they in fact different objects?

>> It is totally possible for the client to destroy global objects: send,
>> e.g., wl_compositor_destroy(). Great, object gone.
>
> Another client (or even the same one) is certainly able to assocate an
> objectId with the state inside the server that every sensible programmer in
> the world will call "the wl_compositor". It is not destroyed in any way!

I consider myself a sensible programmer who's fairly au fait with
Wayland, and I would not refer to the aggregation of every
wl_compositor object created by every client (or indeed multiple times
per client) who connects to a single compositor as 'the
wl_compositor'. They are independent objects with independent
lifetimes. Suggesting otherwise is a strong indication of a massive
misunderstanding of how objects in Wayland work; again we need to fix
our documentation perhaps, but that does not change objective facts.

> In any case I would like to see if the idea of nested compositors will work

It already works. Browsers are already doing this today. They have
been for ages now ...

> since that seems to be your goal. However it looks like a nightmare of
> complexity and confusion for programmers. How exactly do you plan to send
> every type of buffer with zero copy through the intermediate client? Does
> the client have to know about every single type of memory sharing, or will
> the subclients be prevented from taking advantage of server capabilities
> because the intermediate clients are too old? What about the overhead of
> virtually every message having to be decoded and recoded by the intermediate
> client in both directions? What about messages that need an xdg_surface
> (such as the parent surface) that the child did not create?

... so I'm disregarding the rest of this paragraph. Of your questions,
two of them are long-solved problems, one is irrelevant since it would
occur anyway with your global object scheme, and one makes absolutely
no sense since it bears no relation to the actual design and
implementation of real, implemented, working, nested compositors.

Let's drop this thread, and if we need to, carry on in a separate
thread with suggestions for improvements to the documentation to help
you understand how objects in Wayland actually work.

Cheers,
Daniel