I just wanted to share my thoughts about the recent chrome animation bug and how this could be avoided in the future. If I missed some follow-on discussion about this, please give me a link because I haven't seen anything. If you're not sure what I'm talking about, see these two links:
https://groups.google.com/d/topic/google-web-toolkit/UBWsvHYM4SE/discussion http://code.google.com/p/chromium/issues/detail?id=158910 The basic problem was that com/google/gwt/animation/client/AnimationSchedulerImplWebkit.java used prefixed javascript APIs (webkitRequestAnimationFrame and webkitCancelRequestAnimationFrame). Prefixed APIs are experimental and unstable. Chrome changed their implementation, which is their right, but this broke a bunch of deployed GWT applications and many people were frustrated. Chrome then reversed the implementation of their prefixed version, implementing the non-prefixed version to spec, and this issue should be resolved. In this specific case, using the AnimationSchedulerImplTimer worked fine and is the workaround I suggested and some people have used. I would suspect that in most cases, there is never a requirement to use a prefixed API and a non-prefixed alternative could be provided, even if it might be less desirable. Our application is used by 100s of customers and typically deployed behind their firewall. We release often, but some of our customers only update once or twice a year. If their browser is Chrome, their browser will be updated much more frequently and beyond our control. Because of this, we would prefer not to use unstable APIs in our code. *What I would like to see is an option, either a compile flag or a property in the .gwt.xml file, to toggle the use of unstable prefixed APIs.* For certain applications, like implementing Quake in GWT (which is awesome http://www.youtube.com/watch?v=XhMN0wlITLk), it will be necessary to use some prefixed APIs. For other applications like ours, stability is extremely important. We like using GWT because we can develop more solid code and have great tools. We see it mostly as a Java to Javascript compiler that neutralizes browser differences. We don't use uibinder, cells, activities/places, etc. Part of this is because we started using GWT at 1.5 and implemented our solutions for these things. Based on the responses to the two threads I linked above, I think there are other people using GWT who would also prefer stability over using prefixed APIs. I'd appreciate hearing your thoughts. Andy Keller http://tractionsoftware.com http://code.google.com/p/gwt-traction/ -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
