cross-client surface references

[Bill Spitzak]

All your objections sounds like you are confusing the implementation with
the abstraction that the client program sees. A few examples:

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.

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.

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

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!


In any case I would like to see if the idea of nested compositors will work
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150708/7afcca55/attachment.html>