flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jude <flexcapaci...@gmail.com>
Subject Re: Flex 5 in haxe
Date Sat, 17 Nov 2012 02:23:29 GMT
On Fri, Nov 16, 2012 at 4:13 PM, Alex Harui <aharui@adobe.com> wrote:

> Keep in mind that I'm the biggest proponent of the full re-write.  We may
> still find a few performance mistakes in the current code (like the Chart
> styles init that just got fixed), but really, some very smart people have
> spent a lot of time on the current code and haven't found any easy wins.

That is my point in staying with what we have. The Flex SDK has had some
constraints on it that made it what it is today. I'm not against starting a
new or full rewrite but I would say let's get this project going on the
current code base first. Let's make it easy for long term contributors to
contribute and soon after support drive by contributors. When the dust has
settled then we create a branch or two to test performance improvements

> IMO, the framework is slow because lots of code is running just in case.

I wouldn't say it's slow. Maybe on phones in 2010 and on Flex 4 but not in
2013 on Flex 4.6+. There was a lot of optimization done in 4.6 and all the
great things in it were overshadowed by November. I'd say it's not finished
and that developers are still learning it. It's 2 years old. People are
just now migrating to Flex 4.5.  There are videos online on increasing Flex
4 performance for mobile and they went from default 12 and 15 FPS to 45 FPS
by making a few changes. Those same tests are steady at 60 FPS+ on Spark
Lists in newer versions of AIR.

I'd agree the framework is covering it's bases all the time. Which it
should do. But it should also allow developers developers to disable
certain layout code in certain situations and especially when the developer
knows what they're doing.

The thing with Flex is it's flexible enough that you can give it too much
to do. What we don't know right now (maybe you do) is where the bottlenecks
are in general (code or rendering) and more importantly where the
bottlenecks are in our applications and then how and where to optimize. I
wish there was a performance monitoring tool that would show us that
information but none exist.

You also have to remember that technology marches on. So think about 2
years from when phones are 4x as fast. Also, even the latest phones still
stutter and are slow at times in their own native environments (go to the
search screen in any Android or iOS device).

This is especially true for mobile apps where you have the most constrained
> runtime environment.  The issue that came in today on the users list about
> slow List performance I'm sure is in part due to TextLine being a bit
> slower, but probably more due to lots of other code running as well.

AIR 3.4 and 3.5 had major mobile performance improvements.

> Plus, as many have recently said, the intertwined code we currently have
> makes it hard for the volunteer to be successful in their spare time.

There are long time volunteers here too.

There are no alternatives for Flash at this time. HTML5 doesn't even come
close. It's missing so many features across the board (or I should say the
browsers are).

@Gordon - I'd say there's a lot of momentum and interest in mobile software
(software includes apps and that includes apps that are entertaining and
sometimes they have scores and support two or more users at once). Software
is huge... anything that makes Software is of interest. Enter Flex (or
mention it). Or describe it. Flex has had major development investment in
it all the way up to Nov last year. Few other companies put in the
resources this company did. The goal was to make the best platform for
deploying to multiple targets going into 2012. Flex 4.6 is relatively new
and fast and unknown. It's still the best choice for many developers and
companies for creating mobile, desktop and web applications. IF THEY KNOW
OF IT. It can be very successful in that market. It'd be 1000x better for
developers if Adobe would say Flex can run fine on Flash going into the
next ten years instead of saying Flash is for gaming. If someone wants to
do gaming, we the developers, will be the first to tell them Flash is ready
for them.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message