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
