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

List:       kwin
Subject:    Re: Updates to effects
From:       Rivo Laks <rivolaks () hot ! ee>
Date:       2007-06-26 17:07:44
Message-ID: 200706262007.44605.rivolaks () hot ! ee
[Download RAW message or body]

Ühel kenal päeval (esmaspäev 25 juuni 2007) kirjutas Philip Falkner:
> 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)

Something like that sounds quite fine, though perhaps there could be a few 
more for shaders and whatnot.
And we'll also need some kind of more descriptive names for them. That's the 
difficult part ;-)

> > > 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.

Actually we can't even guarantee the target. Target will be reached only if 
there are no more animations in progress. Shouldn't be that much of a problem 
though (we don't guarantee anything atm either).

> > 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.

Yeah, I think so as well. But we need some KWin API for that since the effects 
can't communicate among themselves.

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