[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-07-05 19:59:05
Message-ID: 200707051559.05447.philip.falkner () gmail ! com
[Download RAW message or body]

On Tuesday 26 June 2007 13:07:44 Rivo Laks wrote:
> Ühel kenal päeval (esmaspäev 25 juuni 2007) kirjutas Philip Falkner:
> > On Monday 25 June 2007 10:48:12 Rivo Laks wrote:
> > 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 ;-)

Well, why not just have arbitrary numbers?  Let every effect have a "priority" 
number, e.g. 1 to 100 with 1 loaded first.  We ship effects with relatively 
spread out numbers (10, 20, ...).  Effects that don't interfere with each 
other could share numbers, like DimInactive and DialogParent.

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

Sorry, yes.  I meant that the final result of all combined animations would be 
the only guarantee, rather than how exactly it gets there.

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

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