IRC Log Viewer » #firebreath » 2011-02-04

IRC Nick Time (GMT-7) Message
jshanab_wcw 07:02 I am jumping from 1.2 to 1.4 on an existig project and am trying to figure out what I need to change. i figure there are changes to the generated files to match the new version and since I am not regenerating, i will have to make changes. (wow, that would be a cool prep feature). The first one however is an error thrown trying to compile variant.cpp, which came in the new 1.4 right?
iaincollins 07:02 jshanab_wcw: for me, I found it easier to create a new blank project with the same base information and add my classes and properties to the new skeleton project (not that there were many differences, just didn't want to miss something subtle)
jshanab_wcw 07:02 I am diffing now against a project I created...LOL, i called it Skeleton :-) The part that is odd is that the file not compiling is not pert of the project, it is part of the firebreath
taxilian 07:02 jshanab_wcw: yes, if you are getting an error in variant then you're trying to use a data type that isn't valid
figure out which datatype it is
and you've found your problem
most likely you're trying to use a JSObject instead of JSObjectPtr
see version history for a list of breaking changes
pq_H 08:02 hello
got some question about installing plugin
is there a way to make a setup for all user instead of current one only?
jshanab_wcw 08:02 Thanks. i am reading the version history, but i was not sure where that directed me in my code as the compile errors were in the FireBreath directory and not my project. But I am REdoing everything on the update because of last nights issues with gethub, i may have missed something in all my copying around
jshanab_wcw 08:02 I have a redefinition error on the int8_t type because there is a stdint in a header I include and a fb_stdint.h :-( both are headers that don't belong to me. ( i thought include guards took care of this kind of issue). Is fb_stdint.h new?
jshanab_wcw 09:02 How do i handle this issue. pragma once is not an include guard, it uses the whole path+filename and since the fb_stdint.h and the one deep in the avcodec includes has the name stdint.h, it gets included twice. this breaks the build because the typedefs try to run twice. looks like I would have to change the headers in either FireBreath or Libavcodec :-(
taxilian 09:02 pq_H: yes, there is a setting in PluginConfig.cmake
iaincollins 09:02 oh really? that's cool
taxilian 09:02 jshanab_wcw: include guard should cover that; not sure why it isn't. yes, fb_stdint.h is new
pq_H: if you look in your PluginConfig.cmake file (assuming you're using 1.4) you'll see: # If you want to register per-machine on Windows, uncomment this line
#set (FB_ATLREG_MACHINEWIDE 1)
jshanab_wcw 09:02 They don't use include guards, they use pragma, which generates a key off the filename and I hear the path. Since the filename is different, it considers them differnt and tries to include them both. I am not sure about the path part, but I generally replace prama with include guards when I can.
taxilian 09:02 they should be using an include guard that checks to see if the stdint stuff is already defined
if they aren't, you'll probably need to add it
jshanab_wcw 09:02 taxilian. let me try renaming it
taxilian 09:02 sure, but I'd be shocked if it helped
jshanab_wcw 09:02 these includes are identical. but pragma just doesn't work the same as a real include guard. Suppose to be faster :-)
well, not identical...
I have a deadline and this update to 1.4 is killing me, can I do without fb_stdint.h?
Or do I add your guard to the other library so it sees it as already loaded?
Ah ha! both do have guards, but they have different names.
zmichl 09:02 hi
i have question about FB events
when I generate plugin by fbgen.py and open FBControl.htm, everything is ok
but when I change "pluginLoaded" in FBControl.htm to another name that doesn't exist, then plugin crash
pq_H 09:02 taxilian: thanks, reading just now
zmichl 09:02 firefox-bin: /home/zmichl/ffdnssec/dnssec-plugin/plugin/FireBreath/src/3rdParty/boost/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr<T>::operator->() const [with T = FB::JSObject]: Assertion `px != 0' failed.
Aborted
pq_H 09:02 taxilian: though I'm using 1.3 as now. Will that work on 1.3 too?
taxilian 09:02 no
it's new in 1.4
pq_H 09:02 hate that
taxilian 09:02 zmichl: what version are you on?
pq_H: 1.4 will be out before you release anything; it's pretty close to RC anyway
just use 1.4
zmichl 09:02 taxilian: Date: Wed Jan 5 15:25:17 2011 -0700
taxilian 09:02 I think tha'ts a bug we fixed already
try updating
if updating doesn't fix it, please file an issue
zmichl 09:02 taxilian: I use it becase I had some issues with newer ones
taxilian 09:02 what issues?
if you have issues with the newer ones, don't use the old ones… tell me what the issues are so I can fix them =]
zmichl 09:02 some compilation issues as far as I remember
taxilian 09:02 well, they should be fixed now
as far as I know there are no major blocking issues
just the chrome issue and anything reported
so if there are things I don't know, please report them =]
I still have the flu and picked up an ear infection besides today, so I'm headed to the dr
but I'm more concious today, so I can do some minor fixes if need be later this afternoon
zmichl 09:02 i didn't have time to play with it, I needed to compile my plugin :)
i'll try the newest commit next week ;)
thanks
taxilian 09:02 =] well, that fix should be in there. so you can either fix it yourself (find that line and add a check for validity before calling it) or update =]
zmichl 09:02 ok, I need to go, bye!
taxilian 09:02 good luck
bbl, headed to the doctor
jshanab_wcw 09:02 Anyone have the issue where it cannot find win_common.h because np_winmain.cpp has the "include Win/win_common.h" even thought win_common.h is in src/config?
amackera 09:02 I believe that "Win/win_common.h" should be just "win_common.h"
that's a breaking change in 1.4
There are a few other breaking changes for moved files
http://www.firebreath.org/display/documentation/Version+History
see the "Files Moved" section
jshanab_wcw 09:02 oh, so np_winmain.cpp was generated, duh.. thanks
amackera 09:02 np_winmain.cpp was probably generated by fbgen.py, yeah
jshanab_wcw 09:02 I seem to be getting around my stdint.h problem by modifiny the header guards in the avcodec includes, but if someone has a more elegant solution i would like to here it. seem to becuse it hasn't built and ran yet since the upgrade...
jshanab_wcw 10:02 FYI Plugin built and ran. I modified the include guard in the avcodec's stdint.h
neilg_ 11:02 Hey all!
Good news, I'm back on working with Firebreath again. This time on the mac!
nitrogenycs 11:02 woooo
taxilian 12:02 jshanab_wcw: you can also just remove np_winmain.cpp and dllmain.cpp from your project as of 1.4
they are optional
neilg_: awesome =]
neilg_ 12:02 Are there any good docs or example on rendering using Firebreath/NPAPI on OSX? I figure I can read up over the weekend so I'm not a complete n00b. :)
taxilian 12:02 not that I'm aware of
neilg_ 12:02 Oh dear god, I feel dirty for using l33t speak. And again! Ugh. lol
taxilian 12:02 lol
we all have our weeknesses
neilg_ 12:02 I guess I'll have to figure it out by trial and error then. It sounds a lot more involved that the Windows method
taxilian 12:02 it is
neilg_ 12:02 I've learned more about OSX internals and dyld than I ever wanted to in the last couple of months... lol
fireplug 17:02 Hi, I have build a firebreath plugin on mac and it works wonderful. however if i try to access and opengl functions. it is crashing.
I am calling glReadPixels(0,0,1,1,GL_RGB,GL_UNSIGNED_BYTE, pix) and the browser crashes here.
taxilian 17:02 hmm. amackera might be a good person to help you there
I'm not an ogl guy
the drawing model you use is going to make a big difference, though
fireplug 17:02 any pointers to debug this. can we call opengl/glut apis from browser
taxilian 17:02 and you'll really want to create another thread to do all ogl stuff on
it's tricky
fireplug 17:02 yes i created another thread. that part is ok
taxilian 17:02 have you read up on drawing models?
do you know what browsers you want to support?
fireplug 17:02 firefox/safari on mac
i am testing on firefox now
taxilian 17:02 have you read this page yet? https://github.com/sitaramc/gitolite/blob/pu/doc/gitolite.conf.mkd#_advanced_access_control
fireplug 17:02 no. i have not read this page.
taxilian 17:02 read up =] drawing on mac is tricky because there are different event models and different drawing models depending on the browser
fireplug 17:02 i will read now. i am trying to get pixel value (RGB) from the above mentioned api
taxilian 17:02 some of those do and some don't allow you to access AGL
fireplug 17:02 i dont want to draw anything, just capture pixels from the screen
taxilian 17:02 doesn't matter; you're still interacting with the drawing engine
amackera 17:02 i'm here now
one sec to read
fireplug 17:02 ok
amackera 18:02 ok
so it's crashing on glReadPixels?
have you initialized OGL?
fireplug 18:02 yes, it is crashing on glReadPixels
amackera 18:02 have you allocated memory for pix?
fireplug 18:02 yes i have allocated memory
amackera 18:02 hmm
fireplug 18:02 but have not initialized any other OGL
amackera 18:02 you will need to establish an opengl context
fireplug 18:02 initialize OGL? could you please tell me what all needs to be done
amackera 18:02 sure
hmm
it's a little complicated, what exactly are you trying to do?
fireplug 18:02 ok. i need to get RGB values of all pixels on the screen
amackera 18:02 all pixels being displayed on the screen?
fireplug 18:02 yes
amackera 18:02 that's not what glReadPixels does
glReadPixels will give you the pixels in the rendering context
fireplug 18:02 hmm
amackera 18:02 so
fireplug 18:02 can that context be the entire screen or part of the screen
amackera 18:02 if you render into a rendering context, you can read the pixels out again and see what you've rendered
fireplug 18:02 ok
amackera 18:02 the context can be fullscreen, but i suspect that might not be what you want to do
you can't get pixel data from opengl about pixels that you have not drawn
fireplug 18:02 oh ok.
amackera 18:02 so, for instance, you can't take a screenshot of the desktop from opengl
fireplug 18:02 ok
hmmm
amackera 18:02 you can do that through other means though, i image
imagine*
Carbon probably has a screenshot API
fireplug 18:02 ok. do you have the API reference handy
amackera 18:02 let me see if i can dig something up
fireplug 18:02 thanks
amackera 18:02 It looks like CGWindow has something you can use
fireplug 18:02 let me take a look at it
amackera 18:02 http://developer.apple.com/library/mac/#samplecode/SonOfGrab/Introduction/Intro.html#//apple_ref/doc/uid/DTS10004490-Intro-DontLinkElementID_2
"Son of Grab"
sample code that should do it
I should also say that I may be wrong about OpenGL's ability to capture screenshots
It might be worth looking into
I probably won't be able to help much though
amackera 18:02 man the bloody OGL windowless rendering code breaks mysteriously on some computers :(
taxilian 18:02 yeah; aren't plugins fun?
amackera 18:02 taxilian: Can I get your opinion on something quickly?
taxilian 18:02 I'm good at quick opinions
amackera 18:02 haha
I am trying to figure out how to handle mouse events in my plugin
the trouble is that each mouse move handler is likely to call back into the plugin to change some state of some objects
not a big deal on reasonably new computers
taxilian 18:02 okay
amackera 18:02 but older hardware finds a lag between mouse movements, and javascript's ability to keep up with them
that was badly worded
i mean: you move you mouse, there's a circle that follows your mouse around
old hardware: circle lags behind mouse
Do you know of any common strategies or design patterns that address this?
I'm thinking of limiting the rate of mouse move callbacks to JS
taxilian 19:02 well, there are two approaches you can take
that's the first, probably the easiest
amackera 19:02 right
taxilian 19:02 the second would be to see if you can identify the main bottleneck on the events and see if there is a way to optimize the speed
amackera 19:02 alright
that's pretty much what I had in mind also
thanks :)
taxilian 19:02 since you're on the main thread it shouldn't be cross-threading issues that are causing you slowdown