more thoughts on kwin and window thumbnails in plasma shells

[Martin Gräßlin]

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? Already 
Aaron's initial mail described actually yet another huge hack which is unknown 
to work on the future windowing system.

Can we please step back and think about what we technically want to achieve 
and find the best way to achieve it. 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.
> 
> > > [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 ...
> > 
> > For the last point I don't understand any difference to the situation we
> > have right now. We are f*** up when the compositor locks up. Luckily I
> > have not heard of it for several years :-) Btw in 4.10 I want to work on
> 
> well, is just that when the world goes into the compositor, the probability
> of this happening skyrockets ;)
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.

Cheers
Martin
-------------- 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/20120515/4f9ec4f8/attachment.sig>