|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|
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
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
you get a CGContextRef with every CoreGraphicsDraw event
|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*
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
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|
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||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...
...windows 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)|
|jshanab||16:11||Well, i know what I am doing this weekend :-)|