On Thu, Jul 2, 2009 at 8:03 AM, Joel Webber <j...@google.com> wrote: > > CSS Animations: > I think we need to actually measure the performance difference before > deciding whether it's even worth the trouble. I suspect that there may not > be much of one (though of course I could be wrong), given that it has to do > the same work, possibly including layout, regardless of how it's specified. > And CSS animations aren't as general as programmatic ones. That said, there > might be some utility in having CssResource parse them automatically and > write the necessary code for you on older browsers (though I haven't > assessed the feasibility of doing so). >
It might be useful however to create an animation library that consists of declarative types, as well as custom animation types. If you compose declarative types, you potentially get CSS Animations or SMIL or HTML+TIME (IE), if you include a custom type (uses Java code) in the composition, then you get a pure programmatic fallback. Think of it as a type-safe enumeration pattern, where some types have deferred bindings (CSS Anim, SMIL, or pure JS) and others are just pure-JS. > Canvas: > This is a nasty case, because Canvas cannot be implemented sanely or > efficiently on top of VML, which is the only game in IE town. Existing > canvas-on-VML implementations notwithstanding -- they have wildly different > performance semantics, which is pretty unacceptable in my opinion. > It's possible to use Flash, but in general, performance can't come close to matching HTML5 canvas, not just because IE Javascript is so slow, but also because marshalling/unmarshalling between JS and Flash is slow. A bright spot is Silverlight, since the JS->Silverlight call mechanism is pretty efficient. On the downside, you can't depend on Silverlight. Canvas is also split, since some Canvas impls support text rendering and others do not. > > SVG: > Things are a bit brighter here. There are some things (foreign objects > and certain gradient patterns come to mind) that SVG can do, which VML > cannot. But a sane navigation of the common features could lead to a quite > usable and efficient vector graphics library. There's the existing GWTCanvas > that Jaime wrote a while back as a starting point (which uses Canvas rather > than SVG), but it appears to me that SVG performance has gotten a lot better > since that was written, so it's probably worth reconsidering that approach. > Brad Neuberg is actually working on a fairly complete SVG shim for IE using Flash, it appears performance and compatibility are good. > <audio>, <video>: > I'm not terribly bullish on these. <audio> is at least theoretically > supportable using Flash, and I could see something like the SoundManager2 js > library taking advantage of it. But <video> is rife with codec licensing > problems that seem unlikely to get resolved any time soon (If anyone wants > to debate the ins and outs of codec licensing, let's *please* do so on > another thread, because I can tell you from experience that the thread won't > converge). > There's also the case that doing anything more interesting with <video> other than playback means accessing frame pixel data, and shipping them from Flash back into the browser would be *VERY* inefficient and slow. -Ray > > And of course, there are probably others I'm not thinking of, so feel free > to chime in with ideas. > > joel. > > On Wed, Jul 1, 2009 at 1:09 AM, nicolas de loof > <nicolas.del...@gmail.com>wrote: > >> Transparent support for CSS3/HTML5 on all browsers including IE would be a >> killer feature !+1 >> >> 2009/7/1 tfreitas <tfrei...@gmail.com> >> >> >>> +1 >>> >>> On Jun 29, 10:24 am, dflorey <daniel.flo...@gmail.com> wrote: >>> > Hi, >>> > I've been wondering how GWT should deal with upcoming new features in >>> > HTML5/CSS3. >>> > There are several areas where functionality that has been implemented >>> > in GWT is now also available in the upcoming rendering engines. >>> > >>> > GWT is creating highly optimized JavaScript and the JavaScript-engines >>> > are getting better and better... but: My guess is that for example >>> > animations will be smoother when using CSS3 animations instead of >>> > JavaScript based animations. >>> > Same about rounded corners/shadows and stuff alike. In GWT you'll >>> > typically use DecoratedPanel to implement rounded corners with >>> > shadows. But Firefox3.5 and the latest Safari and Chrome releases also >>> > support css-based rounded borders and shadows. >>> > >>> > So my proposal would be to use deferred binding to "emulate" these >>> > features on browsers that do not support the latest features (IE8...) >>> > and to use a lightweight css based impl on WebKit/Firefox 3.5. >>> > >>> > In my example of DecoratedPanel the 9x9 approach should be kept for IE >>> > and a null impl with css based rounded corners should be available for >>> > Firefox (css have to match the given theme). >>> > Animations that come with the standard widgets should also be able to >>> > fallback to css based animations when available. >>> > >>> > I've been also reading some posts about the new datagrid html >>> > extension and thought it might be clever to have a look at the spec >>> > when moving the tables from incubator to trunk to see how far the >>> > concepts match. Would be very cool to have a native table >>> > implementation on WebKit browsers while other fallback to gwt impls. >>> > >>> > What do you think? >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
