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

List:       kwin
Subject:    Re: Updates to effects
From:       Philip Falkner <philip.falkner () gmail ! com>
Date:       2007-06-25 20:52:56
Message-ID: 200706251652.57299.philip.falkner () gmail ! com
[Download RAW message or body]

On Monday 25 June 2007 10:48:12 Rivo Laks wrote:
> Ühel kenal päeval (esmaspäev 25 juuni 2007) kirjutas Philip Falkner:
> > I've found an issue with this new fade (hence not committed).  It only
> > works for those effects that are loaded before it, which currently means
> > by default effects whose names come before the letter F.  I can't think
> > of how to guarantee the fade code will run only just before
> > finalPaintWindow(), unless we either add a new hook there, make some way
> > for effects to influence their loading order, or incorporate this fading
> > code (i.e. the bit that smoothly animates changes in
> > opacity/brightness/saturation, NOT the decision to fade on
> > windowAdded/Closed) into kwin proper.
>
> We need some kind of ordering for effects anyway, it's in my TODO list.
> BTW, you can see a similar bug when PresentWindows is loaded after Shadow -
> the shadow is where untransformed window is, even when PresentWindow has
> actually transformed it.
> I'm thinking of adding some kind of categories for effects, so e.g. Fade
> category could be one of the last ones to affect the window, so all other
> changes have already been made by the time Fade kicks in.

You're right, that does break.  What sort of categories were you thinking of?

I just took a quick look through the effects, looking especially and 
Screen/WindowPaintData.  Most seem to either alter the values relative to 
whatever they were, or outright ignore them.  The interesting ones were:
  Explosion sets window.x/yScale absolutely
  Magnifier sets screen.x/yTranslate absolutely (2nd pass only)
  PresentWindows can set window.scale/translate/opacity absolutely (other than 
initial animation)
  Zoom sets screen.xy/Translate absolutely
  
  Fade alters window.op/br/sa based on window.op/br/sa
  Shadow draws the shadow based on window.scale/translate/opacity

I'm ignoring other kinds of changes (e.g. vertices, shaders).  Still, I'm 
imagining five categories:
1) initial absolute changes (Zoom?)
2) effect doesn't care what came before (DialogParent, DesktopGrid?)
3) effect cares about what came before, makes changes (Fade)
4) final absolute changes (PresentWindows?)
5) effect cares what came before, no changes (Shadow)

> > I like Rivo's idea of having an interface for changing window appearance
> > (WindowPaintData?) in a time defined by the requestor, e.g. change
> > saturation to 0.4 in 150ms.  I wonder how complex/simple it might be.
>
> I'm not sure either. What if effect A wants opacity to go from 1 to 0.5 in
> 1 sec and effect B wants it to go to 0.4 in 2secs?
> In 1 sec A wants opacity to be 0.5 and B wants 0.7, so we could use 0.6
> (average).
> But then what? Will we use 0.4 (as B wanted) after another second has
> elapsed? I guess that's the best way, using e.g. speed of change could
> sometimes result in opacity going e.g. below 0.

That makes the most sense to me; neither effect will get exactly what it asked 
for during the animation, only the target is guaranteed.

> So for each property we'd have a list of active transformations, each
> having target value and time left (before the target value should be
> reached). With some math we can calculate wanted current value of the
> property for each transformation and then take the average of them and use
> it.

Makes sense.  Should work for all Screen/WindowPaintData changes, I think.

> > By the way, almost unrelated, is there any practical reason why effects
> > shouldn't use KConfigXT vs. the KConfig stuff in EffectsHandler?
>
> I don't see what you mean here? Using KConfigSkeleton objects?

Yes, exactly.  Setting up the appropriate .kcfg files with cmake, then using 
KCModule::addConfig(KConfigSkeleton*, QWidget*).  I've whipped up a version 
of Fade and FadeConfig which uses this.  I'm just wondering if this could 
conflict with the existing configuration methods, e.g. locking issues, ...?

-- 
Philip Falkner

["fade_and_kconfigxt.patch.zip" (application/x-zip)]

_______________________________________________
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]