Freigeben über

Trying to get the story straight [A brief summary of Storyboard differences between WPF and Silverlight]

  • Artikel

**

This blog has moved to a new location and comments have been disabled.

All old posts, new posts, and comments can be found on The blog of dlaa.me.

See you there!

Comments

  • Anonymous
    April 28, 2009
    Mais uns links que gostaria de partilhar, juntamente com umas leituras para esta semana:   LINQ

  • Anonymous
    April 29, 2009
    Thank you for submitting this cool story - Trackback from DotNetShoutout

  • Anonymous
    April 29, 2009
    I also noticed issues in WPF when not specifying a from value in your storyboard, where Silverlight just animates from the current value. I've made it a pattern to always animate using a from value, to avoid issues when porting to WPF.

  • Anonymous
    April 29, 2009
    Is the jitter just caused by WPF recomputing things based on the new From?  that seems logical to me..

  • Anonymous
    April 29, 2009
    toshok, That seems like a reasonable guess - but once the animation has begun, it doesn't seem to me that the original From should be affected by changes to the local value. In other words, the From value has already been captured and I shouldn't be able to re-write the past by setting a new local value after the fact. :)

  • Anonymous
    May 17, 2009
    Introduction In the previous article on my Blog we have implemented a Panel with 3D (or rather projections)

  • Anonymous
    February 12, 2010
    Fascinating. Just ran into this post. I have the Silverlight 4 runtime installed and the (above) Silverlight harness still behaves the same. For that matter, I just tried WPF 4 and it still jitters. So, it seems these issues haven't been declared bugs and/or fixed. Maybe it's because I come from a WPF mindset, but I agree with your allotment (red and green) of what seems correct behavior and what doesn't. I will definitely keep this difference in behavior in mind.2

  • Anonymous
    February 13, 2010
    cplotts, Remember that Silverlight operates in "compatibility mode when running a XAP targeting a previous version of the framework. Therefore, it's necessary to change the target version of a Silverlight project and re-compile it for Silverlight 4 when performing a test like this. I've just done so and my findings were that a recent (internal) build of Silverlight 4 now shows the correct (WPF) behavior for the first case, retains the same incorrect (non-WPF) behavior for the second case, and remains correctly non-jittery in the third case. WPF v4 Beta (sorry, I don't have the RC installed on the test machine) maintained all the same behavior that WPF 3.5 had: correct for the first two cases and the jittery in the third case. So there's no change in WPF for v4 and Silverlight v4 has fixed one of the two problem cases. Progress! :) I've already followed up on the Silverlight situation internally and will pass this information along as well. Thanks very much for reminding me of this!

  • Anonymous
    February 15, 2010
    I am unfamiliar with this compatibility mode and just assumed that it was running as a Silverlight 4 application. So, thanks for clearing that up. Also, it is good to hear that one of the problems has been fixed. Did you contact the WPF team as well? The WPF behavior definitely seems broken. Yuck.

  • Anonymous
    February 15, 2010
    cplotts, Regarding Silverlight 4's remaining non-WPF-compatible behavior from the second scenario of the table above (the one where an animation is run from A->B then a local value C is set after the animation completes and enters the HoldEnd state), I've just checked with the area owners on the Silverlight team and they tell me that this difference is actually deliberate. Specifically, their experience is that what most users expect (and I agree with them) is that setting a local value after an animation has completed should take effect immediately. The WPF behavior in this scenario is simply too difficult for most developers to diagnose when they encounter it, so the Silverlight team has decided that the current behavior of the Silverlight platform leads to a better developer experience. PS - I've sent mail to the WPF team about the one quirky WPF 4 behavior. They're pretty busy right now, though - I may not hear back for a bit. :)