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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
