Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D123BDEF9 for ; Fri, 16 Nov 2012 22:13:47 +0000 (UTC) Received: (qmail 83318 invoked by uid 500); 16 Nov 2012 22:13:47 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 83281 invoked by uid 500); 16 Nov 2012 22:13:47 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 83273 invoked by uid 99); 16 Nov 2012 22:13:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Nov 2012 22:13:46 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates 64.18.1.39 as permitted sender) Received: from [64.18.1.39] (HELO exprod6og117.obsmtp.com) (64.18.1.39) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Nov 2012 22:13:37 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUKa6e6K0anVzT3MdCwLmrJxjXrgIYEFP@postini.com; Fri, 16 Nov 2012 14:13:16 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAGMDEHP026104 for ; Fri, 16 Nov 2012 14:13:14 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qAGMDEXL000456 for ; Fri, 16 Nov 2012 14:13:14 -0800 (PST) Received: from NAMBX02.corp.adobe.com ([10.8.127.96]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 16 Nov 2012 14:13:13 -0800 From: Alex Harui To: "flex-dev@incubator.apache.org" Date: Fri, 16 Nov 2012 14:13:11 -0800 Subject: Re: Flex 5 in haxe Thread-Topic: Flex 5 in haxe Thread-Index: Ac3ERM8Gw9wGhYHKQN+WNxZH3stpZAAAsF+u Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.13.0.120411 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org On 11/16/12 1:52 PM, "Fr=E9deric Cox" wrote: > I'm glad Alex is here because I believe he does not only have > the experience but also great ideas where Flex should be headed. And he > might have been blocked previously by business decisions but now can take > Flex to a even higher level. >=20 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. IMO, the framework is slow because lots of code is running just in case. 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. 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. I tried the big refactor and it was too difficult for me, but one of the main difficulties was the fact that there was lots of other development going on in the trunk at the same time and keeping my branch running was nearly impossible. It could be that there won't be as much active development in Apache Flex and a refactor branch will be manageable, but th= e other problem you run into is that every line of code is needed for some reason at some point, and you tend to start leaving code in. Starting over definitely has its risks, but I think it will have the best outcome. It won't make 100% parity ever and I'd shoot for 80% over two or three years. But it will be designed to port to other platforms, and be modular so the volunteer has a chance of making a difference. --=20 Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui