Shumway is really good. Use it in droid Firefox
On Mar 15, 2013 12:13 PM, "jude" <flexcapaci...@gmail.com> wrote:

> This looks interesting. It's not clear if other browsers can use this
> project or will use it. He also states it's only supporting features up to
> version 10 at this time.
>
> Shumway is an experimental web-native runtime implementation of the SWF
> file format. It is developed as a free and open source project sponsored by
> Mozilla Research. The project has two main goals:
>
>    1. Advance the open web platform to securely process rich media formats
>    that were previously only available in closed and proprietary
>    implementations.
>    2. Offer a runtime processor for SWF and other rich media formats on
>    platforms for which runtime implementations are not available.
>
>
> https://blog.mozilla.org/research/2012/11/12/introducing-the-shumway-open-swf-runtime-project/
>
>
> On Thu, Mar 14, 2013 at 2:40 PM, Alex Harui <aha...@adobe.com> wrote:
>
> >
> >
> >
> > On 3/14/13 10:45 AM, "jude" <flexcapaci...@gmail.com> wrote:
> >
> > > One of the reasons we like Flash and Flex is because it gives the
> > > consistent visual results across platforms. I'm a little concerned that
> > we
> > > are adopting JS and HTML approaches and will then inherit it's
> problems.
> > IE
> > > leaving the view to HTML.
> > I am concerned about that as well.  I think there will be a curve where
> you
> > can get "pretty close" really quickly, but as you try to make it more and
> > more consistent it will cost you.  I think most folks will make a
> trade-off
> > at some point.
> >
> > The only way to guarantee consistency is to spend a lot of time on a
> > standalone rendering engine, and that just isn't practical in my view.
> >
> > If you play with the prototype, it leverages absolute position and so
> far,
> > it seems to work reasonably consistently.  What isn't consistent is the
> > default chrome around widgets.  I'm not an expert on HTML/JS, but I
> believe
> > the biggest inconsistencies are around text flow and this framework is so
> > far not using that.  It may turn out that we can get your widgets to
> layout
> > the same, but the cost of getting text to flow the same is high and won't
> > be
> > in early versions).  Hopefully that would still be a viable strategy for
> > many.
> >
> > >
> > > One of the potentials I see in the Flex to HTML / JS projects is that
> we
> > > will eventually be able to create the same app from the same code base
> > and
> > > get the same look and feel as we do in Flash Player / AIR. If we have
> to
> > > start worrying about visual inconsistencies between browsers or export
> > HTML
> > > and CSS with patches for different browsers then what is the advantage?
> > IMO, it is the job of the SDK developers to hide those inconsistencies
> from
> > the site/app developers using the SDK.  And that would be the advantage
> to
> > the users.
> >
> > >
> > > I know there is an advantage. It's that we can use AS instead of JS so
> > you
> > > get all the advantages of AS, like a strongly typed languages, packages
> > > etc. I think that's the Randori approach. That's a huge. But it doesn't
> > > address the view. At the end of the day we would still need to write
> the
> > > view in HTML or in your version of Flex use raster images instead
> vector
> > > graphics? Correct me if I'm wrong. I'm still in a wait and see.
> > Try the prototype.  You write your view in MXML.  I think I'm going to go
> > with bitmaps first, but if there is a way to use SVG hopefully someone
> will
> > make it work.  This is Apache, not Adobe.  Peter, Erik and I are not just
> > developing a product for you to consume.  We need as many people as
> > possible
> > to contribute, not just wait for 3 folks to try to do what a full team at
> > Adobe did.
> >
> > >
> > > I'm interested in seeing if we can get the same vector output in HTML
> as
> > we
> > > do in Flash. I think Frank mentioned he has a Flash JS runtime
> container
> > > that runs on the HTML Canvas (charts demo?). I would rather we target
> > that
> > > (HTML canvas, drawing API), even if it's poorer performance at the
> > present
> > > time. We can always do runtime performance measurement and turn off
> some
> > or
> > > all of our animations on slower browsers. But from a quick look online
> > I'm
> > > reading many / all the major browsers are hitting 40 to 60 FPS for HTML
> > > Canvas on similar drawing calls to what we have in Flash.
> > >
> > > I can look into HTML5 performance and how it performs across browsers
> > > (mobile may be much faster than desktop?). I'm sure Frank has the
> numbers
> > > and more information on this so I'll wait here before looking further
> > into
> > > it reply.
> > >
> > > I bring this up because I've been writing mobile and desktop app and in
> > my
> > > view for my apps, vector support is becoming much more important than I
> > > thought as I target more platforms (and now retina displays). I'd argue
> > > more for consistent look is more important than performance. That's
> like
> > a
> > > holy grail and major pain point in HTML development (or was for me). I
> > > don't know. Thoughts? My 2 cents.
> > Om says that SVG skinning is possible in HTML5.  If that's true,
> hopefully
> > one of you or both of you or some others will help make that happen.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>

Reply via email to