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.
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.
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.
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.
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.
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?
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. 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.
Finally, here’s the layout wiki page:
https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Layout
HTH,
-Alex
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
>>
