NativeBoost and NBOpenGL on Mac?
Locked
12
12
NativeBoost and NBOpenGL on Mac?
 
|
I've had problems installing NativeBoost on Squeak, but it worked
reasonably well installing on a Mac. However, TestRunner failed while running the callback tests. This may or may not have anything to do with trying to work with NBOpenGL, which also installs fine on Pharo (but not squeak). Basically: GLViewportMorph new "useOwnForm: true;" openInWorld fails with Error: function unavailable It fails during this: hInst := NativeBoostWin32 getVMModuleHandle. which I assume means that Mac OS X is still not supported? Any workarounds available yet? I should point out that my little kludgey youtube demo of integrating OpenGL and the squeak IDE has generated 10x as many hits per day as the next most popular video in my tutorial series on squeak. I should also point out that when I demo pier and seaside I use Pharo and explicitly point out I'm using Pharo, so the Pharo community might benefit quite a bit from me being able to use NBOpenGL on the Mac... L. |
|
|
I believe there is an NBOpenGL-Mac package, but it doesn't yet create windows or integrate with Morphic. I found that the NBOpenGL-Mac package didn't work for me. There is a special calling procedure that tries to store the OpenGL API function pointers in the indexed variables of a variableByteObject and then call those addresses, but this fails with stack alignment errors for me. I fixed this by using the default NB calling procedure rather than this special calling procedure. So there is hope. Nick |
Re: NativeBoost and NBOpenGL on Mac?
|
|
On 10 January 2012 01:27, ncalexan <[hidden email]> wrote:
> > Lawson English-2 wrote >> >> I've had problems installing NativeBoost on Squeak, but it worked >> reasonably well installing on a Mac. However, TestRunner failed while >> running the callback tests. >> >> This may or may not have anything to do with trying to work with >> NBOpenGL, which also installs fine on Pharo (but not squeak). >> >> Basically: GLViewportMorph new "useOwnForm: true;" openInWorld >> >> fails with Error: function unavailable >> >> It fails during this: hInst := NativeBoostWin32 getVMModuleHandle. >> >> which I assume means that Mac OS X is still not supported? >> > > I believe there is an NBOpenGL-Mac package, but it doesn't yet create > windows or integrate with Morphic. > Apparently NativeBoostWin32 should not be used on macs (i actually wonder how you got an instance of it while running on mac). > > Lawson English-2 wrote >> >> Any workarounds available yet? I should point out that my little kludgey >> youtube demo of integrating OpenGL and the squeak IDE has generated 10x >> as many hits per day as the next most popular video in my tutorial >> series on squeak. I should also point out that when I demo pier and >> seaside I use Pharo and explicitly point out I'm using Pharo, so the >> Pharo community might benefit quite a bit from me being able to use >> NBOpenGL on the Mac... >> > > I found that the NBOpenGL-Mac package didn't work for me. There is a > special calling procedure that tries to store the OpenGL API function > pointers in the indexed variables of a variableByteObject and then call > those addresses, but this fails with stack alignment errors for me. I fixed > this by using the default NB calling procedure rather than this special > calling procedure. > > So there is hope. The problem i had stuck with is the inability to create a windowed context on Mac. For that i need to bind to either Carbon or Cocoa libs.. while i thought that i can just use basic functions. I were able to create an OpenGL context using coreGL (or something called Core) but i didn't managed to figure out what to do next. There seems to be lacking of windowing support on mac. So i could use this context as an offscreen context and it should work, but i'm not tried it yet. One of disappointment is that when i query the renderer used for given context, it reports an "Apple software renderer" , which not what i expected means that it is a software renderer, and not hardware acccelerated.. (or maybe it should be read as 'apple-software' renderer.. then there is more hope :) You can check the work if you load the package NBOpenGL-Mac. Any help or suggestions will be appreciated. > > Nick > > -- > View this message in context: http://forum.world.st/NativeBoost-and-NBOpenGL-on-Mac-tp4278813p4280623.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko. |
Re: NativeBoost and NBOpenGL on Mac?
|
|
Igor, I haven't read through the documentation, but glancing at some
complaints about this issue, it is plausible that the system thinks you're trying to run a remote OpenGL server. http://lists.apple.com/archives/mac-opengl/2007/Dec/msg00009.html The relevant documentation is supposed to be here: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html L On 1/10/12 6:08 AM, Igor Stasenko wrote: > The problem i had stuck with is the inability to create a windowed > context on Mac. For that i need to bind to either Carbon or Cocoa > libs.. while i thought that i can just use basic functions. I were > able to create an OpenGL context using coreGL (or something called > Core) but i didn't managed to figure out what to do next. There seems > to be lacking of windowing support on mac. So i could use this context > as an offscreen context and it should work, but i'm not tried it yet. > One of disappointment is that when i query the renderer used for given > context, it reports an "Apple software renderer" , which not what i > expected means that it is a software renderer, and not hardware > acccelerated.. (or maybe it should be read as 'apple-software' > renderer.. then there is more hope :) You can check the work if you > load the package NBOpenGL-Mac. Any help or suggestions will be > appreciated. |
Re: NativeBoost and NBOpenGL on Mac?
|
|
thanks
May be this page is interesting: <a href="http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8">http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8 Igor how is london :) ? Crowded? Stef On Jan 10, 2012, at 9:19 PM, Lawson English wrote: > Igor, I haven't read through the documentation, but glancing at some complaints about this issue, it is plausible that the system thinks you're trying to run a remote OpenGL server. > > http://lists.apple.com/archives/mac-opengl/2007/Dec/msg00009.html > > The relevant documentation is supposed to be here: > > http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html > > L > On 1/10/12 6:08 AM, Igor Stasenko wrote: >> The problem i had stuck with is the inability to create a windowed context on Mac. For that i need to bind to either Carbon or Cocoa libs.. while i thought that i can just use basic functions. I were able to create an OpenGL context using coreGL (or something called Core) but i didn't managed to figure out what to do next. There seems to be lacking of windowing support on mac. So i could use this context as an offscreen context and it should work, but i'm not tried it yet. One of disappointment is that when i query the renderer used for given context, it reports an "Apple software renderer" , which not what i expected means that it is a software renderer, and not hardware acccelerated.. (or maybe it should be read as 'apple-software' renderer.. then there is more hope :) You can check the work if you load the package NBOpenGL-Mac. Any help or suggestions will be appreciated. > > |
Re: NativeBoost and NBOpenGL on Mac?
|
|
On 10 January 2012 21:28, Stéphane Ducasse <[hidden email]> wrote:
> thanks > > May be this page is interesting: <a href="http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8">http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8 > > 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. |
Re: NativeBoost and NBOpenGL on Mac?
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]> wrote: > On 10 January 2012 21:28, Stéphane Ducasse <[hidden email]> wrote: >> thanks >> >> May be this page is interesting: <a href="http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8">http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8 >> >> 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. > |
Re: NativeBoost and NBOpenGL on Mac?
|
|
[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<[hidden email]> wrote: >> On 10 January 2012 21:28, Stéphane Ducasse<[hidden email]> wrote: >>> thanks >>> >>> May be this page is interesting: <a href="http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8">http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8 >>> >>> 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]
<[hidden email]> 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 |
Re: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
In reply to this post by LawsonEnglish
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<[hidden email]> wrote: >>> On 10 January 2012 21:28, Stéphane Ducasse<[hidden email]> wrote: >>>> thanks >>>> >>>> May be this page is interesting: <a href="http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8">http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8 >>>> >>>> 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. |
Re: NativeBoost and NBOpenGL on Mac?
|
|
In reply to this post by ncalexan
[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] |
Re: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
In reply to this post by Bert Freudenberg
[pharo list added back in for real this time]
Would it be best to have a VM primitive that actually gives this info in a cross-platform way since it is going to be more and more useful as time goes on? On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: > Am 11.01.2012 19:18, schrieb Bert Freudenberg: >> ... >> 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 - >> > I'm currently also experimenting with this (under Linux) and it looks like this does not fully work on my system - the > OpenGL output seems to be displayed for a very short moment, and then only teh Squeak desktop is visible again. > Of course, it's nice to have the platform-dependent part within the primitive, but at least for Windows and Linux/X11 > creating an OpenGL context is not really difficult, so since we already have platform-dependent OpenGL subclasses > anyway, there is no strong reason to keep the context creation stuff in primitive code. > > Cheers, > Hans-Martin > > |
Re: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
On 11 January 2012 20:10, Lawson English <[hidden email]> wrote:
> [pharo list added back in for real this time] > > Would it be best to have a VM primitive that actually gives this info in a > cross-platform way since it is going to be more and more useful as time goes > on? > one big issue with such primitive is lack of options which i able to contol for context i creating. As you may know there's a lot of different options , like - depth buffer bits, color buffer bits, alpha bits number of back buffers, subpixel antialiazing, auxuliarry buffers etc as i said before in other posts.. it is really hard to create a primitive which will allow you to control all those options, especially a cross-platform one. I know that for most users you could take 1 pixel format, 1 back buffer and you free to go, but it just doesn't feels right to me, why we should lose all the variety of control and put constrains at context creation stage. That's why i striving for controlling context creation at image side, and if that requires writing a platform-specific code in image, so be it. But then i could make sure that you could access all OpenGL capabilities similar to C/C++ code, without limitations. For beginners, these options may mean nothing, but for those who dealing with OpenGL at more advanced levels, trust me, they simply cannot live without it. Many advanced opengl examples and rendering techniques requiring fine control on context creation. > On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: >> >> Am 11.01.2012 19:18, schrieb Bert Freudenberg: >>> >>> ... >>> 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 - >>> >> I'm currently also experimenting with this (under Linux) and it looks like >> this does not fully work on my system - the >> OpenGL output seems to be displayed for a very short moment, and then only >> teh Squeak desktop is visible again. >> Of course, it's nice to have the platform-dependent part within the >> primitive, but at least for Windows and Linux/X11 >> creating an OpenGL context is not really difficult, so since we already >> have platform-dependent OpenGL subclasses >> anyway, there is no strong reason to keep the context creation stuff in >> primitive code. >> >> Cheers, >> Hans-Martin >> >> > > -- Best regards, Igor Stasenko. |
|
|
On Wed, Jan 11, 2012 at 2:40 PM, Igor Stasenko [via Smalltalk]
<[hidden email]> wrote: > On 11 January 2012 20:10, Lawson English <[hidden email]> wrote: >> [pharo list added back in for real this time] >> >> Would it be best to have a VM primitive that actually gives this info in a >> cross-platform way since it is going to be more and more useful as time >> goes >> on? >> > > one big issue with such primitive is lack of options which i able to > contol for context i creating. > As you may know there's a lot of different options , like > - depth buffer bits, color buffer bits, alpha bits number of back > buffers, subpixel antialiazing, > auxuliarry buffers etc > > as i said before in other posts.. it is really hard to create a > primitive which will allow > you to control all those options, especially a cross-platform one. +1. I have been experimenting with an FFI interface to libSDL, a cross-platform game library that abstracts window and context creation (as well as input). It works quite well under Mac OS X but I expect there will be more work to make it run smoothly under Windows and Linux. It is my opinion that duplicating such functionality in Squeak/Pharo is a poor use of resources. Nick |
Re: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
On 1/11/12 3:54 PM, ncalexan wrote: On Wed, Jan 11, 2012 at 2:40 PM, Igor Stasenko [via Smalltalk] I guess it depends on your definition of primitive and just what it can do. L. |
Re: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
In reply to this post by Igor Stasenko
There's bound to be a way. Perhaps an array of requests, followed by an
array of responses, that can be normalized in a cross-platform way? The fact that the responses might be platform specific doesn't matter as long as they are consistent within the platform, right? You just need 2-way glue: 1 way to create the query and the other to put the query in a cross-platform format that can be used by the rest of the system. L. On 1/11/12 3:39 PM, Igor Stasenko wrote: > On 11 January 2012 20:10, Lawson English<[hidden email]> wrote: >> [pharo list added back in for real this time] >> >> Would it be best to have a VM primitive that actually gives this info in a >> cross-platform way since it is going to be more and more useful as time goes >> on? >> > one big issue with such primitive is lack of options which i able to > contol for context i creating. > As you may know there's a lot of different options , like > - depth buffer bits, color buffer bits, alpha bits number of back > buffers, subpixel antialiazing, > auxuliarry buffers etc > > as i said before in other posts.. it is really hard to create a > primitive which will allow > you to control all those options, especially a cross-platform one. > > I know that for most users you could take 1 pixel format, 1 back > buffer and you free to go, > but it just doesn't feels right to me, why we should lose all the > variety of control and put constrains at context creation stage. > That's why i striving for controlling context creation at image side, > and if that requires writing a platform-specific code > in image, so be it. But then i could make sure that you could access > all OpenGL capabilities similar to C/C++ code, > without limitations. > For beginners, these options may mean nothing, but for those who > dealing with OpenGL at more advanced levels, trust me, > they simply cannot live without it. Many advanced opengl examples and > rendering techniques requiring fine control on context creation. > > > >> On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: >>> Am 11.01.2012 19:18, schrieb Bert Freudenberg: >>>> ... >>>> 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 - >>>> >>> I'm currently also experimenting with this (under Linux) and it looks like >>> this does not fully work on my system - the >>> OpenGL output seems to be displayed for a very short moment, and then only >>> teh Squeak desktop is visible again. >>> Of course, it's nice to have the platform-dependent part within the >>> primitive, but at least for Windows and Linux/X11 >>> creating an OpenGL context is not really difficult, so since we already >>> have platform-dependent OpenGL subclasses >>> anyway, there is no strong reason to keep the context creation stuff in >>> primitive code. >>> >>> Cheers, >>> Hans-Martin >>> >>> >> > > |
Saga of trying to integrate IDE with OpenGL continuesRe: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
http://www.youtube.com/watch?v=F5GHRaIwCS4
nowhere near where it could be. With NBOpenGL and GLDisplay, things would be much snappier and easier. Of course, at this point, we need to start discussing how to integrate OpenGL errors into the squeak debugging system so that the IDE remains stable... L. On 1/13/12 10:29 AM, Lawson English wrote: > There's bound to be a way. Perhaps an array of requests, followed by > an array of responses, that can be normalized in a cross-platform way? > > The fact that the responses might be platform specific doesn't matter > as long as they are consistent within the platform, right? > You just need 2-way glue: 1 way to create the query and the other to > put the query in a cross-platform format that can be used by the rest > of the system. > > L. > > On 1/11/12 3:39 PM, Igor Stasenko wrote: >> On 11 January 2012 20:10, Lawson English<[hidden email]> wrote: >>> [pharo list added back in for real this time] >>> >>> Would it be best to have a VM primitive that actually gives this >>> info in a >>> cross-platform way since it is going to be more and more useful as >>> time goes >>> on? >>> >> one big issue with such primitive is lack of options which i able to >> contol for context i creating. >> As you may know there's a lot of different options , like >> - depth buffer bits, color buffer bits, alpha bits number of back >> buffers, subpixel antialiazing, >> auxuliarry buffers etc >> >> as i said before in other posts.. it is really hard to create a >> primitive which will allow >> you to control all those options, especially a cross-platform one. >> >> I know that for most users you could take 1 pixel format, 1 back >> buffer and you free to go, >> but it just doesn't feels right to me, why we should lose all the >> variety of control and put constrains at context creation stage. >> That's why i striving for controlling context creation at image side, >> and if that requires writing a platform-specific code >> in image, so be it. But then i could make sure that you could access >> all OpenGL capabilities similar to C/C++ code, >> without limitations. >> For beginners, these options may mean nothing, but for those who >> dealing with OpenGL at more advanced levels, trust me, >> they simply cannot live without it. Many advanced opengl examples and >> rendering techniques requiring fine control on context creation. >> >> >> >>> On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: >>>> Am 11.01.2012 19:18, schrieb Bert Freudenberg: >>>>> ... >>>>> 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 - >>>>> >>>> I'm currently also experimenting with this (under Linux) and it >>>> looks like >>>> this does not fully work on my system - the >>>> OpenGL output seems to be displayed for a very short moment, and >>>> then only >>>> teh Squeak desktop is visible again. >>>> Of course, it's nice to have the platform-dependent part within the >>>> primitive, but at least for Windows and Linux/X11 >>>> creating an OpenGL context is not really difficult, so since we >>>> already >>>> have platform-dependent OpenGL subclasses >>>> anyway, there is no strong reason to keep the context creation >>>> stuff in >>>> primitive code. >>>> >>>> Cheers, >>>> Hans-Martin >>>> >>>> >>> >> >> > > > |
Re: Saga of trying to integrate IDE with OpenGL continuesRe: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
Sounds good.
BTW, the trend of popularity continues. This latest video http://www.youtube.com/watch?v=F5GHRaIwCS4 has had 45 views since I put it up yesterday and the first video on that topic is now at 145 views (my most popular video took 2 months to get that many views). Once you get NBOpenGL and GLDisplay cross-platform, I suspect there will be a rather large number of OpenGL programmers testing how it works. Games, GUI testing, algorithmic and other technical visualization. Cobalt/Croquet integration, etc. Lots of potential here. L. On 1/14/12 7:22 AM, Igor Stasenko wrote: > On 14 January 2012 07:12, Lawson English<[hidden email]> wrote: >> http://www.youtube.com/watch?v=F5GHRaIwCS4 >> >> nowhere near where it could be. With NBOpenGL and GLDisplay, things would be >> much snappier and easier. Of course, at this point, we need to start >> discussing how to integrate OpenGL errors into the squeak debugging system >> so that the IDE remains stable... >> > well, one of the ideas is to use fallback display in case of openGL error(s). > And render not to GL context but to bitmap. Then you can actually use > debugger to debug GL calls step by step > without interfering with GL stack/state. > Another approach would be to create a separate GL context and use it > for debugger. But then you need to keep an eye > for switching active contexts at right moment. > >> L. >> |
Re: Saga of trying to integrate IDE with OpenGL continuesRe: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
|
|
The latest video in the saga: http://www.youtube.com/watch?v=TsJmBwi9lDY
BTW, the video I mentioned a day or so ago now has 90 views, in only 3 days. People who want to promote squeak/pharo/seaside/etc to the world at large should take note. L. On 1/14/12 12:20 PM, Igor Stasenko wrote: > [...] >>> well, one of the ideas is to use fallback display in case of openGL >>> error(s). >>> And render not to GL context but to bitmap. Then you can actually use >>> debugger to debug GL calls step by step >>> without interfering with GL stack/state. >>> Another approach would be to create a separate GL context and use it >>> for debugger. But then you need to keep an eye >>> for switching active contexts at right moment. >>> >>>> L. >>>> >> > > |
|
|
Keep going. I would love to have opengl well integrated.
Alexandre On 16 Jan 2012, at 23:44, Lawson English wrote: > The latest video in the saga: http://www.youtube.com/watch?v=TsJmBwi9lDY > > BTW, the video I mentioned a day or so ago now has 90 views, in only 3 days. > > People who want to promote squeak/pharo/seaside/etc to the world at large should take note. > > L. > > > > > On 1/14/12 12:20 PM, Igor Stasenko wrote: >> [...] >>>> well, one of the ideas is to use fallback display in case of openGL >>>> error(s). >>>> And render not to GL context but to bitmap. Then you can actually use >>>> debugger to debug GL calls step by step >>>> without interfering with GL stack/state. >>>> Another approach would be to create a separate GL context and use it >>>> for debugger. But then you need to keep an eye >>>> for switching active contexts at right moment. >>>> >>>>> L. >>>>> >>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |