|IRC Nick||Time (GMT-7)||Message|
Anyone who have experience getting OpenGL to run (crash free!)?
I posted in the forums http://forum.firebreath.org/topic/249/
But no response so fart
|dougma||05:02||what do you mean that NPP_SetWindow is ignored?
it calls plugin->SetWindow
it being NpapiPluginModule::NPP_SetWindow
|dougma||06:02||taxilian: running switcher.html under Chrome i don't see a minor leak (10s of kb), but i have had this assertion firing https://github.com/firebreath/FireBreath/blob/master/src/NpapiCore/NpapiPluginModule_NPP.cpp#L228
the minor leak is constant, the assertion is like 1 in 10 iterations
actually, twice in 70 iterations!
and it seems more easily induced if i switch to another tab
(also, i mean i don't see a major leak, just a minor one)
aha. i am guessing that assertion is due to FBTestPluginAPI::SetTimeout creating a strong pointer to itself.
hmm... commented out the SetTimeout test but still asserting
also SimpleStreamHelper holds a strong pointer to the browser host, that might be it.
trying again with postURL, getURL tests disabled.
50 iterations no probs, that'll be it. i'll make it a weak pointer
removed it altogether
|EvilTengil||06:02||dougma, it's just calling plugin->SetWindow the first time. But the other times, when the client rect has changed but the HWND is the same, it doesn't send any signal to the plugin.
And it seems like that when the plugin clients visible rect has changed, the DC is invalidated and the following ogl calls crashes the plugin!
|dougma||06:02||client rect changing is a different codepath|
|EvilTengil||06:02||But that event seems to sent to the plugin by NpApi by calling NPP_SetWindow, no?|
|dougma||06:02||oh ok i was thinking activex|
|EvilTengil||06:02||in activex it's working :)
its's in chrome it crashes
|dougma||06:02||cause activex is good (compared to npapi)|
|EvilTengil||06:02||and i put a breakpoint in the NPP_SetWindow handler in FireBreath and i get that event exactly before everything crashes, and the following ogl calls crashes the plugin!
As soon as any part of the plugin is scrolled outside the viewbow/scrollbox or whatever it's called of the browser that event is sent and the ogl rendering crashes!
|dougma||06:02||i just wouldn't trust using a DC cross-thread|
|EvilTengil||06:02||hmm im using it only in one thread|
|dougma||06:02||oh yes... i reread your forum post
it's late, i've had a beer. :)
|EvilTengil||06:02||but its the ogl thread
could it be a problem that im actually grabbing the DC from another thread than the thread that is sending the Attached event?
How threadsafe is win32..?
|dougma||07:02||the threa where the DC is created is where you should use it
wellll... that's not quite what it says here: Note that the handle to the DC can only be used by a single thread at any one time
i mean here: http://msdn.microsoft.com/en-us/library/dd144871(v=vs.85).aspx
so yeah if you're using it on your own opengl thread then i would think you're asking for problems.
but i've only ever done windowless-drawing and never opengl, so...
also remember that chrome is going to extraordinary lengths to run your plugin out-of-process
IE's isolation model is different.
have you had any success with Firefox? firefox is interesting to test these things cause you can turn ipc on and off.
i guess i should
|dougma||07:02||still npapi of course|
|EvilTengil||07:02||its working fine in firerfox!
only chrome then.. gag
|dougma||07:02||ipc on (the default) or off ?|
i havent changed any settings
|dougma||07:02||probably the default then. :)
that's good news. boo chrome!
|EvilTengil||07:02||it seems really hard to write browser plugins that just work. different browsers, versions, operating systems.. wondering if it's really worth it|
|dougma||07:02||it's a nightmare but i get paid to do it. :)|
|EvilTengil||07:02||me too but with all this crap i should get paid more haha :P|
|dougma||07:02||i always advise the business no to do it.
but they insist
|EvilTengil||07:02||my project is more of a research project. the reason why we thought it would be good with a browser plugin is that the users should feel it was a bit less intrusive and lighter than installing a standalone application
and instead of having a ugly Qt interface or something it could all be done in the browser (except for the actual video feed im trying to render with ogl)
but as it looks right now i think im gonna implement unaccelerated GDI blitting instead
it should be fast enought to display a 10-30 fps 640x480 webcam feed right..?
|dougma||07:02||yeah... that's not without issues too, but it is pretty fast
yeah it'll do that
|dougma||07:02||have you done windowless plugins before?|
this is my first plugin ever
it was supposed to be done by this other guy who then bailed leaving me with it
|dougma||07:02||ok. yeah so you call 'invalidate' and the browser calls you back to draw.|
|EvilTengil||07:02||i did a small test
but i realized that was not enough
|dougma||07:02||ie will tend to call multiple times to repaint the window in a striped fashion|
|EvilTengil||07:02||because the erase background event it flickers so i think i need to implement my own event handler and discard those erase events
this was just for windowed GDI
|dougma||07:02||yeah, windowless doesn't flicker and interacts with other page elements better|
|EvilTengil||07:02||seems slow? can you invalidate just the region so that not the entire browser window is being repainted=|
|dougma||07:02||it just repaints your plugin
you call the browser-plugin interface to invalidate
|EvilTengil||07:02||is it supported in all browsers?|
|dougma||07:02||yup. and the only option on mac|
i dont really have much gui
i actually just want to blit the images im getting from this kinect library i wrote. so it's just blitting and perhaps writing some text like "Please wait..." and error messages that has to be drawn. would probably be just as easy to just implement native drawing for every platform than using ogl.
|EvilTengil||07:02||ogl would just be nice because then it would be easy to support drawing the pointcloud live which would be cool|
|dougma||07:02||and use html for the messages|
|EvilTengil||07:02||but that's a feature that would be saved for later nayway
oh thats right... you can draw stuff above windowless things
that would make it much easier to make a nice loading animation :))
|dougma||08:02||taxilian: that leakfinder in fbtestplugin is cool! first time i've used it.
and yeah, leaking like a sieve!
oh maybe.... not the first one is a static. will go through one by one. :/
|dougma||08:02||leakfinder is just picking up all the static instances... i can't see any leaks (running fbtestplugin)|
|taxilian||08:02||dougma: it is possible the problem was in firefox, but I ran FBTestPlugin with the switcher page for about 2 hours and the process was up to 4 gig|
|dougma||08:02||oh, will try ff.|
|taxilian||08:02||I did it again w/out your fix for comparison (quite possible it was already there) and just haven't looked at the results
it's probably down there still running :-P
I put an offer on a house yesterday, so I've been a bit distracted
i'm about to crash
maybe i should do release build too
ff (8.0.1) plugin-container uses way more ram than chrome's!
but not growing
I'll keep playing
|dougma||08:02||the mem leaker keeps growing
visual studio is too slow, i'm off!
|taxilian||09:02||hehe. g'night =]|
|dougma||09:02||oh yeah, i am running with that simple-stream change too...
really off now.
|FireBreathBot||11:02||JIRA issue http://jira.firebreath.org/browse/FIREBREATH-166 issue commented by thesheeep "I have the same error and use Cmake 2.8.3. That shouldn't be too old."|
|FireBreathBot||13:02||JIRA issue http://jira.firebreath.org/browse/FIREBREATH-166 issue commented by richard "Just try upgrading and verify, please; there was a version of cmake that I had this problem with,..."|
|FireBreathBot||14:02||JIRA issue http://jira.firebreath.org/browse/FIREBREATH-166 issue commented by thesheeep "Okay, I tried with 2.8.7 and the error does indeed not appear there.
JIRA issue http://jira.firebreath.org/browse/FIREBREATH-166 issue comment edited by thesheeep "Okay, I tried with 2.8.7 and the error does indeed not appear there.
|FireBreathBot||14:02||JIRA issue http://jira.firebreath.org/browse/FIREBREATH-166 issue resolved by richard "It seems that the fix is to upgrade to the latest cmake; if that doesn't work, let me know. This ..."|
|ch||17:02||taxilian: might be worth bumping cmake min version to 2.8.7 then?|
|taxilian||17:02||the problem only happens on windows|