IRC Log Viewer » #firebreath » 2012-11-30

IRC Nick Time (GMT-7) Message
jshanab 09:11 Good morning. When i use PluginWindowMac, there is a getWidnowref that returns an opaque pointer to a window. What is that? I am kinda new to mac windowing apis
taxilian 09:11 jshanab: that depends on your drawing model
have you decided on one yet?
jshanab 10:11 I thought cocoa+coreAnimation but the wiki seems to point to cocoa + CoreGraphics
I was looking at my GLFW lib and it uses NSwindow containing a NSView with a CG backing store
taxilian 10:11 pretty certain you can't do opengl with a CGContextRef
jshanab 10:11 I am a little lost in apple's alphebet soup. The BasicMedaiPlayer use CGLContext.. as variable names and types, But I see it does CoreAnimation on the layer. But the wiki says that won't work on FireFox. Appl sasy everything is on opengl and coreanimation is on coregraphics. i am so confused
taxilian 10:11 ahh
so you need to understand that there is CoreAnimation and InvalidatingCoreAnimation
InvalidatingCoreAnimation is just like CoreAnimation except you have to call InvalidateWindow after you draw to tell the brower to paint
and that works on Firefox and Chrome
jshanab 10:11 ...but not safari?
jshanab 10:11 The library uses NSOpenGLcontext. "LowLevel opengl context" I do not see any reference to CoreAnimation or CoreGraphics, at least directly
But i see Quartz and that is CoreGraphics. right?
taxilian 11:11 Safari uses CoreAnimation
not neccesarily
CoreGraphics is part of Quartz
remember: you *do not get* a NSWindow or NSView
jshanab 11:11 yeah i was thinking I would create a token NSView and NSWindow as a contianer. But i have not figured out yet what I get from the plug, what are my optioins? ie what function has meaning when. is GetWindowRef() valid and only returning a certain value depending on my backend choice? I can't seem to match up what FB is doing with what GLFW is expecting
taxilian 11:11 GetWindowRef is not used in CoreGraphics
jshanab 11:11 I am getting a feel for what is not used but still am unclear as what to use when and what gets returned. Is there such info on the wiki?
taxilian 11:11 it's pretty s
pretty simple
you get a CGContextRef with every CoreGraphicsDraw event
that's it
jshanab 11:11 ok, so that is the coreGraphics choice. Is getWindowRef used in CoreAnimation?
taxilian 11:11 I dont' think so, actually
go look at PluginWindowMacCA
you get a different subclass of PluginWindowMac for each
jshanab 13:11 npapi plugins are passed the NSWindow pointer in a CG + cocoa setup
NP_CGContext.window is a NPNSWindow which is NSWindow*
taxilian 13:11 uh, no
NPAPI plugins?
CoreGraphics + Cocoa?
unless someone completely changed the entire infrastructure recently, that is not the case
where are you seeing this?
jshanab 13:11 In mozilla docs. let me see if I can find it on thi machine so i can paste the urls
and webkit stuff
taxilian 13:11
jshanab 13:11
Well maybe someone posted bad info and I found it.
taxilian 13:11 note that this is 3 years old, first
but let me see if I can find where you're talking about
huh. yeah, this is pretty much inaccurate
jshanab 13:11 The docs said something about the NPAPI CoreGraphics doc was written to assume carbon
taxilian 13:11 this might have been the original plan; it's even psosible that Safari does this
but Chrome and Firefox don't; if you set some breakpoints you'll see that the NPWindow.window is NULL in cocoa
jshanab 13:11 so it fills in the NP_CGContext.window record differently if it is cocoa vs carbon. That would be nice
taxilian 13:11
have you read that?
if not, you should
jshanab 13:11 Breakpoints, ROTFL that will be a few hours. I did read that a week ago, i will have another look.
"wish you hadn't asked'
taxilian 13:11 okay, logging then
jshanab 13:11 I have however seen many blogs and stuff that disagrre with his CoreGraphics+Cocoa statement about "don't care about hardware acceleration or opengl."
taxilian 13:11 well, one thing to note is that it used to be possible to do opengl with CoreGraphics and Carbon
by exploiting an undocumented implementation detail that allowed access to the NSWindow
Andrew____ 14:11 Good day to everyone
Could anyone help me with something ?
jshanab 14:11 just ask!
jshanab 14:11 I have a question about events in the mac plugin case. Do events go to the CALayer (assuming CA) or to FB
taxilian 15:11 jshanab: events go to FB
jshanab 15:11 excellent. I think i have figured out a few ways to achive what I want. One way, as you suggested, is to teach glfw about CALayers. That way I would end up with one api for drawing. On windows and linux it is a child window, on mac it is a child(sublayer) layer. Question is :: Is there really a different animal and MAc is just forceing me to see it. Should I add window and windowless on... and linux and just windowless on mac!?
taxilian 15:11 not sure I follow the question
jshanab 15:11 GLFW is a platform abstraction for GL. I does so by being the creator of the main window. So to use it in a plugin I added a CreateWindowFrom in which the first argument is the window from the browser
Obviously this does not work for mac
taxilian 15:11 hmm. well, unless you give it the CALayer, which you could treat as the window in this case
jshanab 15:11 So should I be adding two functions to the library. CreateWindowFrom(window* ... and CreateDrawableFrom(drawable*,...
taxilian 15:11 hmm. I don't know =]
if it were possible to do opengl w/ a windowless plugin in windows that would be awesome
jshanab 15:11 Giving it the layewr is my first thought, but I realize maybe i am missing the windowless plugin option for windows and linux
taxilian 15:11 I'm not sure it is, though
jshanab 15:11 I did find a section where you can create an Hdc or a WGL.hDc that is a opengl device context
Not sure how accurate that one is
taxilian 15:11 what do you mean?
jshanab 15:11 Well my google foo history of finding impossible things...
taxilian 15:11 no, I mean did you see something w/ NPAPI doing that?
I think there might be a proposal for that that hasn't been accepted; I know there is a directx drawing method in FireFox (recent versions) that nobody else has implemented
jshanab 16:11 I just talked it out with my office buddy and it seems like the two calls one for window and one for drawable would be best.. that way I can do child opengl windows on desktop apps cross platform and just not use the window version on plugins. (Thinking from the general purposeness of the glfw library and not just plugin foicus)
taxilian 16:11 makes sense
jshanab 16:11 Well, i know what I am doing this weekend :-)