On Tue, 18 Feb 2014, Bill Spitzak wrote:
On 02/18/2014 11:09 AM, Mark Thomas wrote:
The "hole" and "plug" are meaningful objects and are needed, at least
server-side, for some associated state. They're also helpful for
limiting the amount of uid-dipping a client can do, as only holes and
plugs have uids.
I proposed that the "uid" be an encrypted number so clients can't guess them
(or "dipping" as you call it). Basically if the server is asked for the
object for a given uid it fails if it is not a number recently delivered by
it to another client.
I've essentially done that, although the uid is more of a nonce. Even a
random number can be guessed or snooped.
Otherwise you are going to have to create a "hole" and
"plug" object for every single Wayland object.
Only the ones you want to embed. It's a rare occurrence. Plus creating
objects is easy because the wayland protocol is very lightweight.
Also you can't create a subsurface without both
surfaces available, so there is a chicken-and-egg issue, too.
I don't understand this. Obviously when the subsurface is created there is
only one surface available (the parent) because the subsurface is not created
yet. That is why I have A create the subsurface. B is still in charge of the
buffers so there seems to be no problem here.
I suggest you read up on the subsurface protocol. A "subsurface" object
takes two "surface" arguments, one is the parent to attach to, and the
other is the child surface that becomes the subsurface.
Having thought about it, I think I'm in agreement with Pekka and the
others that a generic interface is probably not appropriate, as the
requirements change depending on the use case. What's probably more
useful is making it easy for shell plugins to do it the way they want.
So that's my plan.
I don't like the idea that we are saying that things like Firefox have to be
shell plugins.
I think things like firefox are potentially better served by passing
through the buffers from the plugin, rather than the plugin connecting to
wayland itself -- a parent-child relationship rather than a sibling one.
That way it gets to do things to the buffer synchronously as it passes
through (like crop or scale it)*. I think this is what is meant by the
"subcompositor" model.
It sounds like it could work, though I expect there would be lots of edge
cases to work through.
Until someone actually tries it, though, this is all just hot air.
* - I had an idea for smooth, synchronized resizing and scrolling, where
the outer client requests the inner client provide it a buffer with an
extra amount of rendered data around the outside of the subwindow that it
is providing. The outer window crops this buffer to the correct
dimensions (by asking the compositor to do so) and also draws the border
of the subwindow and its scroll bars. Then the outer client can scroll
and resize synchronously by repainting the existing buffer it has with a
differenct crop region, whilst asynchronously requesting a new buffer from
the inner client with the new geometry. I think this would work pretty
well for the "document viewer" class of use case. Just an idea, though.
I don't plan to do anything with it.
--
Mark.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
