kwin thumbnail effect in Workspaces 2

[Aaron J. Seigo]

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.

any other usage that might include showing window thumbnails (e.g. the 
"Plasmoid object class for QML" thread) also runs into problems.

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
		* any thumbnail using component must have access to its system 
window id
		* requires adjusting how kwin does things if we adjust the shell UI 
(iow: they are quite tightly coupled right now)


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

you can flip most of the Cons into "Pros" for the other solution, but for 
brevity i didn't bother :) 

also, the privacy issue can be addressed at least in part by kwin only 
providing scaled-down thumbnails. it may even be possible to only allow access 
to "blessed" processes, though i'm not sure that's entirely realistic.

i would like to see a transition from the current method of "kwin does it all" 
to "kwin provides thumbnails", though i do not think it makes any sense to do 
so before Workspaces 2 for the following reasons:

* we have other important things to accomplish between now and then; the 
current method mostly works, so we can prioritize it down the list

* i don't know if QGraphicsView is up to the task, performance wise, but i 
have high hopes for QML scenegraph given what we've seen with it already

but i'd like to work out a gameplan now so we can work towards it in 2013 :)

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