On 10/23/16, 5:17 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >On Oct 21, 2016, at 10:12 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> Carlos is working on an MDL set. We want to make sure FlexJS can handle >> more than one set. We don't have to all work on one set. > >There’s a difference between specific components based off the basic >architecture, and an entire alternate set for everything based off of >UIHTMLElementWrapper. If you want to use MDL components, it makes sense >to use an mdl prefix. FWIW, I would have thought that MDL would have been >a set of beads, but I guess a set of components is probably easier to use. Internally, some of the createElement calls for MDL will have to build a different DOM tree than what the basic set does. > >>> >>> AFAIK, the only performance overhead in wrapping Flash components is an >>> extra getter/setter call. I don’t see how there would be any extra >>>memory >>> overhead. >> >> Instead of creating a new Sprite, you are creating a new Sprite and >> another object to wrap it. This is worrisome in the sense that, for >>every >> person who is struggling to get a certain update rate in their app, >> wrapping essentially means there are twice as many objects to be updated >> in the same amount of time, although the update time of the wrapper may >> not be the same as the update time of the inner widget. Twice as many >> objects is twice as much work for the Garbage Collector. It is more >>lines >> to step through when debugging. If we told potential FlexJS customers >>to >> wrap all of their code in another layer in order to use FlexJS I think >>we >> would have fewer customers. > >I have no idea what you mean by twice the updates. Why does extra objects >effect that? > >It’s twice the number of objects, but the size of both objects together >is not bigger than one. What is the logic behind that statement? The wrapping object is an EventDispatcher. Each EventDispatcher eats up some 40 bytes. >We’re all used to having extra getter calls when debugging, so I’m not >concerned about that issue. I don’t know how the garbage collector works. >Is the work based on the number of objects, or the size of the objects? Number of objects. >It does not solve the problem that lots of things are happening under the >hood related to the fact that the objects are masquerading as something >other that what they are. I don't see it as masquerading. The platform implementations just share a common API. > >If there will be performance issues for mobile or otherwise, I don’t >believe it’s going to be the wrapping that causes the problem. > >> Now from my experience with Flex, I saw some things happen. Flex's job >> was to put a layer over Flash and essentially hide all the Flash-isms, >> especially frames, and make an API that was more "programmer-oriented". >> You were supposed to use SystemManager instead of Stage, for example. >>But >> when I peek at other people's apps, I see a lot of use of Flash APIs >> anyway. Why? Because they needed to get down to the lower-level for >> optimization. And then, folks started creating other lightweight >> frameworks as alternatives to Flex. I also saw the argument that my >> change only causes 10ms delay. I after seeing it 100 times, we had a >>full >> second delay and nobody could point to what to remove to try to get it >> back to something ignorable. > >We’re not talking about a 10ms delay. We’re talking about a 0.02 ms >delay. That’s not going o be the performance bottleneck. Where did you get the 0.02ms number? > >> Also note: the reason MouseEvent doesn't extend Event doesn't have >> anything to do with wrapping Sprite or not. And any inconsistencies >> between the JS and SWF event model simply need to be resolved. I think >> resolving it so the unwrapped set matches the JS side will lots easier >> than writing a whole new event model for wrapped Sprites. > >Yes it does. Flash objects dispatch Flash events and we’re wrapping Flash >Events and MouseEvents. The current SWF-side event model subclasses flash.events.Event. I don't think there is any wrapping going on. >The fact that we’re handling Flash MouseEvents creates an entire class of >issues which would not exist if we did not use the Flash UI event system >for mouse events. Unless we do some hack to clobber every Flash event >before it propagates, we’re going to be chasing down lots of edge case >issues related to casting bugs and odd side effects of event bubbling. >(as we already saw) Wrapping the Flash objects solves this problem in the >cleanest possible way because unless you do so specifically, event >listeners are not attached to the underlying Flash objects. I will need to understand you are referring to. Since there is no wrapping going on, I'm not sure what you are describing. > > >It might be that the only way to resolve this is to create that tool >chain and have me try to break it. ;-) Yep, I think that's the best plan. > >If that means I can continue working with the wrapped components for the >time being and changes are applied to that, I’m fine with this. If you >can get your tool chain working, I’ll be happy to spend the time trying >to port my code to use that and see what breaks. Then we can have a >better idea how well it really works… I will move the unwrapped set to a different SWC (or set of SWCs) some time this week. Then we can try to merge your branch. I would like to change the URI for the wrapped set to something else: migration, full, flex, other ideas? I am going to close this post with a long story. I am a believer that history repeats itself. The arguments you are presenting here are the same ones I heard many times over the years. Over 10 years of Flex at Adobe, 1000's of changes were made. Nearly every one of those added just a little bit of code and thus slowed the framework just a little bit. Early on, I prototyped a smaller framework like what you see in the basic set. But the emphasis was on how quickly you could put together a POC. Flex grew in popularity, but we started receiving more and more problems with folks trying to meet some performance criteria at the end of their schedule. At one point, I visited a major consumer software company where they complained that they could not get the first-time startup time to an acceptable point. We had no answer for them, because we had baked in 1000's of small changes and couldn't back any of them out without breaking backward-compatibility. There were no low-hanging fruit that would make a measurable difference. As a result, I don't think Flex was ever used to create an app that "everybody" uses. Lots of ActionScript apps are in the app stores, but I'm not sure how much Flex is used in them. So from that experience, I became a code-minimalist. For 4.5 years I've been preaching that FlexJS is about pay-as-you-go, just-in-time instead of just-in-case. Fortunately, because FlexJS can support multiple component sets, folks can create component sets with different philosophies, but I am certain I want to have one that is truly bare bones. When you need a bit more performance, you might trade-off some usability to get there. Folks at least should have a choice. I don't expect the basic set to be the most popular set. It just has to be there when you need it. Otherwise, you will go away and not come back. Also, I am a resource-minimalist. While it is amazing to see how fast networks and CPUs are these days, the fact is, everybody is competing for those resources. The app developer using the framework is often going to totally push the boundaries of how much other stuff can be done in some amount of time. The framework should not waste cycles that app developer might need. It is tempting to think there is plenty of resources, but I would like Flex to be the choice for folks who run apps in constrained environments, whether that is Cordova on a mobile phone, or a conventional computer running a virus scan or backup, or trying to get data over a network while some other task is playing a video. So that's why I fight for every function call. I watched Flex grow too fat once already. The plan for FlexJS has always included a "heavier" set with lots of stuff baked in to make rapid prototyping rapid, but the basic set really needs to be basic. The more places FlexJS can work, the better off we all will be. Thanks for reading, -Alex
