[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-25 14:48:12
Message-ID: 200706251748.12106.rivolaks () hot ! ee
[Download RAW message or body]

Ühel kenal päeval (esmaspäev 25 juuni 2007) kirjutas Philip Falkner:
> > > Second is a new Fade.  Unashamedly taken from the compiz fade, it can
> > > now fade between any changes in opacity/saturation/brightness.  That
> > > is, it can handle fading for other effects.  The question I have is, do
> > > we want this? It gives us a single place for the user decide whether
> > > they want things fading in and out, and how quickly.  On the other
> > > hand, maybe effects are better off with different speeds for different
> > > purposes, e.g. should the fade in PresentWindows be able to be a
> > > different speed than the fade in DialogParent? I think the centralised
> > > way is better, but I'm open to being told that's wrong. :)
> >
> >  I think only practice will tell. Let's give it a try :).
>
> 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.

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

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.

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

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]