more thoughts on kwin and window thumbnails in plasma shells

[Aaron J. Seigo]

hi all ...

after the last thread where "put plasma-desktop into kwin" came up i looked 
for the actual pain points we suffer right now.

the main one, and honestly the only one i could really find, was the window 
thumbnail issue.

so ... the problem is that when plasma-desktop asks kwin to paint the 
thumbnails in a given region, then we have latency issues: application changes 
the region, a series of asynchronous events occur, kwin finds out about the 
change and schedules a repaint.

when this is moved to kwin, then that process is MUCH smoother (obviously: 
kwin manages all the painting :) but then we have event forwading that has to 
happen (ugly) and again we have async events being pushed from one process to 
the next and it isn't particularly smooth.

i reject the "obvious" solution of throwing everything into one process 
because it causes more problems that it solves (interactivity, compositor 
frame rates, stability isssues[1]). as marco noted when we were discussing the 
issues: the grass is always greener on the other side. well, let's not fool 
ourselves ...

so what's the less obvious solution? render the plasma shell with OpenGL. 
we're heading in this direction already and wish to be there with QML2. how 
does this resolve the window thumbnail issue? you can share GL textures 
between processes. this is dependent on the OpenGL stack on the system (it is 
not something OpenGL itself provides and it is done different on windows than 
x.org; probably different again in wayland), but it works. in fact, we found an 
example that does exactly this in zack's graphics dojo repo from when he 
worked at trolltech (yes, trolltech .. before nokia).

this will keep all the rendering on the GPU but control of the painting to 
each process where it makes sense -> kwin to paint the thumbnail content, 
plasma-<device target> to paint the thumbnail in its UI.

this makes the transition to opengl for the shell even more important as a 
goal to hit. and that's a good thing.

(i haven't yet looked into if it would already be possible to do this now with 
current shells; it might be possible in places, but i expect it would be less 
than pretty and would not be a generic solution ..)

(and this is one more example of why rejecting the obvious answer because it 
too sucks can drive one to find better solutions)


[1] this goes beyond crashes and extends to busy loops -> consider if the 
compositing process locks up .. how does the user then go about fixing it? 
can't see any input or windows -> compositor is still running, just not able 
to paint ...

-- 
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/20120515/9b243d4e/attachment.sig>