IRC Log Viewer » #firebreath » 2013-01-19

IRC Nick Time (GMT-7) Message
Grimshaw 15:01 Hello! anyone around to ask a few questions? :)
I've debugged my firebreath plugin for countless hours
and i cant seem to figure whats wrong
it works fine the browsers, even with multiple instances
everything seems fine
but in google chrome
it gives me trouble, only sometimes, when i open a ton of instances, it eventually crashes the plugin
there is no shared data between the threads each instance launches so..
in google chrome, when i have a page with 3 instances of the plugin, with a playable opengl little game
it works fine and smoothly, but the crash can be induced for example opening the developer console with CTRL SHIFT J
what could it be that i have like 5 pages times 4 plugin instances running smoothly in parallel threads, all at the same time, but opening the console crashes the plugin.. weird uh?
taxilian: there? :)
taxilian 15:01 I'm kinda here
in and out
attach a debugger, see if you can catch the crash in the debugger
Grimshaw 15:01 oh, nice! didnt talk to you in a while , hope everything is allright :)
taxilian 15:01 things are well
Grimshaw 15:01 its not even a real crash
taxilian 15:01 but I'm doing a ham radio test session right now, and I've been pretty busy =]
Grimshaw 15:01 its a silent stoped to work
i really have no idea what to do.. what does the developer console have to do with the plugin? :/
taxilian: actually, when i try to open the console in chrome, it actually freezes a bit until a no response error comes out
taxilian 15:01 it might be a chrome bug :-?
no idea
Grimshaw 15:01 this is a wild one
i guess ill just ignore this part
and work as is.. sucks to be glitchy, but i cant really find a solution like this.. :/
Grimshaw 16:01 hey taxilian
sorry, electrical failure
i ve made progress on the chrome bug, i am now aware its not because of the developer console
its whenever i scroll the page
for some reason, sliding up and down in the page causes graphical glitches and crashes in chrome
but works perfectly in firefox..
taxilian 16:01 interesting
Grimshaw 16:01 it is? :)
its completely strange
i only found it out when i added one more instance to the page, so the scroll became available
it loads fine and stays alive, but as soon as a scroll operation happens, it explodes
IE and Firefox work fine even in the scrolling
https://groups.google.com/forum/?fromgroups=#!topic/firebreath-dev/RMUxso6G1eo
this guy seems to have a similar or equal problem
taxilian 16:01 dunno :-/
Grimshaw 16:01 they seem to think its related to the opengl context
im experimenting..
Grimshaw 17:01 i cant solve it
turns out noone did so far
even the sample of OpenGL suffers from the problem it seems
in chrome, when the scroll changes and so on, the plugin window is changed somehow, maybe its handle or something like that
and then my code is using an invalid window and therefore crashes
this is all i could conclude
someone tracked this to a SetWindow call from the NPAPI
but i have no idea how to handle this change and prevent a crash
NPError NpapiPlugin::SetWindow(NPWindow* window) { return NPERR_NO_ERROR; }
in this function, apparently it does nothing, and it should somehow trigger an event so we can re-get the handle or something
can this be done taxilian ?
taxilian 17:01 back for a moment
reading
that function is overloaded in NpapiPluginWin
Grimshaw 17:01 i just want to know how to get to the corresponding plugin instance from that function
where is that NpapiPluginWin object?
taxilian 17:01 not sure I understand what you're trying to get, but https://github.com/firebreath/FireBreath/blob/master/src/PluginAuto/Win/NpapiPluginWin.h
Grimshaw 17:01 so my plugin contains multiple instances running at the same time
each instance loads its own thread and that thread is responsible to do everything
it absorbs the window handle at the beggining and starts drawing a game
everything works fine it seems, from input to render
however, in chrome, any changes in the browser window that cut the visibility of a plugin window, crash the plugin
jshanab_OSX 17:01 grimshaw. I am coming in really late on this conversation, How did you create the openGL context. I had a similar issue myself. Scroll or resize chrome crashed my plugin
Grimshaw 17:01 from what i ve seen from other people, its because the window handle changes
my opengl context is created implicitly from SFML
i dont do anything about it
just pass the window handle to sfml and it does the rest
the thing is, when chrome resizes, i may need to pass a new window handle
because i dont, it crashes
am i right?
jshanab_OSX 17:01 Grimshaw. Yup CreateWindowFrom
Grimshaw 17:01 what do you mean?
jshanab_OSX 17:01 SFML has show me this error it happened when Chrome updated recently and Firefox in some settings like multiprocess. I found it hard to get feedback and went another route.
Grimshaw 17:01 yeah.. but what route?
i need to solve this, and i think its not too hard, just updating the window handle right?
jshanab_OSX 17:01 Oh, maybe that was SDL. I now use SDL on windowsXP and a customized GLFW on win7.
The child window has a side effect, on slower machines the page scrolls and the window catches up in a few ms. I am displaying a bunch of video cameras.
Grimshaw 17:01 i am using firebreath as a cross platform web player of a game engine
jshanab_OSX 17:01 Near as I can figure from debugging, the problem I had was that windows is resetting the winproc to handle the events. So my event handler calls into a destoyed function and segfaults.
Grimshaw 17:01 and the thing is its seems to work everywhere just fine except in the case of the issue
jshanab_OSX 17:01 Sounds Interesting!
Grimshaw 17:01 hmm
basically
the window still exists
jshanab_OSX 17:01 I had everything working with SFML about 6 monthes ago then suddenly it started to break as the browsers updated. It seemed to be related to browsers adding accelerated graphics or GL access of their own.
Grimshaw 17:01 but something changes in it
tricky issue
im still with some hope of fixing..
it seems like firebreath needs to update to cover this issue, which is a constant now i guess
in the meanwhile
if we could detect whenever that window is updated
and immediately re-load the window from the new handle
it could work..
do you mind to send me an email so we can discuss it after, just in case? because ill leave in a few minutes.. [email protected]
jshanab_OSX 17:01 The handle to the window points into a container of structs that have the window class. This can be created by a copy by the system when it needs to. Something about that is shallow and does not recreate or reconnect some stuff. It is because of opengl and the same thing happens with direct X. You have to recreate certain resources in response to a message and we can't get at that message...
...if the browser does not pass it on to us.
Grimshaw 17:01 the browser must pass it somehow
jshanab_OSX 17:01 I tracked the problem into SFML and could not get help. I think I mentioned I had to move on. (after months)
Grimshaw 17:01 some people have done this sucessfully..
jshanab_OSX 17:01 With SFML 1.x? not 2.x right
Grimshaw 17:01 not with sfml at all i d say
but unity and other plugins work fine
they handle it somehow, i need to figure how..
jshanab_OSX 17:01 There are 10 ways to do it. I used GLFW that I modified to fit in a browser window. Only works on windows and linux, Mac gave me fits.
I want to figure out the issues and submit to GLFW
Grimshaw 17:01 the plugin world is a mess :)
glad firebreath exists to solve at least a part of it..
jshanab_OSX 17:01 And getting worse, the pendulm is swinging again. Thank god for Firebreath! (Well, Thanks Taxilian)
Grimshaw 17:01 hope i can find some kind of windowing system to solve this.. getting tired of it
jshanab_OSX 17:01 Your hitting the accelerated graphics in a browser issue. Not a feature of Firebreath.....yet
Grimshaw 17:01 ill just use firefox and keep development and solve it later
but your conclusions about the issue seem to be very precise
its like we know where it is but cant reach it..
jshanab_OSX 17:01 I was getting really tired of it and I think I decided that the best solution will be to make my own. Quit with all the fancy abstractions and just get a context and do everything in opengl
Grimshaw 17:01 absolutely..
maybe ill just do the same and shut up about it
jshanab_OSX 17:01 I wrote my code to have multiple possible backends. I can switch from DirectX, SFML, SDL, and GLFW with environment variables
Grimshaw 17:01 but you say you have it working fine in chrome, right?
i go now, but ill email you to request some hints later, if you dont mind! :)
thanks a lot jshanab_OSX and taxilian