kwin thumbnail effect in Workspaces 2

[Aaron J. Seigo]

On Thursday, January 17, 2013 08:04:14 Martin Gräßlin wrote:
> 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

sounds good, particularly as it would keep all the UI interaction in the host 
application (e.g. the shell).

as you noted, it would need to be *fast* as that was one problem we had in the 
past with "kwin renders the thumbnails, but the UI is managed in the host 
application": the UI would update/change and the thumbnail painting would be 
out of sync with it.

this was particularly visible when there was custom chrome around the 
thumbnail, such as the close button in Active's Peek area. in fact, that is 
probably still a problem: the close button needs to be placed visually next to 
the thumbnail, which means the UI needs to know the thumbnail geometry.

i dislike the idea of trying to coordinate that geometry placement between two 
processes (it's the same genre of problem we have right now), so the chrome 
should be rendered with the thumbnail itself.

.. but then we have the issue of thumbnails of different sizes (widths, most 
often, as we tend to show them in horizontal rows right now). not all windows 
will thumbnail to the same size, and showing those in a row means spacing 
between items will be (visually) different.

in QML terms, the perfect solution would be an item than knows the geometry of 
the thumbnail it will be rendering, and then all of the above problems go 
away.

but if that QML item is not in kwin (something that should be avoided), that 
implies making information available from kwin about thumbnail sizes for 
specific windows.

(and all this to ensure that we have fluidly updating thumbnails ...)

-- 
Aaron J. Seigo
-------------- 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/20130121/67f7f96d/attachment.sig>