kwin thumbnail effect in Workspaces 2

[Martin Gräßlin]

I have thought about it a little bit more. What you actually want is having 
the UI completely in one place. You don't want to have the thumbnails, you 
want to be able to render/implement the UI in a way as if you have the 
thumbnails. Passing the thumbnails from KWin to Plasma is one possible way to 
achieve that, but not the only one.

I don't like the idea of making KWin into a thumbnail providing service and I 
see the following major disadvantages in it:
1) KWin needs to create the thumbnails and keep them around
2) Thumbnail providing would have to be implemented in each compositing 
backend
3) KWin would have to track changes to windows and update the thumbnails 
without knowing whether it would ever be needed (KWin doesn't know where in 
Plasma the thumbnail is going to be used, so it's possible that it gets 
filtered out in the final compositing stage)
4) a protocol is needed to communicate with Plasma

I had thought about the requirements of the last bit and came up with:
* KWin needs to send damage events when the thumbnail data is modified
* KWin has to provide a shared memory buffer with the thumbnail data
* KWin has to provide a new buffer whenever the geometry changes
* Plasma needs to tell KWin when it needs the next updated buffer

This sounds exactly like Plasma becomes a Wayland server and KWin becomes a 
Wayland client. In fact if we would go for this solution I would suggest to 
use the Wayland protocol.

But I'm against this solution and given what I wrote above it would violate 
some design decisions we did like not merging compositor into the desktop 
shell. If we add a Wayland server component to Plasma I am going to question 
why we don't go the full GNOME Shell/Unity road which doesn't require the 
overhead of thumbnail management.

So far so good, I hope we can just scratch that idea :-)

That means we need another way to achieve what Plasma needs and that would be 
KWin continues to render the thumbnails. What we had seen in the past when we 
tried it, is that the thumbnail effect is not sufficient for our needs. And I 
can see how that happened: the thumbnail effect had not been designed for the 
needs.

Nowadays we have inside KWin the facilities to have thumbnails which get 
updated and rendered in a fast way. We need to make it possible to let Plasma 
use this code path. And for this we need a small protocol which is one thing: 
fast.

So my suggestion is to send updates for needed thumbnails together with the 
damage events. We have to look into how we can achieve it, but it would bring 
some advantages:
* existing code path inside KWin can be reused
* thumbnail is always the latest version
* no memory read-backs from GPU
* if thumbnail is not needed (because area is not rendered) it can be 
discarded

So what do you think about that? Would that be a solution which could work for 
you?

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130117/6024d161/attachment-0001.sig>