[vlc-devel] Support of events in Mozilla plugin - Beta
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
> >> 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
> > 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
> 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
> value pairs...).
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
> > 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,
> >> This penalty has not been measured, but is probably not negligible, given
> >> that every event triggers the above-described back and forth exchanges
> > 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...
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel