[vlc-devel] Support of events in Mozilla plugin - Beta
y.brehon at qiplay.com
y.brehon at qiplay.com
Tue Sep 1 19:28:49 CEST 2009
>> It is still in early stages:
>> - it only works when compiled with a recent npfunctions.h, npapi.h,
>> npruntime.h, nptypes.h, npupp.h (on our Ubuntu system, we used the
>> latest API Mozilla furnishes with Firefox, which is located in a
>> Seamonkey folder)
>> - it only works on a browser supporting this recent plugin API
>
> You'll want to tone that down a bit then, if at all possible.
Actually, we were not able to avoid this. We wanted to, but the problem is
when you have a mozilla plugin, only its main thread can call a javascript
function. However, with the VLC plugin, the main thread is (most of the
time) not the one firing VLC events, it is the sub thread created to
actually process video. We were able to avoid this obstacle with the new
api, in which a sub thread of the plugin can ask the browser to call a
specific method of the main thread of the plugin... which subsequently
calls the javascript callback. A bit of a detour, but only way we figured
out.
> Why the distinction? Why not then, say, a bitmap so people can pick
> and choose what events to receive?
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)?
> 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)
As for the other comments, we will try and send an updated version of the
patch taking them into account this week.
Are you considering this to be merged to trunk?
Thanks for the comments!
More information about the vlc-devel
mailing list