Я не мог найти решение здесь после поиска, поэтому я должен спросить! Пожалуйста, извините за мой язык, потому что я довольно новичок в бизнесе NPAPI.
У меня есть существующий плагин, который получает данные в цикле около 100 мс из локально работающего приложения xulrunner, выходящего из nsComponent ( dataCreator). Результат выглядит неплохо, и приложение xul пока стабильно. Но если я увеличу вхождение данных (что мне и нужно), приложению xul понадобится слишком много времени для реакции, и это приведет к сбоям xul. Я думаю, что XUL-> Plugin I / O немного дороже !?
До сих пор я узнал, что плагин может создавать новый экземпляр компонента:
// inside myPlugin.cpp
nsresult rv;
nsCOMptr< myCompClass > _myComPtr ;
_myComPtr = do_CreateInstance( "@myDomain.org/DIR/MYCOMPONENT;1", &rv ) ;
Функция
do_CreateInstance( ) ;
происходит от nsComponentManagerUtlis.h который выходит из xulrunner SDK, но не имеет ничего общего
do_giveMeTheRunningInstanceOf( "@myDomain.org/DIR/MYDATACREATOR;1", &rv ) ;
Моя интуиция сейчас заключается в использовании
nsScriptablePeer::Invoke(NPIdentifier name, const NPVariant *args, uint32_t argCount, NPVariant *result )
способ передать nsCOMptr бега dataCreator в плагин, сделать возможным прямое общение и уменьшить XUL<-> Плагин ввода / вывода до минимума.
Создание другого экземпляра dataCreator это определенно не вариант!
Если честно: я не знаю, как «преобразовать» NPVariant (args [0]) в нужный nsCOMptr, не так ли? Или есть другая возможность получить указатель внутри плагина?
Спасибо за вашу помощь
Я не знаю, как взаимодействовать с xulrunner sdk напрямую из плагина npapi, поскольку они используют совершенно разные API. NPVariants не может передавать объект xulrunner или другой собственный тип указателя.
Это полный мозговой штурм, и я понятия не имею, сработает ли он, но если бы вы могли каким-то образом объединить расширение xulrunner и плагин npapi в один и тот же модуль, вы могли бы использовать глобальную карту и идентификатор из плагина для получения общей памяти , но я понятия не имею, возможно ли это или нет.
Вы правы, что взаимодействие с javascript имеет свою стоимость; на самом деле, однако, это отдельные звонки, которые имеют наибольшую стоимость, потому что они в конечном итоге являются перекрестным процессом. Часто вы можете минимизировать это, используя более эффективные звонки. Быстрее 100 мс определенно не должно быть проблемой.