kwin thumbnail effect in Workspaces 2

[Aaron J. Seigo]

On Wednesday, January 16, 2013 13:11:35 Martin Gräßlin wrote:
> On Wednesday 16 January 2013 12:13:39 Aaron J. Seigo wrote:
> there have been more reasons to do it that way. One is that only KWin has
> information to the most recently used windows.

you mean that it is the only process that currently tracks that information. 
there is no reason that it needs to be.

> > 		* 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

getting OT here a bit, but i'm curious: is this motivated primarily to keep 
window management from intereferig with compositing?
 
> > 		* 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?

not like this, no :) reuse of components is fine; turning UIs into compositions 
where multiple processes orchestrate rendering and event handling is brittle 
and increases the development costs significantly.

> How else do we want to provide a consistent user experience?

by not having half the UI in one process and half in the other.

in Plasma Active's plasma-device layout, it renders and reacts to events in 
the panel ... except the window strip, which kwin does.

to resolve the earlier problems encountered when kwin only did the thumbnails, 
we made kwin do the whole window strip. while it has been better, it still 
gives us problems like no other area of the UI does, and it requires working 
on two different code bases instead of keeping the UI for one component in one 
place.

having two processes cooperatively render and handle events in the same piece 
of UI is just nuts when one compares it to the simplicity and lack of possible 
things that can go wrong when one bit of UI is handled entirely in one 
process.

>           * providing the thumbnail slows KWin down

it already creates them. so that isn't going to change. the cost is sharing 
the pixmap, something that ought to be done on GPU.

>           * 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)

imho, we can count out XRender. "if you're on XRender, you don't get 
thumbnails." is acceptable to me.

so, which OpenGL drivers do not provide the necessary calls?

>          * proper downscaling (dependent on GPU capabilities) is completely
> lost - KWin would have to provide the unscaled variant to allow smooth
> transitions. 

i don't think there is any need (or call) for unscaled variants. all scaling 
should be done in kwin. the shell should simply get thumbnails of a given 
size. not downscaling in kwin would also represent a possible privacy issue 
due to being able to peak at window contents.

>         * what about damage events?
>         * what about window resizes, etc?

same way now: kwin handles that and updates the thumbnails appropriately. or 
are you saying that the thumbnails are only partially redrawn when a 
damage/resize happens?

>         * 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)

excuse my ignorance in advance: what is the problem for sharing pixmaps in 
this case?

> A possible solution (which could also be extended) are KWin QML scripts. For

and then we're still left with the issue of ensuring that the kwin window and 
the plasma-device window line up, that the right events are caught at the 
right places by the right processes and the development complexity of having 
to modify UI in two places.

we need something that allows all rendering and event processing to remain 
local. window thumbnails are the lone remaining issue with a split desktop 
shell / window manager, and if we can solve that then we have a near-perfect 
situation. it must be doable in some fashion.

-- 
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/114186d1/attachment.sig>