[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: RFC: How to blur boxswitch background?
From:       Thomas =?iso-8859-15?q?L=FCbking?= <thomas.luebking () web ! de>
Date:       2010-06-07 13:17:18
Message-ID: 201006071517.18386.thomas.luebking () web ! de
[Download RAW message or body]

what about adding support for a global blur region that applies after all 
windows have painted? (eg. as property on the root window)
boxswitch sets some region in prePaintScreen and blur blurs is in paintScreen. 
you only have to ensure that blur is the last effect in the queue, so you can

boxswitch::paintScreen()
{
	effects->paintScreen(); // calls blur::paintScreen(), blurring the screen
	drawTabBox();
}

this would allow us to blur arbitrary regions, independent of 
<superspecialitem_aka_effectframe> usage ;-)
(eg. for some logout or modal blocking etc.)



Am Sunday 06 June 2010 schrieb Martin Gräßlin:
> Hello fellow kwin devs,
> 
> I thought about how to fix the problem that the background of the box in
> boxswitch effect (and in general EffectFrames) does not get blurred. I
> found some possible solutions and would like to get your opinion on what's
> the best approach.
> 
> 1. Extend tabbox in a way that it is able to replace the boxswitch. As we
> could use Taskbar Thumbnails and Highlight Windows the boxswitch
> functionality is rather easy to implement. But the configuration has to be
> changed completely as the thumbnail view would be a layout mode and not an
> effect and fallback to "No effect" could be difficult. Showing the box in
> CoverSwitch might be difficult, too.
> 
> 2. Use a Plasma themed window instead of an EffectFrame for the box. That's
> what Compiz does in the KDE plugin. The disadvantage is, that it becomes a
> window which has to be painted on top of everything else and we already use
> elevating the currently selected window. And it's not a general solution,
> but just a solution for Boxswitch.
> 
> 3. Do the general way: EffectFrame becomes a window. This would be quite
> handy, but has the disadvantage that the EffectFrames have to be painted on
> top of some windows (e.g. in Present Windows). And it would not fix the
> issue for blur as blur skips fullscreen effects (so no blur for
> EffectFrame in CoverSwitch, Cube, etc.)
> 
> 4. Pipline all rendering calls to EffectFrame through all effects. So
> EffectFrame::render() will trigger an effects->drawEffectFrame() which will
> invoke the Effect::drawEffectFrame() hook in each effect. This would
> require to add an EffectFramePaintData, so that we can translate or change
> opacity of the EffectFrame. Finally painting the EffectFrame would be
> moved from kwineffects into SceneOpenGL and SceneXRender.
> 
> I think the fourth option is the best one as we would not have to change
> any effects and just add the new hook to blur (and invert).
> 
> So any comments?
> 
> Martin

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

[prev in list] [next in list] [prev in thread] [next in thread]