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

List:       openjdk-openjfx-dev
Subject:    Does styling opacities conflict with animation opacities?
From:       richard.bair () oracle ! com (Richard Bair)
Date:       2012-08-31 16:11:46
Message-ID: A92286F6-1C1C-4101-804C-0A63F3BB8868 () oracle ! com
[Download RAW message or body]

Ya, it seems like we'd be better off adding animation support to CSS.

On Aug 31, 2012, at 6:46 AM, David Grieve wrote:

> The inner workings of CSS may need to know about animations, but animations \
> shouldn't know anything about CSS. Just my $.02 
> On Aug 31, 2012, at 5:52 AM, Randahl Fink Isaksen wrote:
> 
> > I think I have a sound solution to this problem: What about simply letting the \
> > KeyValue pairs of KeyFrame specify if the KeyFrame *overrides* the CSS or if the \
> > KeyFrame *factors in* the CSS, so we will both have the original KeyValue \
> > constructor 
> > new KeyValue(someNode.opacityProperty(), 1.0); //absolute end value as we know it
> > 
> > which means we end at an absolute value of 1.0, and a new KeyValue constructor
> > 
> > new KeyValue(someNode.opacityProperty(), 1.0, true);
> > 
> > where 'true' means this KeyValue is true to (i.e. relative to) the value \
> > specified by CSS, so if CSS specifies 0.8 we end at 1.0 x 0.8 = 0.8. 
> > Could this be it? If so, I will file an RFE ? I do not presently have the \
> > available hours to put into this feature myself, but I do think this would be \
> > very powerful and useful. 
> > Randahl
> > 
> > 
> > 
> > 
> > 
> > On Aug 31, 2012, at 0:50 , Jim Graham <james.graham at oracle.com> wrote:
> > 
> > > Shouldn't the animation be from 0 to "whatever the node got styled with"?  \
> > > Otherwise you have a tooltip that fades in - overshoots - and then drops back \
> > > to .8.  It sort of smacks you in the face and then hangs back nonchalantly.  ;) \
> > >  So, whether or not the program is fixed to retrigger the CSS styling after the \
> > > animation, the animation itself is probably not "what you'd want" anyway. 
> > > It's easy to animate "from a current value to another value" by using a \
> > > timeline with no initial value, but it would be nice to have support to create \
> > > a timeline that animates "from this concrete value to whatever the current \
> > > value is".  Perhaps that could be achieved with a bit of work with an \
> > > auto-reverse timeline? 
> > > 	KeyFrame kf = (node.opacity = 0 at 1s)
> > > 	Timeline tl = new Timeline(kf);
> > > 	tl.setCycleCount(2);
> > > 	tl.setAutoReverse(true);
> > > 	tl.jumpTo(1s or whatever the time stamp of the KeyFrame is);
> > > 	tl.play();
> > > 
> > > (Caveat - I'm not a particularly knowledgable CSS/antimation expert so I'm not \
> > > sure if that sequence will properly capture the initial value or not...) 
> > > 			...jim
> > > 
> > > On 8/30/12 8:41 AM, David Grieve wrote:
> > > > 
> > > > On Aug 30, 2012, at 10:36 AM, Richard Bair wrote:
> > > > 
> > > > > Hi Randahl,
> > > > > 
> > > > > > This means our tool tips are just enough transparent that you can vaguely \
> > > > > > see the content behind it. To make the tool tips look nicer, we decided \
> > > > > > to animate then, so now when showing the tool tip, we fade it in by \
> > > > > > gradually changing its opacity from 0.0 to 1.0 using a FadeTransition. So \
> > > > > > up pops the question: What will the opacity be, once the fade transition \
> > > > > > ends? Will it be the 0.8 from the CSS, or the 1.0 from the \
> > > > > > FadeTransition?
> > > > > 
> > > > > The problem here is that whenever you set a property both from CSS and from \
> > > > > code, code not only will always win, but will disable that property from \
> > > > > being set from CSS henceforth. We used to have the rule that "last applied \
> > > > > wins" or "CSS always wins", and this led to very unsettling behavior to \
> > > > > developers. The current behavior appears to be much more intuitive. However \
> > > > > it means that until CSS animation support is added, you won't be able to \
> > > > > both style from CSS and animate the styled property :-(.
> > > > 
> > > > This is not entirely correct. If I have
> > > > 
> > > > Rectangle rect = new Rectangle(10,10);
> > > > rect.getStyleClass().add("rect");
> > > > rect.setOpacity(.5);
> > > > 
> > > > And this CSS in an inline style or an author stylesheet:
> > > > 
> > > > .rect { -fx-opacity: .8; }
> > > > 
> > > > Then the opacity will be set to 80% since an inline or author style overrides \
> > > > a user set style. If the same style was in a user agent stylesheet, then the \
> > > > user agent style would be overridden by the call to setOpacity (more \
> > > > correctly, the style will not override the call to setOpacity). 
> > > > The reason the Tooltip doesn't end up at .8 is because CSS is not applied to \
> > > > it after the tooltip is shown. It is styled once, but there is no reason to \
> > > > style it again. You can test this by adding a style for the tooltip's hover \
> > > > pseudo-class, for example, 
> > > > .tooltip:hover { -fx-fill: red; }
> > > > 
> > > > Hover over the tooltip and back out again and the opacity will be reset to \
> > > > 80%. 
> > > > As a hack, you can add an onFinished event handler to the transition that \
> > > > forces CSS to be updated by calling impl_processCSS(false) on the skin. 
> > > > final FadeTransition ft = new FadeTransition(Duration.millis(1000), \
> > > > tooltip.getSkin().getNode()); ft.setFromValue(.0);
> > > > ft.setToValue(1.0);
> > > > ft.setOnFinished(new EventHandler<ActionEvent>() {
> > > > @Override
> > > > public void handle(ActionEvent t) {
> > > > tooltip.getSkin().getNode().impl_processCSS(false);
> > > > }
> > > > });
> > > > ft.play();
> > > > 
> > > > > 
> > > > > The CSS engine though is completely in the open source, and at least at one \
> > > > > time we had a fairly simple idea as to how to go about doing the \
> > > > > animations. Perhaps you could work with David and contribute some code for \
> > > > > CSS Animations for FX 8? 
> > > > > In the meantime, your application will either have to set the opacity \
> > > > > exclusively from code, or from CSS. Alternatively you could do some hack, \
> > > > > for example having an empty Group in your app with the same style class as \
> > > > > the tooltip. Then the Group will have whatever opacity you set from CSS for \
> > > > > your Tooltip. Then when you animate you can animate from the current value \
> > > > > to whatever value the Group says it should be (but animating the tooltip of \
> > > > > course). 
> > > > > Thanks
> > > > > Richard
> > > > 
> > > > 
> > > > David Grieve | Principal Member of Technical Staff
> > > > Mobile: +16033121013
> > > > Oracle Java Client UI and Tools
> > > > Durham, NH 03824
> > > > Oracle is committed to developing practices and products that help protect \
> > > > the environment 
> > 
> 
> 
> David Grieve | Principal Member of Technical Staff
> Mobile: +16033121013 
> Oracle Java Client UI and Tools
> Durham, NH 03824 
> Oracle is committed to developing practices and products that help protect the \
> environment 


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