more thoughts on kwin and window thumbnails in plasma shells

[Aaron J. Seigo]

On Tuesday, May 15, 2012 23:25:40 Martin Gräßlin wrote:
> On Tuesday 15 May 2012 20:35:01 Marco Martin wrote:
> > On Tuesday 15 May 2012, Martin Gräßlin wrote:
> > > On Tuesday 15 May 2012 14:13:24 Aaron J. Seigo wrote:
> > > > 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).
> > > 
> > > I am not sure whether that would work at all. What we have here are not
> > > normal textures but textures from pixmaps. I fear that this makes quite
> > > some difference especially concerning the damage events.
> > 
> > since kwin can draw thumbnails with the correct update window, i assume it
> > has the correct pixmap any given moment? can't that be shared?
> 
> We don't need KWin to share the pixmap - Plasma can play compositor any time
> it wants. But be aware that a window is composited through more than just
> the pixmap.
> 
> And now we are back to what I don't want to see any more: adding hacks on
> hacks to make hacks working. Seriously?

> do we need to pass X pixmaps around
> because we know that the activation of X properties is too slow?

well, sharing textures, which is a bit different. (yes, addressed using 
pixmaps, since those give a unique ID which gl textures don't on their own. 
this may be different on wayland, i don't know what is available in a wayland-
only case.)

but aside from semantics, yes, i'd rather share pixmap data because the 
activation of events across processes is too slow. one is slower than the 
other, one keeps painting control in one place while the other tries to get 
multiple processes to cooperate on it (with all the problems for interactivity 
and visual consistency i said would occur years ago when people bitched about 
plasmoids all being in the same process)

> Aaron's initial mail described actually yet another huge hack

how is publishing and sharing textures a hack?

note that i described how what we're doing now (and have tried previously) is 
a hack that causes problems.

> which is
> unknown to work on the future windowing system.

which windowing system does this not work on today?
why would a future windowing system drop this feature?
(there's a reason its there in the first place ...)

> Can we please step back and think about what we technically want to achieve
> and find the best way to achieve it. 

that is precisely what i did. thanks, though.

> I don't know whether moving the
> Thumbnails to KWin is the best way to achieve it, but technically it sounds
> more sane to me to move the complete rendering to KWin instead adding more
> hacks.

moving the complete rendering to kwin *creates the need for more hacks* 
itself. it is not the silver bullet solution you have convinced yourself it 
is. we know this because we've been busy separating different rendering and 
data paths from plasma-desktop and plasma-device for some time now to avoid 
this "all in one process" approach specifically because it has caused real 
world, user noticeable, unacceptable problems. i've enumerated some of them.

saying "let's do what didn't work, but this time over there" is simply not 
learning from history.
 
> Let's try to get our software working and not thinking about solutions for
> the case that our software is buggy. If we allow ourself to consider that
> software components could lock up, our users who blame us for bad quality
> are right. I want us all to get to a point where we don't have to even
> think in the direction of a compositor lockup.

with third party plasmoids and people writing plugins for plasma shells, this 
happens. even if everything is QML, it still doesn't give us a great answer to 
the "while (1) { hah(); }" problem.

let's also keep in mind that "lock up" can be seen at the small timeslice 
scale too.

we want, what, 60fps performance? let's be kind and say "nah, we're lowe 
achievers ... 30fps". that gives us 33ms ... which means to hit our goal, we 
need to have no code paths in the painting thread that spin the cpu for more 
than 33ms at a time; well actually, it means that no code paths can spin the 
cpu for more time than 33ms-$TIME_TO_COMPOSITE_THE_SCREEN .. and that's for 
just 30fps.

good luck.

no, let the kernel and GPU sort it out and let's partition processes where we 
reasonably can.

-- 
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/20120516/18edae6d/attachment.sig>