On Fri, Nov 16, 2012 at 4:13 PM, Alex Harui <aha...@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 out. > 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. Jude
