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

List:       kwin
Subject:    Re: Updates to effects
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2007-07-17 14:23:37
Message-ID: 200707171623.37885.l.lunak () suse ! cz
[Download RAW message or body]

On Monday 25 of June 2007, Philip Falkner wrote:
> 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

 Actually, this was the original idea with PaintData - to alter them 
relatively to their current values. That's why translating is done relatively 
to current position and why opacity changes are done by multiplying the old 
value. It's quite possible this may get pretty complicated for more complex 
cases, e.g. translating+zooming.

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

 This sounds rather complicated. With the intention as stated above, neither A 
nor B would want a resulting absolute value, so e.g. A would not want to go 
to half opaque window, but instead would reduce opacity by one half.

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

 Does it :) ? Well, if it makes sense for both of you, ok. I have no clue 
about this graphics stuff after all.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
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]