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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel