kwin thumbnail effect in Workspaces 2

[Martin Gräßlin]

On Wednesday 16 January 2013 12:13:39 Aaron J. Seigo wrote:
> hi all ...
> 
> currently, whenever there is a window thumbnail on screen, kwin paints it.
> on plasma desktop, this is currently not a big problem for our default
> setup since we only use them in tooltips on window listing plasmoids.
> 
> in Active, it has been and continues to be more problematic. this is because
> we use the thumbnails in an interactive UI: they *are* the window switcher.
> after trying other methods that didn't work overly well, the current
> approach is that kwin itself draws the entire window selection area and
> handles some of the events itself (in theory passing others through). this
> means that the "Peak" UI is party drawn and managed by plasma-device and
> partly by kwin. the result is ok, but is prone to breakage and we have to
> be overly careful when working around that part.
there have been more reasons to do it that way. One is that only KWin has 
information to the most recently used windows.
> 
> any other usage that might include showing window thumbnails (e.g. the
> "Plasmoid object class for QML" thread) also runs into problems.
<jedihandmove>there are no other usages</jedihandmove> - without having looked 
into the details of the thread: the usage of thumbnails has to be done very 
carefully. Yesterday I had been asked whether it would be possible to use the 
thumbnail instead of a window icon. That would be too small to recognize 
anything and I don't want to support such use cases (and no: but we can, is in 
this case not a valid argument). If someone can come up with a valid use case 
which is not in tooltips or for window switching, I might consider this. But 
at the moment I am not happy with any "might be interesting" discussions.
> 
> i don't think it is a scalable, long term solution in which we change the
> window manager as needed to accomodate new UIs, such as Active's Peak area,
> and insist on visual components knowing their system window ID.
> 
> an alternative is to allow passing of pixmap data from kwin to processes
> like plasma-device who can then handle the painting themselves.
> 
> the pros and cons, as i understand them currently:
> 
> KWin Does It All
> 	Pro:
> 		* minimal copying of data
> 		* guaranteed to sync with compositor updates
> 		* can guarantee no process has access to pixmap data (privacy
> concern; only interesting on Wayland, however)
> 	Cons:
> 		* requires kwin to provide workspace UI, which then must also blend
> with existing UI outside of kwin
> 		* commits CPU cycles to shell UI in kwin, which should be focused on
> compositing performance and window management for most fluid results
this is a non-issue once the compositing is done in a different thread - which 
is clearly on the TODO
> 		* any thumbnail using component must have access to its system
> window id
why?
> 		* requires adjusting how kwin does things if we adjust the shell UI
> (iow: they are quite tightly coupled right now)
and they should be, shouldn't they? How else do we want to provide a 
consistent user experience?
> 
> 
> KWin Provides Thumbnails:
> 	Pro:
> 		* complete flexibility in how they are presented in workspace UI
> 		* all event handling goes into the application displaying them
> 	Con:
> 		* rendering of thumbnails can only happen as quickly as the
> application (e.g. the shell) updates
          * providing the thumbnail slows KWin down
          * providing thumbnails requires OpenGL specific extensions not 
guaranteed to be present (fallback mechanism is known to be slow - not 
implemented in the screenshot effect, XRender, too)
         * proper downscaling (dependent on GPU capabilities) is completely 
lost - KWin would have to provide the unscaled variant to allow smooth 
transitions. To get the filters inside Plasma would need to copy the shaders 
and all the logic for GPU detection and what not
        * what about damage events?
        * what about window resizes, etc?
        * plasma running on llvmpipe (e.g. no OpenGL 2), while KWin runs on 
OpenGL 1/XRender, would be problematic (yes Intel GPUs will still be around in 
PW2)

I'm totally for improving the situation, but I see too many cons for providing 
thumbnails and too little gain :-(

A possible solution (which could also be extended) are KWin QML scripts. For 
those a window thumbnail QML item exists. It uses internal communication to 
render the thumbnail together with the window it's supposed to be rendered. 
This might be a path to investigate into.

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/20130116/cb69cdb5/attachment.sig>