kwin thumbnail effect in Workspaces 2

Wed Jan 16 14:22:10 UTC 2013

On Wednesday 16 January 2013 14:12:16 Aaron J. Seigo wrote:
> 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.
true, but KWin has currently something like 5 kSLOC to correctly track the 
most recently used windows. I don't think we want to duplicate that somewhere 
else.
> 
> > > 		* 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?
both directions. Just because we are currently waiting for the vsync doesn't 
mean that we should not process X11 events and processing X11 events should 
not delay the next frame.
> 
> > > 		* 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.
sorry Aaron, that's not the case. It's not "one" pixmap, but up to six pixmaps 
(window, 4 decorations, one shadow) rendered together with the right margins, 
etc.

If you just want the window pixmap: go for it, it's all there through the X 
composite extension.
> 
> >           * 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.
quite a regression given that XRender has no problems rendering thumbnails.
> 
> so, which OpenGL drivers do not provide the necessary calls?
I cannot tell you by heart as this feature is not listed in the 
readoen/nouveau feature matrix. And it's not as simple as which driver 
provides it. It's a combination of several features and capabilities of the 
GPU.

If you want to look for it:
* GL_ARB_framebuffer_object
* GL_EXT_framebuffer_blit

blit is not necessarily required.
> 
> >          * 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?
we don't save thumbnails, we don't update thumbnails. We render on the fly 
when either the area where the thumbnail is, needs an update or if the 
thumbnailed window gets damaged.
> 
> >         * 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?
I was thinking in the direction of llvmpipe performance is not sufficient to 
render the thumbnails in the shell process. If we have to use llvmpipe we want 
to use as little as possible
> 
> > 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.
I have an evil idea
> 
> --
> 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/5bd72ff5/attachment.sig>