Let’s see if I can do a better job at explaining myself. > Seems like that would just stomp on the current basic set.
Yes. And I think that’s appropriate for now. When I say default, I mean that we should have one set of components that we’re all working on for now. We all have limited time, and splitting our time over two component sets is going to add significant overhead. Migrating the port to a new component set seem like a big job and will take time I do not have. Also, telling new users which component set to use is going to add extra friction to adapting the framework. 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. To convince me that the performance issue is a problem, we’re going to need a real-life example where getters and setters make a MEASURABLE difference in performance. Every benchmark I’ve seen indicates that to have any measurable impact by using getters and setters you need MANY millions of accesses. At even ten million accesses we’re talking at most 1/5 of a second. (probably less depending on the type of getter access) I find it hard to believe that we’re going to come up with a real life case where that will make a difference and there’s not a pile of other code causing much bigger performance issues. In fact, even the non-refactored code is already overriding the setters for most properties, so the issue is really only with the getters. If we come up with that use case (i.e. ridiculously large data grids or particle animations), I think there will be other refactoring we’re going to need to do to improve performance anyway. (i.e. image caches for item renderers and GPU optimizations) 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. Another point: I believe FlexJS will primarily be adopted by two groups of developers: 1. Developers migrating from Flash and classic Flex. 2. JS developers who could not care less about Flash support. For the first group wrapping Sprite is really important as I’ve already explained. For the second group Flash performance is a non-issue. I’m not sure which developer we’re worrying about vis a vis getter performance. 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. 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). Thanks, Harbs On Oct 21, 2016, at 8:06 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 10/20/16, 9:49 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> I feel like we’re not communicating. No. I want to merge as-is. > > I don't understand how that would create a second component set. Seems > like that would just stomp on the current basic set. > >> >> I think that wrapping should be the default for all components. I feel >> that having Flash properties leaking though is worse than a bit of >> redirection for 99% of use cases. I can’t stress how much of an issue >> that the Flash properties and methods leaking through was for us. >> Spark-like components was not the issue. Platform-specific implementation >> details leaking through is the issue and it’s more of an issue than >> possible performance problems IMO. >> >> We have not demonstrated that the performance impact will even be an >> issue. If that’s demonstrated, we can make leaky high-preformance >> alternates for those cases. > > I'll work on getting profiler information, but I have a feeling it won't > convince you. I have proposed tool chain solutions to I think every > problem you have described. If not, it is probably time to write down > explicit examples so everybody can understand the issue. I must clearly > be missing something. We have examples that work without wrapping on the > SWF-side. The API conflicts you hit were from migrating existing Flex > code and I don't think folks starting new projects will run into the same > problems and if they want to deploy a SWF version, may be more interested > in seeing that the output has as little overhead as possible. > > The URI for the basic set is currently > "library://ns.apache.org/flexjs/basic". I don't quite get how a wrapping > pattern on the SWF-side counts as "basic". I would offer that the > component set with wrapping have the URI > "library://ns.apache.org/flexjs/migration". Feel free to propose an > alternate set of URIs if you are convinced your wrapping set is "basic". > I don't care that much about the names as long as the meaning is clear. > If you want the HTML.swc to contain the wrapped set, propose SWC names for > the unwrapped set. Could be Basic.swc or BasicHTML.swc. > > I have no idea what the "default" set of components will be for FlexJS. I > doubt it will be what is currently "basic". It will likely be something > with more beads packed in with their APIs aggregated to the components API > surface. Folks will choose the ones they want. But at least if you want > to go low-level, you can. > > Thanks, > -Alex >
