Re: [Pharo-project] NativeBoost and NBOpenGL on Mac?
I've developed a CocoaUI app, which implements the example you copied. A cocoa window, with a custom NSView, which renders an OpenGL surface. The app also catches events, and notifies it via sockets. My idea is to render within Pharo to a frame buffer object(offscreen rendering), and communicate the redisplay to the cocoa app via sockets (IPC). So we can code all the UI in Smalltalk, using offscreen rendering as a means to draw to a native OS X window. I will continue experimenting with this approach, to assess its performance and usability. Wether IPC via sockets is fast enough, amongst other technical challenges. Yes, i noticed two that the OpenGL info in the Mac, returns 'APPLE SOFTWARE RENDERER 2.1". Surely we can find a way to solve this problem, i will look into Lawson's link. Fernando pd: Enjoy the vacations Igor, have a pint or two. On Wed, Jan 11, 2012 at 1:21 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 10 January 2012 21:28, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
thanks
May be this page is interesting: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Concep...
Igor how is london :) ?
Crowded?
like hell. :) Kiev is more or less same in this regard, so i already having immunity
Yes, i will definitely get back to this issue, once i return from vacation. And now i should stop reading and replying mails and spend time on just resting :)
-- Best regards, Igor Stasenko.
[cross-posting this reply because it certainly seems relevant to both Pharo and Squeak] This seems to me to be roundabout, and will make sure that any Mac version of OpenGL will be far slower than any Windows version. What I'm not understanding is how the current OpenGL libs can render directly on the screen on a Mac, while the Igor's can't. The Croquet OpenGL package appears to be grabbing something from the Baloon3D plugin, I think. Has anyone looked at how THAT tells OpenGL libs to render to the appropriate area on the system window? primCreateRenderer: flags x: x y: y w: w h: h <primitive: 'primitiveCreateRendererFlags' module:'B3DAcceleratorPlugin'> ^nil L On 1/11/12 1:22 AM, Fernando Olivero wrote:
I've developed a CocoaUI app, which implements the example you copied. A cocoa window, with a custom NSView, which renders an OpenGL surface. The app also catches events, and notifies it via sockets.
My idea is to render within Pharo to a frame buffer object(offscreen rendering), and communicate the redisplay to the cocoa app via sockets (IPC).
So we can code all the UI in Smalltalk, using offscreen rendering as a means to draw to a native OS X window.
I will continue experimenting with this approach, to assess its performance and usability. Wether IPC via sockets is fast enough, amongst other technical challenges.
Yes, i noticed two that the OpenGL info in the Mac, returns 'APPLE SOFTWARE RENDERER 2.1". Surely we can find a way to solve this problem, i will look into Lawson's link.
Fernando pd: Enjoy the vacations Igor, have a pint or two.
On Wed, Jan 11, 2012 at 1:21 AM, Igor Stasenko<siguctua@gmail.com> wrote:
On 10 January 2012 21:28, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
thanks
May be this page is interesting: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Concep...
Igor how is london :) ?
Crowded? like hell. :) Kiev is more or less same in this regard, so i already having immunity
Yes, i will definitely get back to this issue, once i return from vacation. And now i should stop reading and replying mails and spend time on just resting :)
-- Best regards, Igor Stasenko.
On Wed, Jan 11, 2012 at 9:34 AM, Lawson English-2 [via Smalltalk] <ml-node+s1294792n4286205h19@n4.nabble.com> wrote:
[cross-posting this reply because it certainly seems relevant to both Pharo and Squeak]
This seems to me to be roundabout, and will make sure that any Mac version of OpenGL will be far slower than any Windows version.
What I'm not understanding is how the current OpenGL libs can render directly on the screen on a Mac, while the Igor's can't. The  Croquet OpenGL package appears to be grabbing something from the Baloon3D plugin, I think. Has anyone looked at how THAT tells OpenGL libs to render to the appropriate area on the system window?
primCreateRenderer: flags x: x y: y w: w h: h <primitive: 'primitiveCreateRendererFlags' module:'B3DAcceleratorPlugin'> Â Â Â ^nil
Sure. Baloon3D is tightly tied to the VM, and is creating the OpenGL rendering context (and attaching it the NSWindow, etc) directly on the C side. Igor's approach is to do this all from the image side, and he just ran into the reality that you need to know the whole render stack on Mac OS X to do this (NSWindow, NSView, and OpenGL context). (I don't mean to put words into Igor's mouth, but his approach is consistent across issues and he has been up front about wanting to move things to the image.) Nick -- View this message in context: http://forum.world.st/NativeBoost-and-NBOpenGL-on-Mac-tp4278813p4286296.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[squeak dev added back in] Even so, i think there's a very windows-centric thing going on that need not exist. might be wrong of course. L On 1/11/12 11:01 AM, ncalexan wrote:
On Wed, Jan 11, 2012 at 9:34 AM, Lawson English-2 [via Smalltalk] <[hidden email] </user/SendEmail.jtp?type=node&node=4286296&i=0>> wrote:
[...]
Sure. Baloon3D is tightly tied to the VM, and is creating the OpenGL rendering context (and attaching it the NSWindow, etc) directly on the C side. Igor's approach is to do this all from the image side, and he just ran into the reality that you need to know the whole render stack on Mac OS X to do this (NSWindow, NSView, and OpenGL context). (I don't mean to put words into Igor's mouth, but his approach is consistent across issues and he has been up front about wanting to move things to the image.)
Nick
------------------------------------------------------------------------ View this message in context: Re: NativeBoost and NBOpenGL on Mac? <http://forum.world.st/NativeBoost-and-NBOpenGL-on-Mac-tp4278813p4286296.html> Sent from the Pharo Smalltalk mailing list archive <http://forum.world.st/Pharo-Smalltalk-f1294837.html> at Nabble.com.
On 11.01.2012, at 18:34, Lawson English wrote:
[cross-posting this reply because it certainly seems relevant to both Pharo and Squeak]
This seems to me to be roundabout, and will make sure that any Mac version of OpenGL will be far slower than any Windows version.
What I'm not understanding is how the current OpenGL libs can render directly on the screen on a Mac, while the Igor's can't. The Croquet OpenGL package appears to be grabbing something from the Baloon3D plugin, I think. Has anyone looked at how THAT tells OpenGL libs to render to the appropriate area on the system window?
primCreateRenderer: flags x: x y: y w: w h: h <primitive: 'primitiveCreateRendererFlags' module:'B3DAcceleratorPlugin'> ^nil L
This primitive encapsulates the platform-dependent part of creating an OpenGL rendering context. OpenGL itself is platform-independent, but creating a window is not. The plugin has code for Mac, Windows, and Unix. So this creates a new borderless window that gets embedded in the "big" main window. It also creates an OpenGL context for that window and makes it current. After calling the primitive you can use any OpenGL commands to draw directly into it using the hardware renderer. I don't see a good reason why you would not want to use it. - Bert -
On 1/11/12 1:22 AM, Fernando Olivero wrote:
I've developed a CocoaUI app, which implements the example you copied. A cocoa window, with a custom NSView, which renders an OpenGL surface. The app also catches events, and notifies it via sockets.
My idea is to render within Pharo to a frame buffer object(offscreen rendering), and communicate the redisplay to the cocoa app via sockets (IPC).
So we can code all the UI in Smalltalk, using offscreen rendering as a means to draw to a native OS X window.
I will continue experimenting with this approach, to assess its performance and usability. Wether IPC via sockets is fast enough, amongst other technical challenges.
Yes, i noticed two that the OpenGL info in the Mac, returns 'APPLE SOFTWARE RENDERER 2.1". Surely we can find a way to solve this problem, i will look into Lawson's link.
Fernando pd: Enjoy the vacations Igor, have a pint or two.
On Wed, Jan 11, 2012 at 1:21 AM, Igor Stasenko<siguctua@gmail.com> wrote:
On 10 January 2012 21:28, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
thanks
May be this page is interesting: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Concep...
Igor how is london :) ?
Crowded? like hell. :) Kiev is more or less same in this regard, so i already having immunity
Yes, i will definitely get back to this issue, once i return from vacation. And now i should stop reading and replying mails and spend time on just resting :)
-- Best regards, Igor Stasenko.
participants (4)
-
Bert Freudenberg -
Fernando Olivero -
Lawson English -
ncalexan