On Apr 12, 2006, at 9:16 AM, P T Withington wrote:
> That is what henry proposed. I mis-used the word 'created', just
> meaning that events would always be valid. We didn't think about
> making the null event really be null in swf -- maybe that is a good
> idea, or not, depending if newer swf runtimes will be stricter.
>
I think our assumptions about performance and behavior should not be
carried forward from Flash <= 8 to Flash 8.5. So having sendEvent be
null would most likely only be a solution for Flash <= 8. (But we
should benchmark and test, of course.)
Since it's cheap to do, I'm trying as an experiment to check for null
every time we call sendEvent in LzView and LzNode. The biggie I've
seen so far is this one:
LzNode.prototype.__LZapplyArgs = function ( args , constcall ){
...
this[ a ] = args[ a ];
if ( !constcall ){
//then we need to notify the rest of the system
that this
//value changed.
this[ "on" + a ].sendEvent( args[ a ] );
}
}
If you don't know, __LZapplyArgs figures prominently in profile
traces of node/view initialization, so this is a nice find; I'll
measure whether it speeds anything up.
jim
> It is probably still valid to avoid calling send event when there are
> no listeners -- a future optimization.
>
> On 2006-04-12, at 12:03 EDT, Adam Wolff wrote:
>
>> I thought the plan was that we attach a singleton "NullEvent" to
>> declared
>> event slots. When a delegate registers for the event, it replaces
>> the null
>> event with a real event.
>>
>> In SWF (where call overhead is high, and it's not an error to call a
>> missing function) we could define the NullEvent sendEvent method as
>> null
>> (when you're not in Debug.) In other runtimes, we can define it as
>> a no
>> op.
>>
>> This scheme *would* make it unnecessary (useless) to test for a non-
>> null
>> slot before calling sendEvent.
>>
>> We can't afford to instantiate every event that is declared. Much too
>> slow.
>>
>> A
>>
>> On Apr 12, P T Withington wrote:
>>
>>> Right, but what Henry was proposing was for their to always be an
>>> event object created. Then you would never have to check for the
>>> event object existing (so the idiom you use would go away).
>>>
>>> BUT, Jim discovered that, at least on the swf runtime, because
>>> function calls are relatively expensive, that testing for the
>>> delegateList being empty or not before calling sendEvent saved
>>> considerable time, at least with very frequent events (in particular
>>> onwidth and onheight).
>>>
>>> The best of all worlds would be for sendEvent to be inlined, at
>>> least
>>> to the point of checking the delegateList, and only call the out-of-
>>> line helper function when there are delegates listening. For now,
>>> that would have to be done by special code in the compiler...
>>>
>>> On 2006-04-12, at 00:29 EDT, Sarah Allen wrote:
>>>
>>>> In the component code and application code that I've been creating,
>>>> it is common to write:
>>>> if (foo.someevent) foo.someevent.sendEvent()
>>>>
>>>> This avoids debugger warnings if no one is registered for
>>>> someevent.
>>>>
>>>> Sarah
>>>>
>>>>
>>>> On Thu, Apr 6, 2006 at 9:01 PM, P T Withington wrote:
>>>>
>>>>> Belay that. Not sure what I was thinking here.
>>>>>
>>>>> It would be an optimization to not call sendEvent if the event's
>>>>> delegateList was empty. At least in the swf runtime, where
>>>>> function calls are costly.
>>>>>
>>>>> But I'm not sure this is the whole answer. It looks like you are
>>>>> trying to create some sort of 'null' event for each declaration.
>>>>> If you do this, you also need to check for this null event when
>>>>> you do add a delegate (and convert it into a real event).
>>>>>
>>>>> On 2006-04-06, at 20:38 PDT, Henry Minsky wrote:
>>>>>
>>>>>> So that needs to be a convention that everyone obeys when they
>>>>>> write calls
>>>>>> to sendEvent? Not just in the LFC, I'm just thinking about user
>>>>>> code, if app
>>>>>> developers are going to be told to do
>>>>>>
>>>>>> if (foo.someevent) foo.someevent.sendEvent()
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> foo.someevent.sendEvent()
>>>>>>
>>>>>>
>>>>>> Or is there some kind of magic we could use to do this
>>>>>> automatically ? I
>>>>>> guess it would need to be some kind of macro processor :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/6/06, P T Withington <[EMAIL PROTECTED]> wrote:
>>>>>>>
>>>>>>> If you do, annotate LPP-1915 to say this can be removed when all
>>>>>>> callers of sendEvent check for no listeners first (which
>>>>>>> should be
>>>>>>> much more efficient than making a call to the empty function).
>>>>>>>
>>>>>>> On 2006-04-06, at 19:56 PDT, Henry Minsky wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> This code for declaring events is currently in the DHTML
>>>>>>>> runtime
>>>>>>>> but not in the SWF runtime.
>>>>>>>>
>>>>>>>> Should this go into the SWF runtime as is, or is there
>>>>>>>> anything we
>>>>>>>> need to do differently?
>>>>>>>>
>>>>>>>> [background for the viewing audience; we need to avoid
>>>>>>>> referencing
>>>>>>>> properties of null values
>>>>>>>> in the DHTML runtime, as it brings the browser javascript
>>>>>>>> interpreter to a screeching halt]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> LzDeclaredEvent = {};
>>>>>>>> LzDeclaredEvent.sendEvent = function ( a ){ return a };
>>>>>>>> LzDeclaredEvent.toString = function ( ){
>>>>>>>> return "Declared event";
>>>>>>>> }
>>>>>>>>
>>>>>>>> function DeclareEvent( who , what ){
>>>>>>>> // debug('declare ' + who + ' what ' + what);
>>>>>>>> who[ what ] = LzDeclaredEvent;
>>>>>>>> }
>>>>>>>> function DeclareEvents( who , what ){
>>>>>>>> // debug('DeclareEvents', who, what);
>>>>>>>> for (var i in what) {
>>>>>>>> //info('what', what[i]);
>>>>>>>> who[what[i]] = LzDeclaredEvent;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Henry Minsky
>>>>>>>> Software Architect
>>>>>>>> [EMAIL PROTECTED]
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Laszlo-dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Henry Minsky
>>>>>> Software Architect
>>>>>> [EMAIL PROTECTED]
>>>>>
>>>>> _______________________________________________
>>>>> Laszlo-dev mailing list
>>>>> [email protected]
>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>
>>>
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> [email protected]
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
