Protocol for window previews/thumbnails

[Pekka Paalanen]

On Tue, 10 May 2016 21:30:53 +0100
ade low <adloconwy at gmail.com> wrote:

> I think that it would be a good idea to have a standard, cross-compositor
> protocol for getting previews/thumbnails of windows, similar to XComposite.

Hi,

I strongly disagree. A huge part of Wayland's reason to exist is that
things like XComposite protocol are not necessary.

> This protocol should be as fast as possible and use as little system
> resources as possible. It should probably provide a handle to the native
> window surface.
> 
> It will also be necessary to receive damage events on these surfaces. I
> don't know if this should be included in this protocol or if this should be
> a separate protocol?
> 
> Does anyone have any ideas on the best way to design such a protocol?

"Don't do it" is the only answer based on just this information you
gave.

You should explain the use case behind the idea. Then it would be
possible to assess whether such protocol would even be appropriate for
it.

If some sort of protocol would be needed, then you have to figure out
how to not make it a gaping security breach, and how to not interfere
with other clients too badly or cause too much work for the compositor.
You would also have to figure out how and to what level to synchronize
things between at least four different actors: your client, the
compositor, a normal client, and the compositor again.

A little more tractable plan would be to communicate only surface
meta-data to the client, which could then ask the compositor to draw
the thumbnails relative to one of the client's surfaces. The client
would never have access to window content itself. However, then there's
the question of whether it can be a standard protocol or not.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160511/29c35258/attachment.sig>