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

Kaloyan Kovachev kkovachev at varna.net
Wed Sep 2 12:03:25 CEST 2009

On Wed, 02 Sep 2009 11:27:13 +0200, Yannick Brйhon wrote
> >> 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...).

What about javascript to register WantEvent(<name>|all),
DiscardEvent(<name>|all) with discard all as default and the bitmask being
internal for the plugin/thread

> > 
> > 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list