From kwin Tue Jul 17 14:23:37 2007 From: Lubos Lunak Date: Tue, 17 Jul 2007 14:23:37 +0000 To: kwin Subject: Re: Updates to effects Message-Id: <200707171623.37885.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kwin&m=118468224815967 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