IRC Log Viewer » #firebreath » 2013-04-12

IRC Nick Time (GMT-7) Message
Aktau 03:04 Does anybody know when the browser calls NPEnumeration? It doesn't seem to do it for me
(chromium 25 on linux)
prhyme 04:04 hello, guys. what happens to the plugin, when i close the browser? is ~SbisDocviewPluginAPI() (destructor) called?
johannes 04:04 prhyme: http://www.firebreath.org/display/documentation/Plugin+Lifecycle
doesn't answer the question fully, though ;-)
but should help a bit
prhyme 04:04 ... and it helps) thank you!
mrahr 05:04 HI
A question
how do I store a boost::shared_ptr<myAPI> myPtr, so that I can use it later on ?
max242 07:04 sorry reichi for not seeing your answer earlier
i'm not pursuing that path anymore
reichi 07:04 :)
max242 07:04 I'm now reading the context buffer using readPixels in JavaScript now
reichi 07:04 :)
max242 07:04 and would like to pass the memory created using Uint8Array to my FireBreath plugin
(So i did like your answer :-)
question: what datatype do I use on the FireBreath side to further deal with the buffer (swpiing i
(swapping it to my video hardware)
An STL container?
or JSObjectPtr?
taxilian 07:04 max242: assuming it works, you'd probably use a JSObjectPtr
npapi knows nothing about a uint8array, so it's only useable as a javascript object
like any other js object
max242 07:04 thx taxilian - let me try
buffer->GetProperty("length"); already returns the correct length of buffer
what method (in JSObjectPtr) do i call to access to the buffer?
taxilian 08:04 I'm not sure I understand the question
what would it be in javascript?
it's going to be Invoke or GetProperty pretty much
max242 08:04 JavaScript reads the content of the WebGL context using readPixels into a buffer
the buffer is allocated in JavaScript using Uint8Array
the buffer I pass to FireBreath
taxilian 08:04 that will most likely be too slow for whatever you're doing
just FYI
max242 08:04 Really? Is the buffer processed when passing it to FireBreath?
ReadPixels is fast enough (in regular OpenGL)
(don't know in WebGL)
i'd like to pass the buffer to an external buffer (Bluefish444 video hardware)
max242 08:04 also looking at http://stackoverflow.com/questions/12336599/access-javascript-array-in-c-plugin for the answer, but not sure how to extract the array from the JSObjectPtr
prhyme 09:04 in MyPlugin::onPluginReady() i call MyPluginAPI method like this: getRootJSAPI()->Invoke("launchAX",FB::variant_list_of()) . in launchAX i create m_wvptr(FB::View::WebView::create(getPlugin(), m_host)). after that i try to call m_wvptr->loadUri() and the plugin crashes.
what am i doing wrong?
taxilian 09:04 prhyme: without knowing what the crash is, it's hard to say
you could try attaching a debugger so you can find out what the crash is
prhyme 09:04 i tried also loadHtml() , so it crashes when i try to call m_wvptr`s methods...
m_wvptr is FB::View::WebViewPtr
taxilian 09:04 you could try attaching a debugger so you can find out what the crash is
prhyme 09:04 mm, ok, i will try
max242 11:04 I'm passing an array (created in JavaScript using new Uint8Array(1000)) and would like to use the that buffer in FireBreath. I need the address to that buffer
What do I need to call to get the address of the buffer ?
method in FireBreath called by JavaScript: void TestAPI::contentReady(const FB::JSAPIPtr& buffer)
(JSObject::GetArrayValues would be too slow (cfr what Taxialian mentioned) - I need the address of the first element, hoping that the buffer allocated in JavaScript is unchanged)
taxilian 11:04 you *can't* get the address of the buffer
it's in a different process
not possible
max242 11:04 OK - I'll look for alternatives
taxilian 11:04 basically for transfering huge amounts of data like that your best bet is probably to base64 encode it and send it across
max242 12:04 I can try, but that will be to slow - the buffer is (1920 x 1080 x 4) bytes long and I need to do this 50 or 60 times a second
I was looking at Shared Memory, but that is not supported in JavaScript AFAIK
taxilian 12:04 quit now
there is now way to send that much information between javascript and a plugin at high enough performance
base64 is the closest you'll get
max242 12:04 OK - thx - bye
jshanab 12:04 Ouch. that is some high bandwidth.
I just logged on. But I was wondering why the data be going to javascript?
max242 12:04 I'm using WebGL and would like to send the content of the drawing buffer to an external video buffer (Bluefish444 - HD video)
jshanab 12:04 When i started to do my video player i looked at WebGL, it's title sounded like it was what I needed. But I discoevered it was very restricted to javascript. I wonder if the buffers belong to the webgl implementation and there is a way of tagging them and retrieveing them from the opengl driver from the c++ side. Don't pass them, just fetch a ref to them in each language.
Kinda like the shared context stuff and named textures on openlgl. (But this would be painful)
max242 12:04 between process this is very difficult, already hard between threads in the same process - I now understand that FireBreath runs in its own process
reichi 12:04 jshanab: there isn't
acutally on windows chrome uses direct3da s webgl-backend
jshanab 12:04 You can override that in Firefox BTW. The other way to move binary data very fast is ZMQ. I don't know if there is a javascript binding, but that would be interesting
max242 12:04 (looking up ZMQ)
jshanab 12:04 I am looking but it looks like it is string based only, not an actual library wrapper.
max242 12:04 it indeed looks like strings only - and would also add unnecessary copying of the buffer - ideally i'm looking for direct access to the render buffer
jshanab 12:04 I run accross a similar situation on android. Gotta stay on one side the fence or the other. Crossing it invloves coping and that is jsut not practical