Protocol for window previews/thumbnails

[Derek Foreman]

On 11/05/16 03:07 AM, Pekka Paalanen wrote:
> 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.

Right - and I'll be quick to stand behind Pekka on this one.

I think this is generally considered something that should be done
inside the compositor - but I also think the compositor itself could
expose some manner of API/modular interface/whatever to allow external
code to do this.

That is, wayland protocol is not required for a compositor to allow this
to happen.  And this is a key point people miss when "wayland refuses to
support external task switchers" or whatever shows up as a thread on
reddit. :)

Wayland is not preventing desktops from allowing third party application
switchers/pagers/previewers.

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

FWIW, if I had to address this problem, that is probably the route I'd take.

There are a lot of different buffer objects and formats to deal with,
and the compositor already knows how.  Also, keeping the actual contents
out of the hands of other applications (not just for security, but to
keep them from leaking giant chunks of shmem or screwing up timing)
seems like a win.

But I'm of the opinion that this doesn't need to be a "wayland" problem
at all - but I'm not saying there can't be a standard way to do this.

It just doesn't need to be solved by adding wayland protocol.  A common
module framework for compositors that find this functionality useful
would probably perform better and have less complexity.

Thanks,
Derek

> 
> 
> Thanks,
> pq
> 
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>