Not using the most efficient implementation by default seems overly harsh and likely to bias people against using GWT, so I tend to side with making the efficient one the default. Javascript programmers would usually react differently, by doing capability tests, and selecting the appropriate implementation at runtime. We are somewhat culturally constrained in the GWT world to think in terms of deferred bindings, but writing JSNI code that has multiple browser fallbacks into it is not necessarily a bad solution to bridge the timeframe in which we wait for browser upgrades.
If you consider something like iOS Safari, they upgrade the browser like once per year, so a policy that works well with Chrome I think harshly punishes Safari. -Ray On Sun, Jan 20, 2013 at 4:30 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > Thomas Broyer has posted comments on this change. > > > Change subject: Stop using prefixed API's in AnimationScheduler by default. > Firefox and Safari will use the Timer-based implementation. For Chrome we > can use requestAnimationFrame because it's unprefixed starting in Chrome 24. > ...................................................................... > > > Patch Set 1: > > (3 comments) > > FYI, Mozilla is discussing what to do wrt high-res timers: change mozRAF > (would break GWT 2.4 users like the Chrome change broke them already) or > only rAF. > > See https://bugzilla.mozilla.org/show_bug.cgi?id=753453 > > > .................................................... > File user/src/com/google/gwt/animation/Animation.gwt.xml > Line 27: <replace-with > class="com.google.gwt.animation.client.AnimationSchedulerImplTimer"> > According to "Can I Use" and the MSDN, it seems like IE10 has it unprefixed > already (with the same behavior as Chrome 24, which is the one from the > latest Editor's Draft). > > > Line 41: <!-- Disabled by default because it uses a prefixed API. --> > +1 > > I proposed it on the G+ Community too: > https://plus.google.com/114156500057804356924/posts/45D9ZfZkF28 > > The default value is controversial though. I'd lean toward setting it to > true by default and documenting it prominently in the developer guide (and > possibly even emitting a warning at compile-time). Let's discuss it in > GWT-Contrib though. > > Ideally, there should probably be a property per module, whose default value > is controlled by a global property declared in c.g.g.core.Core. Something > like: > > <define-property name="animation.useExperimentalApis" values="true,false" > /> > <set-property name="animation.useExperimentalApis" value="true"> > <when-property-is name="useExperimentalApis" value="true" /> > </set-property> > <set-property name="animation.useExperimentalApis" value="false"> > <when-property-is name="useExperimentalApis" value="false" /> > </set-property> > > > .................................................... > File > user/src/com/google/gwt/animation/client/AnimationSchedulerImplNative.java > Line 60: * create a JavaScriptObject and add an expando named "cancelled" > to indicate > The Javadoc doesn't match the implementation. We should fix *ImplMozilla > too. > > > > -- > To view, visit https://gwt-review.googlesource.com/1780 > To unsubscribe, visit https://gwt-review.googlesource.com/settings > > Gerrit-MessageType: comment > > Gerrit-Change-Id: I3011dceab489871a5864eed1ece47ec850d82425 > Gerrit-PatchSet: 1 > Gerrit-Project: gwt > Gerrit-Branch: master > Gerrit-Owner: Brian Slesinsky <skybr...@google.com> > Gerrit-Reviewer: Goktug Gokdogan <gok...@google.com> > Gerrit-Reviewer: Thomas Broyer <t.bro...@gmail.com> > > Gerrit-HasComments: Yes > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
