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 <[email protected]> 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?
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
