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. >> >> 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. 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? >> >> Now, back to the problem of not wrapping Sprite: >> >> Yes. The case I mentioned is a much bigger problem in migrated code than >> new code (and in new code there’s still the issue of undocumented >> reserved properties when targeting Flash), but it’s not the only issue. >> It’s been a while, and I don’t remember all the nuances of the issues we >> encountered. Maybe Yishay remembers more. >> >> We encountered numerous issues related to events. Some of the problems >> were related to the fact that event bubbling is different in Flash than >> it is in JS. Some of the problems were due to the fact that the events >> were dispatched by the Flash objects — those issues were at least >> partially due to the fact that Flex MouseEvent does not subclass the Flex >> Event. I don’t see any way of fixing that other than wrapping Sprite. I >> think we need to make events identical across platforms. >> >> There are possibly issues I’m not remembering now, and there’s possibly >> other issues we did not run into. >> >> Again: My objection is that I believe the idea of having >> platform-specific implementation details leaking through is fundamentally >> wrong and should be avoided if at all possible. > > I guess I don't understand why it is wrong. IMO, you were the first > pioneer and I'm really thankful that you took the risk to do so. In US > history, the pioneers had a covered wagon pulled by an ox. There were no > paved roads. Some days, they were only able to go one mile!. You found > that by taking an extra mattress and sitting on it, it made the ride more > bearable. However, the tool chain is slowly coming behind you paving > those roads. I think I will be able to fill in every bump in the road you > went over. If there is something I can't fill in, I would like to > identify what that is, because that would definitely make me change my > opinion. IMO, folks just aren't going to need an extra mattress. You can > argue that the ox is so strong that it doesn't matter, but if you do try > to drive off-road and get stuck in the mud or there are other things you > would much rather pack into your wagon, you will want to leave that > mattress behind. Just this week there is a thread about mobile > performance. Again. We already agreed that there’s no way to cover the bumps for migrated code. Also, if someone tries to add scaleX/scaleY or a transform method, they will get an error despite the fact that these methods and properties are not documented. All the tool chain can do is warn about the issue. 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. 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. Also, lots of times it was because using the Flash APIs was simpler. I for one did not know you were “supposed” to use SystemManager instead of Stage. When I needed to do something, I looked through the docs to find something helpful and used the first thing I found. Since Stage was the top level parent, using those properties make sense. Leaving a back-door open for optimization is fine, but I think the front door should have a clean entrance. > 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 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. >> >> We have a conflict between ideals here. You want a the highest possible >> performance under all circumstances, and I want the highest level of >> compatibility across platforms under all circumstances. > > I think the tool chain can get you that compatibility so there is no > conflict. I'm still wondering what the killer scenario is that the tool > chain cannot solve. I am open to the idea that there is one. Again, I think it’s not just a toolchain problem. It’s an inconsistency between documentation and code and a framework which is inherently more fragile. (Event issues that we had is one example of the fragility.) It might be that the only way to resolve this is to create that tool chain and have me try to break it. ;-) >> These two ideals are at head with each other here, and we’re going to >> have to decide which one is more important. I think I’ve made opinion >> clear on that question. The performance issue is a theoretical one which >> I don’t believe will have practical implications, while the compatibility >> one is a practical one which already bit me. Trying to maintain two >> complete component sets at this point I believe to be counterproductive >> and I don’t believe it will resolve performance issues that might arise >> anyway. If we identify use cases where performance is an issue, I would >> suggest specific components designed for those use cases (and not a whole >> new set). > > I would like to work on one Basic set too, but your set doesn't sound like > it is Basic. It sounds like it is aggregating APIs into the component > surface to simplify migration. And that's fine with me. I would love to > have a component set tuned towards migration. I just would caution about > using your experience with a new tool chain to make decisions that we will > carry around for a long time. > > Maybe the answer is that I copy the current unwrapped Basic set to new > SWCs, then you can drop the wrapped set on top. Then I will work on the > tool chain to see if we can resolve all of your issues without wrapping. 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…
