IRC Log Viewer » #firebreath » 2011-04-13

IRC Nick Time (GMT-7) Message
taxilian 10:04 so has anyone in here actually tried out the 1.5RC yet?
kylehuff 11:04 I have not; I hope to this weekend...
zeus_ 13:04 hi..What is the best way of sharing large data(read-write on both sides) between plugin and javascript?..Is there a mechanism like memory mapping or buffering?.
taxilian 13:04 there really isn't a good way to do that, I'm afraid
NPAPI just doesn't expose anything like that
how are you storing it in Javascript?
zeus_ 13:04 it is webgl application so we allocate float buffers
but we want to update in plugin and return to javascript
taxilian 13:04 well, any object accessible by javascript you can probably pass the javascript object in question into the plugin
and access it using normal calls
so I would just pass the float buffer into the plugin as a JSObject
and call it just like you would from javascript
keep in mind that you can only access it on the main thread
zeus_ 13:04 updating each element in array buffer will be a function call synch with the main thread that is a very big overhead
taxilian 13:04 yes it certainly is
zeus_ 13:04 I was thinking there should be someothe way around
taxilian 13:04 one thing you can do is batch the conmands
so that it calls to the main thread, does all the commands at once, and then returns
rather than making a seperate cross-thread call for each command
zeus_ 13:04 is there a code snippet for that?
taxilian 13:04 just put those commands in a function and call the function using host->CallOnMainThread
!wiki CallOnMainThread
hey... where is my bot?
there you are!
!wiki CallOnMainThread
FireBreathBot 13:04 4 results found. Note: Results limited to 8
"class FB BrowserHost CallOnMainThread":
"Frequently Asked Questions":
"Version History":
zeus_ 13:04 thanks taxilian..I'll try that..Also it is weird though the browser developers should think of the cases like this right..There should be javascript object just for fast update plugin2javascript or javascript2plugin
taxilian_web 13:04 grr.. fyi everyone, my internet connection is flaky the last few days, so IRC isn't working well
zeus_ 13:04 lots of application can be developed with that
taxilian_web 13:04 zeus_: sorry, with what?
zeus_ 13:04 if there is an object for fast data transfer
taxilian_web 13:04 the problem is that all objects have to use javascript primitives
zeus_ 13:04 yaa..that is the reason we're waiting javascript engine of the browser, is that right?
taxilian_web 13:04 so you could create a JSAPI object for that if you wanted, but you'd still be stuck only being able to make API calls that accept double, int32, bool, string, or another object
and those API calls will all have to happen on the main thread, since that's the only place we can talk to the browser with
that's why generally if you're using a plugin, you just do the opengl drawing yourself
zeus_ 13:04 webgl people are also having the same problem. since in webworkers you can only send/receive messages you can't share objects by reference
taxilian_web 13:04 yeah; it's a common issue
dan2 13:04 taxilian_web: I'm going to go do an upgrade, but I think we may have a problem with holding shared ptrs to plugin instances that cross threads when the destructor is called in a different thread
taxilian_web 13:04 dan2: the destructor of a plugin instance is never called on a different thread
not unless you're doing something wrong, anyway
hmm; I guess I could conceivably see one instance where that could happen; if you were doing something with the plugin object on the toher thread that you needed a shared_ptr to it could cause you to hold it for just a bit too long, since there isn't really another way to know that hte plugin should be shutting down
perhaps we need to add a "shutdown" method on the plugin for that purpose
dan2 13:04 it is called on a different thread because I may hold an instance to the plugin where the plugin is held by shared pointer and as part of the destruction process
I highly recommend that
taxilian_web 13:04 well, you shouldn't "hold" a shared_ptr to the plugin; you should use a weak_ptr
however, while you have the weak_ptr locked I can see how that could be an issue
add a JIRA ticket =]
I'll put it in 1.5
pomegrate 14:04 Hello,
I just have a question.
If the MIME type is something like "abc/def", would it still be invoked from the HTTP response? (i.e. Content-Type: abc/def)
taxilian_web 14:04 pomegrate: I would assume that any mimetype has that potential
I haven't really played with how NPAPI plugins work as full page plugins, however
pomegrate 14:04 When I was trying with x-BasicMediaPlugin, it was invoked from the HTTP reponse.
However, after changing it to "abc/def" (for my use), it is not invoked.
It is only invoked by type="abc/def" HTML directive
taxilian_web 14:04 interesting
no idea why
pomegrate 14:04 But it should be working right?
maybe i am missing something
taxilian_web 14:04 to be honest, I have no idea. I have never had a need or desire to invoke a plugin based on the response mimetype
pomegrate 14:04 Oh okay, but do you know on which part does the response mimetype invoking is occuring? the source code
taxilian_web 14:04 nope