IRC Log Viewer » #firebreath » 2013-02-24

IRC Nick Time (GMT-7) Message
taxilian 10:02 haxmeadroom: there isn't anything in NPAPI for dealing with binary data, but it does work for strings
thus base64 is the fastest option
and no, you can't send binary data in the string; the string has to be valid utf8
haxmeadroom 10:02 taxilian: ahh Yeah, tried that route. :)
taxilian 10:02 there is one other option, I suppose
you could run an embedded web server
there is even one already in the firebreath codebase
but keep in mind that you'll have problems if you run over https
because the embedded web server won't be running https
so you'd be requesting resources from a non-https web server from a https page
haxmeadroom 10:02 taxilian: Yeah, we've considered that, or saving the file to the filesystem and reading it from the plugin
taxilian 10:02 wait, you need to get binary into the plugin or out of it?
haxmeadroom 10:02 both
taxilian 10:02 so getting it into can be easier, because the plugin can download binary data from a server
I suppose you could also have the plugin upload the data using curl, though
haxmeadroom 10:02 I think I'll eventually go that route, but probably base64 for now. I wonder how the npapi folks could have overlooked this??
taxilian 10:02 I suggested a fix, but they didn't like it because there isn't a consistent enough cross-browser binary datatype
and I just haven't had time to update the recommendation
haxmeadroom 10:02 Yeah, I ran across your recommendation doing searches for solutions yesterday..
johannes 10:02 haxmeadroom: firefox-.specific: For doing uploads i use something like this: https://github.com/johannes/FireBreath/commit/47c6655f1438669ecacb6b1157a7f296a52cb015
haxmeadroom 10:02 johannes: That looks cool, thanks!
johannes 10:02 haxmeadroom: feel free to improve it in any way ... especially w/ other browsers ...
haxmeadroom 12:02 Is there much of a performance benefit to using FB::JSObjectPtr for pass-by-ref instead of say std::string and pass-by-value?
haxmeadroom 12:02 Also, how do you deal with memory leaks? Say if you return a char* that was malloced
haxmeadroom 13:02 Any ideas on how to get  the /SAFESEH:NO option in Visual Studio with the .cmake files?
taxilian 13:02 johannes: does that only work on firefox?
haxmeadroom: string and object are not the same type… not sure I understand the quesiton
haxmeadroom: on the flag, is it a link flag or a compile flag
haxmeadroom 13:02 It's a link flag
taxilian 13:02 then you should just need to add it to LINK_FLAGS (a target property)
haxmeadroom 13:02 taxilian: If the object were a string, would there be a performance benefit?
taxilian 13:02 string is probably giong to be slightly more efficient
haxmeadroom 13:02 taxilian: Ok..
taxilian 13:02 but only because once you have the object, you have to make another call into the browser to get the string
or whatever other value
a JSObjectPtr is just a wrapper around the browser's native object type
and every time you make a call on one of those it ends up going across the process boundary (or at least thread boundary in IE) which has a performance hit
that's why returning an array is inefficient; it's slick, but you have to make a call to create an array, then a call for each array value. (firebreath does it for you, but the performance is the same)
haxmeadroom 13:02 So what about a JSObjectPtr for a Uint8Array for efficient binary data?
johannes 13:02 johannes: in the current form, yes, I haven'T found an IE API for that
taxilian 13:02 haxmeadroom: you could probably pass that in, but it would still not be efficient because you'd have to make a call for every single byte you put into it
haxmeadroom 13:02 taxilian: Damn.. Wonder if I can get a pointer to the bytes somehow...
taxilian 13:02 nope
if you could, that would be a security risk
and they'd fix it as soon as they found out
haxmeadroom 13:02 taxilian: Well, in the plugin getting a pointer, not through an official API. Is there a possibly non legit way to get a pointer to the original javascript object?
taxilian 13:02 I really doubt it, since you're in a different process
but again, if it were possible it would be a security risk
and they would fix it ASAP as soon as they found out
haxmeadroom 13:02 For NPAPI its in another process or IE?
taxilian 13:02 npapi
ie sometimes
haxmeadroom 13:02 damn.. Yeah, pointers wouldn't help then
base64 it is then...
taxilian 13:02 hehe. I dont' blame you, but I really have been through all of this already… when I say that's the best option, I meant it =]
haxmeadroom 13:02 taxilian: haha.. I'll take your word for it. I just thought since we may not need IE, there would be a way around it.
taxilian 13:02 nope
actually ie might have a better way
but npapi certainly doesnt
haxmeadroom 14:02 I converted it and base64 is a LOT faster!
nirvdrum 14:02 Ugh. Not exactly Firebreath related, but it's been a while since I've been in VS. I just installed the IE9 SDK. Any pointers on how to get those headers and libs into my project would be appreciated.
They don't seem to be auto-added from the VC++ directories.
I think I just got it. Thanks.