0
votes

I couldn't find a solution here after searching so I have to ask! Please excuse my language, because I'm pretty new in the NPAPI business.

What I have, is an existing plugin which receives data in a cycle of about 100ms out of a local running xulrunner application comming out of a nsComponent (the dataCreator). The result looks pretty well and the xul app is stable so far. But if I increase the occurance of data (which I have to), the xul app needs too long for reaction and this ends up in xul crashes. I think a XUL->Plugin I/O is a bit expensive!?

What I have learned until now, is that the plugin is able to create a new instance of a component:

    // inside myPlugin.cpp
    nsresult rv;
    nsCOMptr< myCompClass > _myComPtr ;
    _myComPtr = do_CreateInstance( "@myDomain.org/DIR/MYCOMPONENT;1", &rv ) ;

The function

    do_CreateInstance( ) ;

comes from nsComponentManagerUtlis.h which is out of the xulrunner SDK, but it has nothing like

    do_giveMeTheRunningInstanceOf( "@myDomain.org/DIR/MYDATACREATOR;1", &rv ) ;

My intuition now is to use the

    nsScriptablePeer::Invoke(NPIdentifier name, const NPVariant *args, uint32_t argCount, NPVariant *result )  

method to pass a nsCOMptr of the running dataCreator into the plugin, make direct communication possible and reduce the xul<-->plugin I/O to a minimum. Creating another instance of the dataCreator is definitely not an option!

To be honest: I've no idea how to "convert" the NPVariant (args[0]) into the needed nsCOMptr, did you? Or is there another possibility to receive the pointer inside the plugin?

Thanks for your help

1

1 Answers

1
votes

There is no way that I am aware of to interact with the xulrunner sdk directly from a npapi plugin, as they use totally different APIs. NPVariants cannot pass a xulrunner object or other native pointer type.

This is a total brainstorm and I have no idea if it would work, but if you could somehow combine a xulrunner extension and a npapi plugin into the same module, you could probably use a global map and an id from the plugin to get shared memory, but I have no idea if that's possible or not.

You are correct that interfacing with javascript has a cost; really, though, it's the individual calls that have the most cost because they end up being cross-process. Often you can minimize this by using more efficient calls. Faster than 100ms should definitely not be an issue.