kwin thumbnail effect in Workspaces 2

[Aaron J. Seigo]

On Wednesday, January 16, 2013 15:22:10 Martin Gräßlin wrote:
> 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:
> > >           * 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.

so the current thumbnails are not one pixmap (with those various pieces 
rendered into it) scaled down, but 6 separate pixmaps each of which are 
individually downscaled and painted into place afterwards?

indeed, i was assuming that kwin had a fully rendered version of the window 
assembled and was down sampling that pixmap to create the thumbnail.

> If you just want the window pixmap: go for it, it's all there through the X
> composite extension.

that is of course also an option for these use cases, though obviously not as 
attractive in all of them. in plasma-device it would not really change the end 
result at all, since we are running full screen windows without decorations 
there anyways.

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

yes, it's tradeoffs.

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

right, so the same thing would happen, except into an off-screen pixmap rather 
than into the composited pixmap for the screen.

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

right, due to it being essentially equiv to the raster render backend we use 
now in terms of work done where (e.g. on CPU). not sure this will be a real 
issue given how thumbnails are used on the desktop (e.g. they aren't always 
shown, in their own window, smallish)

will discuss your evil idea with you on irc :)

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