On 9/28/16, 12:21 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>The overhead to swfs seem to me like it’s really minimal. There’s not a >lot of added code for using composition rather than inheritance. Well, at Adobe, we said "the overhead is minimal" so many times in Flex that UIComponent grew to 13,000 lines of code. I could put the code through a profiler, but my understanding is that the refactor creates twice as many objects and probably at least twice as many function calls at runtime. Yes, we will accept bigger sizes and slower performance on the SWF side in order to make sure the JS side is as efficient as possible, but IMO, we aren't wrapping Sprite to help the JS side. > >Improving events is probably something which should be done for the JS >side as well, so I’m not convinced that’s a major problem either. Some of >the event issues we had had nothing to do with inheritance vs composition >of Sprite and friends. It had to do with the fact that MouseEvent and >Event are unrelated. Yup, and once we decide on the sprite refactor we can then decide on how to deal with events. > >Additionally, I really don’t believe most folks will use swf output for >much more than debugging purposes, so if there’s a little more overhead, >so what? Ideally, the SWF version would remain viable for deployment so folks who can use Flash can continue to save on cross-browser testing, but also, we need big apps to load the SWF version fast enough to make it efficient to use as a debugging version. Doubling objects and function calls isn't going to help. >We’ve also done a lot of work on the sprite-refactor branch which would >be hard to back-port. I would think if we abandon the sprite wrapping, we would revert UIBase and Application to extend Sprite in the refactor branch, then the branch merge to develop would pick up everything else. IMO, if it were easy to upgrade every Flex IDE, we would solve the issue of detecting which Flash APIs aren't available by modifying the IDEs. This means to me that it isn't required to solve this problem by making changes to the runtime output. Today, I played with a "new workflow" for migrating apps that might solve this problem for FB and maybe other IDEs. I created a test app called "NewFlexJSProject" and selected FlexJS as the SDK. It looked like this: <js:Application xmlns:fx="http://ns.adobe.com/mxml/2009"; xmlns:js="library://ns.apache.org/flexjs/basic" > <fx:Script> <![CDATA[ override public function get buttonMode():Boolean { return super.buttonMode; } ]]> </fx:Script> ... </js:Application> As you can see it overrides the buttonMode setter on Sprite, which isn't supported by FlexJS. AIUI, this is typical of the kinds of problems you ran into. The SWF version compiles just fine. Next, I created another Flex project and made the application look like this: <js:Application xmlns:fx="http://ns.adobe.com/mxml/2009"; xmlns:js="library://ns.apache.org/flexjs/basic" > <fx:Script> <![CDATA[ private var test:NewFlexJSProject = new NewFlexJSProject; ]]> </fx:Script> </js:Application> I set the source path to point to NewFlexJSProject/src, then I modified the library-path to remove the standard FlexJS SWCs and playerglobal, then add in the js.swc from js/libs and the SWC folder from frameworks/js/FlexJS/libs. That folder contains xxxJS.swc that present the JS-side APIs to downstream SWCs. When I did that, this project showed errors about buttonMode in NewFlexJSProject.mxml. IMO, a workflow like this might be sufficient for speeding up migration without requiring the extra overhead of wrapping Sprite. We could possibly teach our compilers to compile twice, once with each library path so you don't have to set up the second project. That's why I believe there are ways to solve the problem of catching use of Sprite APIs without wrapping Sprite and making all SWFs pay the price via the tool chain and not code running at runtime. Thoughts? -Alex
