On Tue, May 19, 2015 at 11:00 AM, Alex Harui <aha...@adobe.com> wrote:
> Some (many) thoughts on this: > > I considered event pooling in the current Flex SDK and have suggested > pooling other objects in people’s apps at times in the past. Some folks > claimed that instantiating lots of small objects fragmented memory and > made the Flash Garbage Collector work harder. Flex does pool item > renderers, but, IMO, more for instantiation time than GC impact. For > sure, if I was running a 3D graphic simulation I would not want hiccups on > occasion to collect garbage. > Sounds reasonable, I don't have enough experience in this part, I was just bringing up "issues". > > But at least for now, the FlexJS focus is on 2D applications, so I’d want > to see if event instantiation is having a negative impact before > implementing a pool. Also, since the root event dispatching for FlexJS is > implemented within the runtimes and I believe event.target is read-only, > it is problematic to create a pool without causing other memory leaks. > Agreed. > > FWIW, the other way to optimize for event instantiation is to simply fire > less events. In current Flex, lots of events are fired “just-in-case". > With replaceable models and other parts in FlexJS, you should be able to > replace parts with parts that only fire the events you are actually going > to use if it turns out to be important. > > Another way to fire less events is to not use bubbling like I’ve seen some > folks do. Bubbling is an easy way to hoist an event up to a listener, but > breaks encapsulation and is the equivalent of shouting from the sidewalk > to someone on the top floor of an apartment building. Bubbling is really > intended for when the listener doesn’t know who is going to have something > to say, which is why Keyboard and Mouse events bubble, but for most custom > events, the better practice is to have each abstraction boundary dispatch > an event that doesn’t bubble and has a unique semantic meaning, and have > the one listener listen directly at the boundary. That’s like texting the > person on the top floor. Not everybody has to hear it. > Yes, In my custom Feathers components I don't use bubbling at all. I may use it when I initially prototype a component so the mediator catches it easily but, in production, there is a one to one relationship with a component and mediator. So the mediator IS listening to the component that is dispatching. > > Separately, it looks like you like an API where you pass in a few > parameters instead of an event instance. The JS side already does that > and we could do that on the AS side. > > It's a nice feature since I don't create any custom events, I always used the Event class and it's data field. > I couldn’t tell quickly whether Starling has only one Event class, but I’d > suggest we start with an Event with no data since that’s built in to the > runtimes, then a ValueChangeEvent that has oldValue/newValue and add an > EventWithData when we come up with a need for it. Also note that: > > MyClass(event.target).selectedIndex > > is type-checked by the compiler, where as > > event.data > > is probably not, so IMO, I’d recommend the former instead of passing the > payload in a data field in most cases. > > Starling has a couple but not many, like TouchEvent etc. So you are saying use a ValueChangeEvent for things that need a payload, don't tack data onto event correct? I am confused as to the " I’d recommend the former instead of passing the payload in a data field in most cases." Can you give a concrete example of what your context is? Just trying to fully understand what you are saying. > And then, unlike Starling and current Flex which has dozens of constants > declared on the Event class, I want to experiment with putting those > constants on the class that dispatches the event. Having every constant > on Event doesn’t scale well. When you get to 100’s of constants you could > be bringing in lots of strings that aren’t used and the documentation gets > unwieldy. Third-parties can’t be changing the Event class for their > components so instead of creating subclasses of Event, why not just > declare the constant on the same class that is dispatching it? > I already do this, I put events on ALL my components as constants. That way a mediator always knows what it can get from a component. I the dev..... neve have to use my crappy memory to remeber all these rediculous event class names, just use autocompletion; addEventListener(myView.EVENT_[name goes here], ) > > Regarding where and how the JavaScript line is, I’m not quite sure what > pieces of information you are looking for, but consider this: the goal of > FlexJS is to produce an optimal HTML/JS/CSS app, not an optimal SWF. You know, I think I am just getting this now. Honestly I thought this was the "NEXT" Flex framework for SWF. Now reading this I may have got the framework all wrong. > So I > will sacrifice a bit of being more like current Flex for using different > APIs to make the final cross-compiled output run better. Thus, at the > lowest level, I’m going to try to leverage HTMLElements, CSS, and > EventDispatchers built into the browsers rather than layering code on top > of it. IMO, you can always sacrifice performance and add layers on top of > your low-level, but the problem with current Flex is that there is no > low-level below the 13,000 lines of UIComponent and the nearly 200K of SWF > bytecode it is hard-coded to bring in. The composition-orientation of the > framework should allow you to build up things into higher levels where you > need them, but allow for optimization, replacement, testing, mocking, etc > of individual pieces. > Yeah, I get this. I am just trying to understand the lowlevel completely. I am only efficient and helpful in things I fully understand. I need to understand this stuff from start to finish, one I want to make components and use other frameworks to add extensions, two if I am going to help with the compiler, I need to know how it all ticks and not just fragments. > > Finally, here’s the layout wiki page: > https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout > > HTH, > -Alex > Thanks for taking the time Alex, appreciated. Mike > > On 5/19/15, 5:41 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >So are you saying Starling traded a bit of performance in event > >dispatching > >to get object pools? Or was is that they needed to implement bubbling of > >their own display list, so they sacrificed performance. > > > >Mike > > > >On Tue, May 19, 2015 at 8:32 AM, Kessler CTR Mark J < > >mark.kessler....@usmc.mil> wrote: > > > >> Just a side bar on this. I believe a concern about using the > >> eventdispatcher like the one in starling was that it was slower than > >>one we > >> use from flash.events. It had to do with the fact the player was > >>managing > >> the events vs using an actionscript driven one. Bumped into that when I > >> explored managing the lists of the active events and I even made single > >> serving events that would remove themselves after one call. > >> > >> > >> -Mark > >> > >> > >> -----Original Message----- > >> From: Michael Schmalle [mailto:teotigraphix...@gmail.com] > >> Sent: Tuesday, May 19, 2015 6:30 AM > >> To: dev@flex.apache.org > >> Subject: Re: [FlexJS] Event names > >> > >> NOTE: I forgot to say that in the EventManager in the component > >>framework > >> can do it; > >> > >> > >> > >> > https://github.com/Gamua/Starling-Framework/blob/master/starling/src/star > >>ling/events/EventDispatcher.as > >> > >> See the method invokeEvent(), line 140. In a way, this makes the need > >>for a > >> subclassed Event obsolete, the data IS the payload which can be a > >>primitive > >> value or vo/struct class. > >> > >> The client knows what it needs. > >> > >> Mike > >> > >
