IRC Log Viewer » #firebreath » 2011-03-18

IRC Nick Time (GMT-7) Message
neilg_ 07:03 Morning all!
nitrogenycs 08:03 morning neil
Ed___ 11:03 Quick question about the onload callback..
taxilian 11:03 hey Ed__: been awhile. go for it
Ed___ 11:03 If I call plugin.valid, I get undefined rather than valid..
taxilian 11:03 how did you get the reference to "plugin" and which browser/os?
Ed___ 11:03 getElementById, and WIN32 (Vista)
taxilian 11:03 browser?
Ed___ 11:03 Think it applies to Chrome 10 and Firefox 4b12. Going to check IE next..
taxilian 11:03 also applies to IE
the browser hasn't linked the plugin element in yet
don't know of any way to know for sure when it has
onload gets a parameter that is the root jsapi object
just use that
Ed___ 11:03 ah ok.
Its not a big problem. I can just add an onstarted callback or something a bit later on.
Just wanted to make sure I hadn't borked anything..
taxilian 11:03 seriously, use the param
Ed___ 11:03 Yep. I shall do that.
taxilian 11:03 function myonloadcallback(plugin) { alert(plugin.valid); } will work
Ed___ 11:03 Been making good progress. I love the stuff you can do that just works!
taxilian 11:03 =] yeah, I wrote most of it and though it may sound immodest, whenever I use it I just grin and grin... "hey, that was easy"
Ed___ 11:03 Make a JS call to the plugin to start a thread
pass in a JS function
when thread finished just callback into JS
two lines of code :D
This is why I code..
taxilian 11:03 hehe. yep =] I'm actually fairly proud of the cross-thread stuff; it works quite well
if it's particularly helpful and you wanted to contribute back, better docs on how threading works in FireBreath on the wiki would be awesome...
Ed___ 11:03 Might look to that at some point then. I did a couple of quick updates after I got the WiX stuff going.
taxilian 11:03 I appreciate that
I don't have much time to do documentation unless there is nothing that needs to be done in the code
Ed___ 11:03 Once I get my head around the boost::bind stuff, threading was pretty painless. (boost n00b)
taxilian 11:03 then that's the sort of thing that we should add better examples and explanation for in the docs
Ed___ 11:03 yeh, I usually find that if I can cross-reference a couple of examples I can pull it apart and understand it..
taxilian 11:03 yeah; I think what FireBreath needs the most right now are more and better examples
Ed___ 11:03 I may look to drop that into the docs somewhere too. Diunt see onload with a parameter mentioned..
Certainly there is alot of power there now.
taxilian 11:03 yeah; I probably haven't documented that well anywhere
you're the second to ask about it in 24 hours
Ed___ 11:03 Well, docs is never the first thing anyone does.
Cool. Thanks again for the pointers.
I need to jump off. End of the week here..
taxilian 12:03 .findfile NpapiPlugin.cpp
FireBreathBot 12:03 Found 1 matching file(s) in the master branch. First 1 are:
sabotaged|wk 12:03 so the windowless support on firebreath, is that for npapi+activex?
FireBreathBot 12:03 JIRA issue issue created by richard
taxilian 12:03 sabotaged|wk: yes, though there are some issues on activex that we're still trying to narrow down
sabotaged|wk 13:03 i see you mentioned on the list that Anson found that the only way to draw to a windowless plugin with D3D etc is to draw to an off screen window and then blit
is that still the case?
taxilian 13:03 as far as I know; however, you're welcome to try it =]
sabotaged|wk 13:03 looks like i might have to do that, since i'm using directdraw in another process to draw
taxilian 13:03 you would definitely have to draw only when instructed by the window
that won't work with windowless
you have to draw on the draw event with windowless
sabotaged|wk 13:03 yeah thats what i gathered
taxilian 13:03 oh, I misunderstood
yeah; drawing offscreen and then blitting should work cross process, I would guess
grr. FIREBREATH-10 is going to be a pain to track down
FireBreathBot 13:03 FIREBREATH-10: Summary: BrowserHost is not being released on shutdown of the plugin or even the process
FIREBREATH-10: Assigned To: richard
FIREBREATH-10: Priority: Critical
FIREBREATH-10: Status: Open
taxilian 13:03 when the plugin shuts down BrowserHost still has a refcount of 6
hopefully it's just one thing, but finding it could be fun...
taxilian 13:03 welcome
amackera 13:03 Sweet:
taxilian 13:03 will definitely need to look at this more
anyone want to do a quick, most likely fairly easy, python project for me?
I'd do it but I need to fix this memory leak
dan2 14:03 hey guys
amackera 14:03 hey
taxilian 14:03 hey dan2
dan2 14:03 how do I debug a javascript issue on startup of my extension/plugin? the error console doesn't show up with this one.. :(
not in menus..
taxilian 14:03 ouch; I'm really not sure :-( if it's inside FireBreath that's a little easier because you can use gdb, but in javascript... I have no idea :-/
dan2 14:03 something is really unusual
god damn it
taxilian 14:03 I'm arbitrarily inventing a new convention; let's try to make a jira issue for anything we push to the repo; that will make it much easier for me to figure out change history
and put the jira issue in the commit message
multiple commits per issue are perfectly fine
amackera: thoughts?
dan2 14:03 man..
not sure what to do
taxilian 14:03 dan2: I wish I could help :-/ I really haven't a clue
I don't do extensions
dan2 14:03 I'm assuming the issue is javascript related
taxilian 14:03 hmm. you could try putting a try .. catch block as early as you can and doing an alert on catch
dan2 14:03 but honestly I can't tell
it makes it through the entire onload() procedure well
it's kinda like xul is choking in the background
taxilian 14:03 :-/
stuartmorgan: you around?
taxilian 14:03 amackera: I have some mac window changes for you
amackera 14:03 oh?
color me curious
FireBreathBot 14:03 Commit 99bbcde on master by Eric Herrmann: "FIREBREATH-8 Support ICA"
Commit b3d0a7a on master by Eric Herrmann: "FIREBREATH-8 Added FBMAC_USE_INVALIDATINGCOREANIMATION and P..."
Commit 533f25a on master by Eric Herrmann: "FIREBREATH-8 Refactored window invalidation timer to base cl..."
Commit ae02bb4 on master by Richard Bateman: "FIREBREATH-8 Fixed PluginWindowMacICA"
taxilian 14:03 you'll still need to do the coregraphics draw event, I suspect
unless it's done and I didn't see it?
amackera 14:03 not done yet
taxilian 14:03 this change may affect what you were doing
but ICA should mostly work correctly now; we're still having some issues on Chrome on 10.5
FireBreathBot 14:03 FIREBREATH-8: Summary: Modify Mac plugin windows to support all valid Event / Drawing model combinations
FIREBREATH-8: Assigned To: amackera
FIREBREATH-8: Priority: Major
FIREBREATH-8: Status: Open
taxilian 14:03 I put them on your issue
since it's related
amackera 14:03 sure makes sense
i should get a chance this weekend to commit some code
taxilian 14:03 cool
sabotaged|wk 15:03 how do i tell firebreath to be windowless? is it through cmake?
oh no some parameters to the plugin it seems
taxilian 15:03 yep
sabotaged|wk 15:03 got it
stuartmorgan 15:03 taxilian: pong
FireBreathBot 15:03 Commit 35d8578 on master by Eric Herrmann: "Added some logging of the autoinvalidate"
Commit 4ecb5d5 on master by Richard Bateman: "FIREBREATH-8 Fixed typo causing CA problem"
taxilian 15:03 stuartmorgan: question on ICA
to make sure we're doing this right
when we call InvalidateRect, does it copy the bits immediately or just flag it to copy them the next time the browser draws?
stuartmorgan 15:03 Neither
It sends an async method to the browser to draw the plugin region from the shared surface
(in Chrome)
taxilian 15:03 ok
stuartmorgan 15:03 (Well, on 10.5 it does grab the bits; that probably happens synchronously)
taxilian 15:03 wait
on 10.5 it odes?
stuartmorgan 15:03 (but it will draw at a later point)
taxilian 15:03 because that's where it isn't working for us
well, crap. :-P
stuartmorgan 15:03 On 10.5 we use CARenderer to draw to a bitmap context IIRC
And swap it out with another so it's available for drawing in the other process without corruption
I didn't write the internals of our surface abstraction, so I'm fuzzy on the details
taxilian 15:03 hmm. what we're doing may not work, then; need to rethink this
do you know where in the code it is?
(I can look, but if you already know where it is it'd save me a few minutes)
stuartmorgan 15:03 The theory is that it shouldn't matter to the plugin which path is used
taxilian 15:03 well, I'm trying to figure out if it does or not
stuartmorgan 15:03 I think is most of the 10.5-specific stuff
taxilian 15:03 thanks
stuartmorgan 15:03 Chrome's CA path has gotten almost no testing in the real world on 10.5, so it may be broken in cases we don't know about
I verified it with a modified version of Apple's CA sample plugin
taxilian 15:03 hmm. that's worrysome =] we're not able to draw on 10.5
but it works on ff4 and 10.6 chrome
stuartmorgan 15:03 But in the real world, I don't know of plugins that use CA on 10.5
taxilian 15:03 but our app in where it draws doesn't know about the browser, just that we're using CA; so we set up a timer to invalidate at the same speed that we draw
well, we have one =]
stuartmorgan 15:03 I've heard from more than one person that CA on 10.5 is too buggy to be useful
Unclear if that meant Safari's CA on 10.5, or CA itself
(too buggy in the context of writing a plugin)
taxilian 15:03 Safari on 10.5 works fabulously
for us
are you talking CA or ICA or both?
incidently, using CA on 10.5 in Chrome also worked great
stuartmorgan 15:03 CA; these discussions predate ICA
taxilian 15:03 wait
no it didn't
CA on Safari
sorry, misunderstood what he said for a minute =]
stuartmorgan 15:03 I don't know the details; I just know that more than one plugin vendor has mentioned something to this effect
And in practice, Flash, QuickTime, Unity, and Shockwave, which covers most of the CA plugins, all use CA on 10.6 only
taxilian 15:03 hmm. I guess we might have to fall back to QD on 10.5
stuartmorgan 15:03 But that doesn't mean ICA shouldn't work in Chrome
taxilian 15:03 hmm
so ICA should work?
because ICA is working for us on 10.6, but not on 10.5
stuartmorgan 15:03 In theory, yes. And it did work with the modified test plugin
But I get the impression GL drawing can be finicky; maybe something about drawing to the FBO is failing?
If there's any way you could provide me a test case I could try to look into it next week
taxilian 15:03 I'll see what we can manage
FireBreathBot 15:03 Commit 462106e on firebreath-1.4 by Richard Bateman: "FIREBREATH-10 Fixed browserhost refcount issue by changing t..."
tomek_ 15:03 Hello
taxilian 15:03 hello
tomek_ 15:03 I was wondering if anyone here could help me.
I'm writing a plugin that displays JPEG images extracted from MJPEG stream from an IP camera
taxilian 15:03 sounds fun
tomek_ 15:03 I have recently switched to Firebreath, which is just awsome
taxilian 15:03 we like it =]
tomek_ 15:03 So far used plain NPAPI
the switch was actually fun and very quick (less than a day)
taxilian 15:03 awesome! I'm always curious to hear how migration goes
tomek_ 15:03 I'm currently testing it on Firefox @ Mac OS X
everything works fine except one little "thing"
taxilian 15:03 which branch? master or 1.4?
tomek_ 15:03 when I have several tabs, and switch between them, the image which is supposed to be drawn in the place where plugin is embedded is drawn in the lower left corner of the window
taxilian 15:03 also which drawing model?
tomek_ 15:03 1.4.1
CoreGraphics + Carbon
taxilian 15:03 amackera, any ideas?
tomek_ 15:03 the strange thing is that exactly the same drawing code works find in the plain NPAPI verson
I looked at the Firebreath source code, and the event processing seems very similar to what I was doing before, when using plain NPAPI
taxilian 15:03 well, 1.5 might work better, but you'd have to fix the coregraphics code a little bit
tomek_ 15:03 one more thing, it may be coincidence, but that "wrong" image is drawn approx. 1 second after the tab switch
taxilian 15:03 still, if you know how to do it with plain NPAPI it'd probably be easy
tomek_ 15:03 and the image is up side down
taxilian 15:03 I don't really know that part of hte code; it's the one piece that I'm not really familiar with
tomek_ 15:03 ;-)
taxilian 15:03 hmm. that sounds familiar.
tomek_ 15:03 for CG it has to be flipped
taxilian 15:03 amackera could probably help if he comes back
tomek_ 15:03 I suspect...
taxilian 16:03 hmm. yeah, I really don't know. we don't have many people using drawing on mac yet; we're starting to get there, and that's where the new model that we use in firebreath 1.5 (dev version) comes from
however, that model has a couple of issues with CG
tomek_ 16:03 I haven't looked at 1.5, is it a lot of work to fix these issues with CG?
I can invest some effort there
If that would help
taxilian 16:03 probably not
amackera was planning to do it this weekend
it should be pretty straightforward
just need to abstract the difference between cocoa and carbon
tomek_ 16:03 I see
taxilian 16:03 .findfile PluginWindowMacCG
FireBreathBot 16:03 Found 2 matching file(s) in the master branch. First 2 are:
taxilian 16:03 like most projects, there is more to do then there are developers to do it
amackera 16:03 tomek_: I believe i know the answer to your problem
taxilian 16:03 hey, he's back!
he will solve all your problems
amackera 16:03 hahah
tomek_ 16:03 Great
what is it?
amackera 16:03 tomek_: I believe you must clip your CG drawing region to the bounding box
tomek_ 16:03 OK, I'll try that.
I actually already thought about it, but then I thought "why did it work without clipping before"
amackera 16:03 tomek_: Also a question I have been asking myself
tomek_ 16:03 I mean when I was using plain NPAPI
amackera 16:03 Yeah doesn't seem to quite make sense, but FireBreath doesn't touch the CGContext at all
tomek_ 16:03 Also, the image is draw upside down...
amackera 16:03 I have a theory about that :P
tomek_ 16:03 I know very little about QuickDrawm but isn't it that it has exactly the opposite orientation to GC?
amackera 16:03 Yes, that's true
tomek_ 16:03 What I thought might be happening is that somehow (I don't know how though) Firebreath is delivering RefreshEvent for something that originally was not NPAPI's updateEvt
, and the CGContext then is something else...?
taxilian 16:03 well, the RefreshEvent would come from the PluginWindow object; I guess that's possible
amackera 16:03 Yep that's possible
and the CGContext wouldn't be strictly speaking valid at that point
taxilian 16:03 with the new one in 10.6 you will *only* have a context during the duration of the event
tomek_ 16:03 that's what I suspect
amackera 16:03 refactored away the bug :)
Either way, for the time being, check the dimensions of your CG bounding box
taxilian 16:03 I think we'll release 1.5 as soon as the new pluginwindows are ready
at least RC1 of it
amackera 16:03 CGContextGetClipBoundingBox()
if it's a wonky size, don't draw
taxilian: I like that plan
tomek_ 16:03 OK, thanks again. I'll do that and let you know how it goes.
amackera 16:03 alright, good luck!
taxilian 16:03 grr. so I fixed the memory leak on 1.4 but it isn't fixed on 1.5, so there is something new :-P
I'm going to add a refcount and assert that all BrowserHost objects have been destroyed when the program closes
to keep us honest
amackera 16:03 good call
stuartmorgan 16:03 FYI, checking the bounding box isn't going to be sufficient to fix all problems if plugins are drawing at the wrong time
taxilian 16:03 stuartmorgan: I think it was intended as a patch measure until we finish fixing the 1.5 CG window =]
stuartmorgan 16:03 Sure, I'm just saying there will still be weird bugs
taxilian 16:03 I'm really excited for 1.5 to be ready; the mac window code is really starting to feel solid and useable. we just need to figure out the 1.5 ICA chrome issue and the CG stuff
stuartmorgan 16:03 In Chrome the check will never fail, and you'll get tearing if drawing collides with the renderer process
taxilian 16:03 the correct fix would be to find what else could be firing a refreshevent and why and making sure that it doesn't do it anymore
tomek_ 16:03 Ok, I have an update
Typically I'm getting Refresh with clipCGRect like this: 0.000000, 0.000000, 640.000000, 480.000000
(plugin is not obscured)
when problem hits the clipCGRect is like this: 0.000000, 0.000000, 895.000000, 1015.000000
taxilian 16:03 can you catch it in a debugger and see what is firing the RefreshEvent?
tomek_ 16:03 quite often I also get: clipCGRect: 0.000000, 0.000000, 0.000000, 0.000000, however these are harmless and I guess easy to filter out...
Good idea, I'll try
sabotaged|wk 16:03 anyone run into deadlocks with PluginWindowlessWin's InvalidateWindow?
i guess i should update to 1.4 final, but thought i'd ask anyways
taxilian 16:03 sabotaged|wk: I haven't, but I can look at it if you still have the issue in final
sabotaged|wk 16:03 ok
i want the tag firebreath-1.4.0?
taxilian 16:03 no
you want branch 1.4
that puts you just shy of 1.4.2
but I'm very careful about what I put in there
sabotaged|wk 16:03 ok
taxilian 16:03 .findfile firebreath-1.4 SimpleStreamHelper
FireBreathBot 16:03 Found 2 matching file(s) in the firebreath-1.4 branch. First 2 are:
taxilian 16:03 heh. that's actually faster than looking it up myself :-P
now I just need to teach FireBreathBot how to fix bugs
amackera 16:03 Heh, cool. IRC on iPhone
taxilian 16:03 lol. yeah, I use colloquy on my iphone and ipad
what are you using?
amackera 16:03 Colloquy :)
tomek_ 16:03 Hi, I just run this issue strange updateEvt in gdb
I'm not sure of its significance but message in the event (I understand that in case of updateRvt this should be the window) is different than win
amackera 16:03 the window that it passes you is different?
tomek_ 16:03 or maybe it should be like this, because it is different window?
amackera 16:03 i'm not sure what the issue is
tomek_ 16:03 hang on, I don't know, I guess I should compare it with m_winRef, right?
FireBreathBot 16:03 JIRA issue issue created by jloveridge
tomek_ 16:03 OK, the message in the event is actually the same as m_winRef
FireBreathBot 16:03 JIRA issue issue commented by richard "uh, wow."
tomek_ 17:03 Hi, I have to go to sleep now, but I looked at this in the debugger and there is nothing special in the EventRecord when this happens, for the time being the workaround with checking the clippingrect seems to be working for me.
@amackera, thanks once again for the help, and bye bye.
taxilian 17:03 awesome... we can insert nice links to jira issues directly in confluence
physicsrob 17:03 hello
FireBreathBot 17:03 Commit cb9f70e on master by Richard Bateman: "Fixed FIREBREATH-10 on 1.5 branch"
Commit c08c6c1 on firebreath-1.4 by Richard Bateman: "Touching on FIREBREATH-10, fixes memory leak in SimpleStream..."
taxilian 17:03 hey rob
how're things?
been awhile
physicsrob 17:03 not bad -- insanely busy
what do you make of bug #11
taxilian 17:03 I haven't been able to install IE 9 on any of my dev machines yet
so I don't know
I'm hoping there'll be something inside the activex stuff that we can do
but it's definitely baffling
Jarom is reliable, and he did the testing just today
physicsrob 17:03 yeah -- I don't have a dev box with IE9 either
I just found "confirmation"
in the form of a google plugin that had this issue
taxilian 17:03 huh
physicsrob 17:03 and a much better work around
taxilian 17:03 could you add that link to the issue?
FireBreathBot 17:03 FIREBREATH-11: Summary: Using a DOCTYPE definition in the HTML page breaks IE 9
FIREBREATH-11: Assigned To: richard
FIREBREATH-11: Priority: Major
FIREBREATH-11: Status: Open
physicsrob 17:03
looks like you can use a doctype if you use <meta http-equiv="X-UA-Compatible" content="IE=8" /> in the head
taxilian 17:03 hmm
FireBreathBot 17:03 JIRA issue issue commented by physicsrob "I haven't had an opportunity to test, but I found a plugin for an unrelated google project that d..."
taxilian 17:03 thanks, rob
physicsrob 17:03 np
that's cool
this makes sense
with no <!doctype> IE9 assumes its rendering an old page
so it defaults to the old behavior
sabotaged|wk 17:03 that's good, after updating to the latest 1.4 i dont see the deadlock anymore
taxilian 17:03 the question is, what is the new behavior?
sabotaged|wk: that's good; I will be releasing 1.4.2 soon, I think
I just fixed a majorish memory leak
I gotta run, though
see you all later
sabotaged|wk 17:03 though i'm seeing InvalidateWindow having no effect in IE9
taxilian 17:03 I'll read the logs when I get back
sabotaged|wk 17:03 later
sabotaged|wk 18:03 anyone know specifically how to draw offscreen with a HWND? special CreateWindow flags or something?
physicsrob 18:03 not sure
FireBreathBot 18:03 Commit 16643d6 on master by Richard Bateman: "fixed typo in memory leak test code"
taxilian 20:03 and the memory leak check returns clean on windows