[vlc-devel] Support of events in Mozilla plugin - Beta

[Yannick Bréhon]

>> Masks are not very "javascript-esque", but we could indeed set this up. We
>> had thought of the "profile" system to give shortcuts leading to what users
>> are most likely to want to monitor. Maybe we should offer all options
>> ("profiles" and bitmaps)?
> 
> Probably better to either fire events for everything or take a list
> of desired events from javascript to look at. No point in arbitrary
> restrictions. How that's implemented at the point of firing the event
> back to the requester (say, a bitmap) is, well, an implementation
> detail.

The question is: how would you imagine settig this mask on the
javascript side? using an int representing a mask is not very practical
for the web developers, as they will have to parse the event list and
figure out how to build the mask based on that. Using a structure would
make the plugin-side code enormous: we will have to decode the
javascript struct, figure out the mask (not mentioning evaluating key
value pairs...).

> 
> Note that I just committed a way to have the cpp generate a list of all
> available events. I'm not sure all possible events should be passed back
> to javascript but right now I don't really see why not either. At the
> very least it can provide the master list of events to choose from. Note
> that such a master list could safely be a static const char *[] class
> member.

This will indeed be useful once we decide on a way to encode the mask,
thanks!

>>> What is the performance penalty of (unnecessairy) calls-to-javascript?
>> This penalty has not been measured, but is probably not negligible, given
>> that every event triggers the above-described back and forth exchanges
>> (thread->firefox->plugin->javascript)
> 
> Worth a look then as it'd save code. If you come up with numbers please
> share.

OK, we just ran a few tests. Nothing complete or extremely serious, but
still. Machine was a dual proc @ 1.66GHz, 2GB RAM. When catching all
events (according to our "all" profile), proc was used at around 60%
(for the browser). We didn't do much processing, just a simple test on
the event name after catching an event. When catching only a single
event (begin of video play), or no events, we were running at 55%. That
is quite a difference, and would indeed justify the extra code...

Yannick