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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
