kwin thumbnail effect in Workspaces 2

[Martin Graesslin]

On Monday 21 January 2013 12:03:54 Aaron J. Seigo wrote:
> 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.
yes, the information must be available at the same time. It needs to come 
together with the damage events. That was the problem with the thumbnail 
effect: updating the property and the rendering where not in sync.
> 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.
The logic to determine the size of the thumbnail is not very difficult. We could 
provide a QML item (outside KWin) which has the same algorithm implemented and 
annotate code in KWin and the item to keep it in sync.

Not perfect, but better than setting some X properties...

--
Martin Gräßlin