IRC Log Viewer » #firebreath » 2010-10-04

IRC Nick Time (GMT-7) Message
Lta 09:10 taxilian_away, Hello. I've found the source of the problem regarding my X11/vlc firebreath drawing issue
This was actually pretty simple, I'll need to check some stuff before actually sending you a patch of whatever (the fix is one line long, i don't think a patch is necessary :))
firebreath was returning the xid of the xembed window instead of the specially created canvas
actually i don't know which behavior is better. It kind of depends of the intended use
taxilian 09:10 Lta: we may want to support both in some way
on Mac we have something like 4 different drawing models and 2 event models we support; in Linux I suspect we may need something similar
there are at least 3, it seems; raw X11, XEmbed, and QT
woops. meant to close another chat window, hit "q" instead of "w" :-P...
Lta 09:10 raw x11 seems to be a bad idea because chromium (and maybe other doesn't support it)
taxilian 09:10 fair enough
I have never done linux gui dev, so I'm not the best person to make the decision =]
Lta 09:10 and actually after rereading the code you already allows to do so, getWindow and getBrowserWindow now allows to do so
hum, i doesn't know how to talk anymore
taxilian 09:10 lol. I figured you'd clarify yourself when ready ;-)
Lta 09:10 if you return the canvas xid via getWindow, and the xembed widget id when using getBrowserWindow
you support both xembed (which allows to use qt) and raw x11
taxilian 09:10 … really? if anything, I would have expected the other way around. getBrowserWindow should be the firefox window
Lta 09:10 this is the case
i don't know how to say this clearly
taxilian 09:10 meh, tell you what… just tell me how to fix it ;-)
Lta 09:10 the xembed widget is the firefox window
taxilian 09:10 ahh
Lta 09:10 but, using xembed directly will break firebreath event handling i think
taxilian 09:10 I do know that several people have mentioned some siginficant problem with the event handling
'course, I don't actually know how to fix it, so it didn't help
Lta 09:10 and there is a chance that the GtkDrawingArea setup will mess all up, but i'm not an x11 expert and you'll have to wait for somebody more competent
taxilian 09:10 so I'm going to make a change so that the PluginCore object is a shared_ptr
I don't recommend ever using it as such directly
but then we can use a weak_ptr to it in the JSAPI object
and lock it when needful
kylehuff, amackera, nirvdrum: anyone have time to help me do some minor revamping of the documentation this morning?
nirvdrum 09:10 Sorry dude. Pair programming at the moment.
taxilian 09:10 just thought I'd ask =]
kylehuff 09:10 taxilian: it is a monday - but if I have a list of things that need to be done, I can try and tackle some of the items.. might take me all day though being as I have a few minutes here and there..
taxilian 09:10 ok; ask much as anything, I'm hoping for someone to talk it through with me for a few minutes and help me decide what we want
I'm thinking I want to put together a page as a "Building your FireBreath Plugin" home page, similar to the documentation home page currently there
and then off of that page, "Creating your project with fbgen", "Hosting your project outside of the FireBreath tree", "Adding Methods and Properties to your API", "Accessing your plugin object from your API", etc
kylehuff 09:10 by documentation homepage you are speaking of the wiki?
taxilian 09:10 yes
the main page on the wiki
kylehuff 09:10 roger
taxilian 09:10 There is a lot of documentation there, but it's a bit disjointed
trying to figure out how to best fix that
the problem, of course, being that I am a software engineer, not a technical writer =]
kylehuff 09:10 lol.. yeah
kylehuff 09:10 taxilian: sorry, phone keeps ringing... anyway, that sounds good - one suggestion might be to change any reference of "Building FireBreath" to "Building your FireBreath plugin", or something to that affect.. when I first read the docs I was confused by that slightly, thinking I needed to first build firebreath on my system before I could use it.
granted - other people may have more of a clue! lol
taxilian 09:10 no, it's a good suggestion
taxilian 10:10
it's very much a first incomplete draft
but all I have time for right now
and, honestly, patience for
cygmatic 11:10 hi
taxilian 11:10 cygmatic: *now* you show up. I think I about have my template problem figured out finally… :-P
we'll see, I guess =]
cygmatic 11:10 i was just sitting it out :p
taxilian 11:10 lol
smart, really
I would too, if I could =]
working on the "invoke this functor on the main thread" functions
cygmatic 11:10 sounds good
taxilian 11:10 got it working nicely, but then I realized it didn't support synchronous calls with a void return type...
cygmatic 11:10 oops
taxilian 11:10 talk about a pain...
cygmatic 11:10 but you've got it now?
taxilian 11:10 I may still need your help if what I'm trying doesn't work =]
I think so, but I haven't tried compiling yet
so mayb enot
does this work, do you know? template<class Functor, class RT = typename Functor::result_type>
cygmatic 11:10 it should
taxilian 11:10 ok
I should be able to specialize on the return type, then
and I should be find
cygmatic 11:10 note that you can't partially specialize functions
taxilian 11:10 ooh. that could be trickier, then
so this won't work?
template <class Functor>
static void CrossThreadCall::syncCall<Functor, void>(BrowserHostPtr &host, Functor func
cygmatic 11:10 nope
taxilian 11:10 crap
I guess I could make a syncVoidCall function...
but that seems messy
cygmatic 11:10 but you can forward the call
taxilian 11:10 problem is the original function has a "return syncCall…" in it
cygmatic 11:10 so you can choose one of two alternatives: forwarding to a static member function of a class template (which you can partially specialize) or use overloading
taxilian 11:10 how would I do this with overloading?
cygmatic 11:10 you can do "return f();" if f() returns void
taxilian 11:10 oh, really?
okay, that should be workable, then
cygmatic 11:10 overloading in this case with a "is void"/"is non-void" helper type - e.g. mpl::bool_
taxilian 11:10 and whoosh! it all goes over my head
I still don't understand how all the mpl stuff works
it's a little weird, really
I think you must have to speak German to understand it
I only speak English and Russian
cygmatic 11:10 e.g.: return helper(... blah, boost::is_same<void, RetType>);
no, that is the international lingua of template based programming ;)
taxilian 11:10 lol
I hate learning new languages ;-)
cygmatic 11:10 heh, i like it ^^
taxilian 11:10
so how would you specialize that?
syncCall specifically
this is being called from browserhost through a template method there, btw
taxilian 11:10 I guess since this is a static call anyway, I could just create a specialized class to call different methods on the real one
cygmatic 11:10 just a moment ^^
taxilian 11:10 ok =]
cygmatic 12:10
heh, no i won't fix all :)
taxilian 12:10 lol
if that works, it's enough
where does "syncCallHelper" come from?
or is that the one I make?
cygmatic 12:10 oops, the 2 new ones should be named syncCallHelper
taxilian 12:10 oh, I see it
let me play with that and let you know how it goes =]
cygmatic 12:10 alright
i was thinking by the way... i don't see why we couldn't support building FB as a library for those that have to integrate it where it doesn't fit now
they would have to build it for exactly the configuration their plugin needs
and would of course have to update their resources manually
taxilian 12:10 Yeah, I think some things could be moved into a library, anyway
the hardest bit would be the ActiveX stuff
but we could definitely move a lot of it into a library
possibly even have the bulk of it precompiled so you don't have to wait for it to build every time
cygmatic 12:10 and for needed stuff like const char data like mime-types, resources, ... the prep-script could take care of it for those who want convenience while those who want to use FB as a library have to fix/provide that manually
if this "not a lib" is a reason why some people can't use FB, a not-so-convenient alternative might be enough
taxilian 12:10 yeah, I agree
I've been thinking about that a bit lately
I'm guessing 90% of the "plugin specific" libraries could be done as global libs
cygmatic 12:10 i think its only pluginwindow that has to be configured
taxilian 12:10 I don't even remember why pluginwindow needs to be configured?
cygmatic 12:10 different drawing models on mac
taxilian 12:10 FBControl has to be
oh, yeah
COMJavascriptObject has to be as well
cygmatic 12:10 and possibly for no-gui-mode
why those two?
taxilian 12:10 GUIDs
I guess it might be possible to abstract those out, though...
I'd have to look at it
the template tweaks now build, btw =]
still working on a test for them, but it'll be pretty slick, I think
cygmatic 12:10 ah, the guids at compile time
taxilian 12:10 yeah
cygmatic 12:10 hm, but it only passes pointers to the base classes
so it should be possible to make them "extern"
and to be provided by either prep* or manually
taxilian 12:10 yeah, you may be right
this is far, far better than the old way
you want to call something on the main thread? host->MainThreadFunctor(boost::bind(Object::Method, instance, arg1, arg2);
it will execute it on the main thread and return the result
if you don't care about the result, do the same thing with host->ScheduleAsyncFunctor
except you have an extra argument that is a shared_ptr to the object in question so it doesn't go away while you're waiting for it to get called
cygmatic 12:10 sounds good
maybe use a weak pointer instead for async?
and call them a bit different like ScheduleOnMainThread()/ScheduleOnMainThreadAsync() ?
taxilian 12:10 hmm. not a bad idea on either count
so if the shared_ptr goes away, we can just abort the async call
I like it
ScheduleOnMainThread doesn't make sense when it is a synchronous call
I'm also making the PluginCore object get created and immediately placed in a shared_ptr
that way we can have weak_ptr to it on the JSAPI object
cygmatic 12:10 ok, CallOnMainThread()/ScheduleOnMainThread() or something similar?
taxilian 12:10 I can live with that
anyone else want to vote? =]
renamed as you suggest
physicsrob 14:10 hi all
kylehuff 14:10 hello physicsrob
physicsrob 15:10 I had a question I wanted to ask here before I send it off to the entire email list: on internet explorer I keep getting a first chance exception warning
"First-chance exception at 0x7c812afb in iexplore.exe: Microsoft C++ exception: FB::bad_variant_cast at memory location 0x0013d854.."
it doesn't show up on any other browser
is this something I should be worried about?
kylehuff 15:10 sorry mate, I have no idea.. I was just saying hello.. lol
physicsrob 15:10 hi taxilian -- do you have any thoughts on my above question?
taxilian 15:10 physicsrob: sorry, I've been out for a few hours. let me read through it
oh, okay
yeah, that's nothing to worry about
that just means it's an exception that was thrown
and handled correctly
physicsrob 15:10 really... that's bizarre that it spits out an error for that
taxilian 15:10 most likely
you can disable that in visual studio
physicsrob 15:10 okay... cool
taxilian 15:10 if you want you can tell it to break when that exception is thrown
so that you can see exactly where the issue is
physicsrob 15:10 yeah I did that -- it wasn't very useful. I don't understand all this COM stuff that goes on behind the scene in firebreath :)
*few* -- that's a relief.. I *finally* got my plugin working in IE (my last platform). time to celebrate
taxilian 15:10 hehe. aren't you glad you have firebreath so you dno't *have* to understand it? =]
I wish I didn't
it makes my head hurt
if you have any questions, though, let me know
physicsrob 15:10 yes -- I *am* glad
taxilian 15:10 I'll try to explain it
physicsrob 15:10 I used to have to do similar stuff with connecting to a webcam via directshow
nasty stuff
now I have a library that abstracts that nastyness away (just like firebreath does for the plugin aspects)
it's nice to be insulated from it
taxilian 15:10 yeah
I've played with directshow before
but it was all in c#
physicsrob 15:10 the microsoft paradigms are just sooo different than anything else I've ever dealt with
taxilian 15:10 that they are
after studying COM a bit I understand why
but it's still a pain
physicsrob 15:10 so I'm curious -- is the plugin project you started firebreath for public information,?
I'm really curious about what plugins are being developed with firebreath... there are clearly way more plugins being developed than listed on the wiki
taxilian 15:10 hehe
actually, it was never written
amackera has a plugin that is live that uses firebreath
nirvdrum uses it for
there are a couple of examples linked to from the wiki
and other than that there are lots of people using it (aparently) that aren't talking much
physicsrob 15:10 agreed
taxilian 15:10 though I'm in the process of porting a plugin to it for Facebook
physicsrob 15:10 I'm about to release my plugin live to customers in roughly a week
taxilian 15:10 if you're willing to advertise that you use us, it would be greatly appreciated =]
but obviously it's up to you
physicsrob 15:10 I most likely need to discuss it with business partners
but I think it's likely
taxilian 15:10 the thing is, it benefits everyone to have more people using firebreath
because then any security concerns, crashes, instabilities, etc will get found faster
and reported so we can fix them =]
physicsrob 15:10 oh -- that reminds me
I just found a bug
taxilian 15:10 oooh
physicsrob 15:10 I'll submit a report
taxilian 15:10 do tell
even better
physicsrob 15:10 PluginWindowWin WM_PAINT
taxilian 15:10 but I should mention
physicsrob 15:10 the fix you checked in
taxilian 15:10 that my software doesn't have bugs
physicsrob 15:10 was to add a break
taxilian 15:10 it just occasionally generates random features
physicsrob 15:10 haha
you have break at the end of WM_PAINT in PluginWindowWin
taxilian 15:10 this is on stable?
physicsrob 15:10 if I handle the RefreshEvent and return true, no other handling of the event should take place
taxilian 15:10 *looking*
physicsrob 15:10 but since it's just a break instead of a return true
taxilian 15:10 hmm. you're right
it should be a return true;
physicsrob 15:10 I don't know if there are any consequences
but still...
taxilian 15:10 there actually could be
ATL may decide to handle it
and clobber your drawing
physicsrob 15:10 that's right
taxilian 15:10 cygmatic: that was your fix, are you available to update it?
physicsrob 15:10 I was having wierd behavior that went away when I fixed it
taxilian 15:10 that would make sense
probably only on IE?
well, no
physicsrob 15:10 When the plugin started up the plugin displayed "ATL 10.00"
taxilian 15:10 it would be anywhere
physicsrob 15:10 actually yah -- it was IE and not firefox
I think
taxilian 15:10 that's what would happen =] that means you're using Visual Studio 2010
physicsrob 15:10 but that might have been related to a different IE bug I was having that I have since fixed
taxilian 15:10 you should *never* see ATL 10.00
but if that falls through to CustomWinProc, then you will
physicsrob 15:10 agreed
taxilian 15:10 hmm. I'm not in a state to easily fix that; do you want commit access and you can do it? =]
physicsrob 15:10 I would say yes -- but I'm not experience with mercurial. I don't want to screw anything up
if it were git... :)
taxilian 15:10 lol. it's not too hard; the main thing you need to remember is when you commit if you only want to commit certain files, specify them with the commit command =]
unlike git, the default is to commit all changes
physicsrob 15:10 okay
taxilian 15:10 [email protected]?
physicsrob 15:10 yep
taxilian 15:10 ok, you have access
please be careful with it =]
also, the worst possible thing you could do (which is sometimes worse than others) is to push dev to stable or vise versa
so just don't do that -=]
otherwise it's pretty much like git
hg pull && hg update
hg commit <files> -m "message"
hg push <https url>
taxilian 15:10 debugging multithreaded fav
physicsrob 15:10 okay... cool -- I'll be careful
taxilian 16:10 I appreciate that =] I can probably fix it if you aren't, but it's a pain
taxilian 16:10 yay! Synchronous calls on the main thread are working
so amackera: remember the pain I put you through the other day when you used that async call thing with the void*?
amackera 16:10 yea
taxilian 16:10 there is a lots easier way now =]
in dev
just pushed it
amackera 16:10 nice!
taxilian 16:10 it's pretty cool
you were trying to call NPN_InvalidateRect?
amackera 16:10 yep
taxilian 16:10 ScheduleOnMainThread(shared_ptr(), boost::bind(&NpapiBrowserHost::InvalidateRect, this))
amackera 16:10 cool!
taxilian 16:10 fi you want it synchronous, you don't need to pass a shared_ptr and you use CallOnMainThread
all JSObject calls should do that automatically, though I'm a little uncertain about how much I like that since it is a bit of a performance issue
amackera 16:10 i have windowless plugins working in windows, but no luck with getting them to draw OpenGL
i am unable to set up a context
taxilian 16:10 hmm
I wonder how Flash and Silverlight do it? I guess they probably don't use opengl
might not even do hardware accelerated
amackera 16:10 i'm not enitrely sure what they use
taxilian 16:10 well, having windowless support in FireBreath is a good thing, even without OpenGL
but it would sure be nice to find a way :-/
amackera 16:10 it's strange, i have an HDC from the browser, and i use the same code for windowed plugins, but it fails on the wglMakeCurrent() call with an invalid handle error
taxilian 16:10 I wonder if they are already doing hardware acceleration in the browser?
and it's conflicting?
amackera 16:10 hmm
multiple openGL contexts cannot draw to the same device context, you're thinking?
taxilian 16:10 yeah
or possibly opengl can't draw to something directx draws to
taxilian 16:10 I've been meaning to write something to allow cross-thread synchronous calls since we started the project
good to have it done
amackera 17:10 nice :)
amackera 17:10 do you know of any mailing lists i could post to to get help with my OGL problem?
is there a mozilla NPAPI list that is read by anybody?
taxilian 17:10 kinda
amackera 17:10 I suppose we could do the same thing we do with CoreGraphics in Mac.. just render to an FBO and draw the pixel buffer with whatever windows uses for drawing
amackera 18:10 the error i'm getting from wglMakeCurrent is that it doesn't support GDI clipping
making me think that the browser uses GDI clipping on the HDC before passing it to us
which makes sense, since the plugin is just supposed to draw to its clipping rect
but it also means its impossible to get an OGL context from the HDC that gets passed to us
(ie offscreen rendering)
taxilian 18:10 that would make sense
is it possible to create a window that participates in the Z-order of the page?
I mean, all components on the page are windows, no?
amackera 18:10 it's funny that you say that because i wrote a little mock webpage that used CSS fixed positioning
and the windowed plugin actually did respect DOM ordering (ffox 3.6, I think.. it's been a while)
but on our page that uses some other CSS hackery it doesn't work
so i'm kind of confused about the whole thing
amackera 19:10 i think offscreen rendering is the only option for OGL in windowless mode :(
i looked at the o3d code, they don't support windowless mode
i wonder what flash does...!
i suppose we could get a new HDC from the browser's HWND
that isn't clipped
taxilian 19:10 amackera: think that'd work? we could probably get coordinates to put it in the same place...
but I don't know if you can get it to draw in the z-order just by drawing at the right time or not
amackera 19:10 maybe the clipping of the HDC is what causes it to respect z-ordering, not just the actual drawing order
taxilian 19:10 that is possible; I don't know how it works :-/
amackera 19:10 me neither but i imagine it's possible
taxilian 19:10 I wouldn't think that just clipping would be enough, but then maybe clipping means something more here
amackera 19:10 you can clip regions
so my guess is that it might clip out regions of things that are over-top of the plugin
taxilian 19:10 yeah, but this is more than just region clipping; it's transparency as well
could be, yeah