IRC Log Viewer » #firebreath » 2011-09-08

IRC Nick Time (GMT-7) Message
dougma 00:09 anyone know about NPAPI:CocoaEventModel ?
how do i get the button state on mouse events?
as far as i can tell... i can't tell button state on mouse moves
dougma 01:09 hooray for half-baked APIs
taxilian 09:09 dougma: yeah, that sounds about right
there may be system APIs to check button state
chris____ 11:09 hi
taxilian 11:09 hi
chris____ 11:09 I'm getting some strange behaviour in an NPAPI plugin I'm writting.
Basically I've been using NPN_InvalidateRegion to force my NPAPI plugin to redraw itself., this was working fine under OSX in safari in 32bit mode.
it doesn't seem to work/fire in 64bit mode
just wondering if you hit this before?
this is the browser run in 32 versus 64 bit mode, plugin unchanged
taxilian 12:09 (I'm interviewing someone right now, so I'll be back in about 30 min)
chris____ 12:09 sure thing thx
taxilian 12:09 (taking longer than I expected; another hour tops :-P)
chris____ 12:09 alright, I'll fight with it somemore
taxilian 12:09 Try just using InvalidateWindow
InvalidateRegion has never been consistently implemented, AFAIK
chris____ 12:09 sorry, this is a raw npapi plugin (not using firebreath) although I might be re-writing in firebreath soon.
I've been reading that the NPN_XXX functions are suppose to be called from the "main" thread. I've been doing my calls from a secondary "rendering" thread
taxilian 12:09 I would highly recommend rewriting it in firebreath =] it would simplify a lot
no, you can't do that
you have to call them from the main thread
or very bad things could happen
chris____ 12:09 right I see that now :(
taxilian 12:09 it most likely would be easier than you think to port to FireBreath
it's pretty straightforward
what drawing model are you using?
chris____ 12:09 core graphics
taxilian 12:09 and you're not doing anything crazy like trying to use a NSView or render OpenGL, right?
you're aware that you only get the Cocoa model in 64 bit mode?
and that in 64 bit mode you get the CGContextRef with each draw event and you can only use it during the lifetime of that event?
chris____ 12:09 really?
taxilian 12:09 not sure which you're asking about, but yes
chris____ 12:09 yes the contextref is only being used on update event
just a sec, I'll describe my issue/project in detail
taxilian 12:09 and you're getting the contextref from the event and not trying to pull it from the NPWindow when in cocoa, right?
chris____ 12:09 hmmm, perhaps this part is wrong too, I get my contextref from my NPWindow ( which I update on every 'setwindow" call). But I only try to us it inside my "updateEvt handler.
The thing is, my plugin is actually screen scraping a 3d game from an offscreen window running in a seperate process. Hence i needed the plugin to "paint itself" at about 30/sec. I setup a secondary thread/timer which would call NPN_InvalidateRect. I found this call would raise an update event to my plugin, where I could perform the screen scrape and output results to the contextref. I settled on core graphics to cover older OSX
all this worked in 32 bit safari, but the event doesn't seem to fire in 64bit safari
btw, thank you for your documentation on the supported drawing/event models, very helpful
taxilian 12:09 (I'm still in the interview, so hang on)
chris____ 12:09 np
brb too
chris____ 13:09 back
chris____ 13:09 hi
might have missed last few messages
taxilian 14:09 there weren't any
chris____ 15:09 @taxilian, you were correct, I need to add support for cocoa events if running under 64bit safari
thx for your help.
taxilian 15:09 makes sense
good luck
still consider porting to FB… it'd save you time in the long run
chris____ 15:09 I've looked enough in the firebreath code to see that there are so many nicely supported paths. My issue with using firebreath was the size of the final plugin. I'm shooting for about 500k
taxilian 15:09 my final plugin is about that
chris____ 15:09 hmmm, I posted about the size here:
taxilian 15:09 is that compressed or not?
chris____ 15:09 not compressed
taxilian 15:09 so first of all, the compressed size is really what you are worried about; secondly, I suspect you were building a universal binary there; if you build a 32 bit only binary you'll get about half the size
and it'll still work on 64 bit builds
chris____ 15:09 true I didn't change the project to build 32 bit only ... I'll give that a try
taxilian 15:09 but your'e right; you won't get it a lot smaller than that.
other than the 32/64 bit thing