Re: [Pharo-project] [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?
[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
On 11 January 2012 20:10, Lawson English <lenglish5@cox.net> 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] <ml-node+s1294792n4287148h52@n4.nabble.com> 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 -- View this message in context: http://forum.world.st/NativeBoost-and-NBOpenGL-on-Mac-tp4278813p4287190.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 1/11/12 3:54 PM, ncalexan wrote:
On Wed, Jan 11, 2012 at 2:40 PM, Igor Stasenko [via Smalltalk] <[hidden email] </user/SendEmail.jtp?type=node&node=4287190&i=0>> 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.
I guess it depends on your definition of primitive and just what it can do. L.
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<lenglish5@cox.net> 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
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<lenglish5@cox.net> 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
participants (3)
-
Igor Stasenko -
Lawson English -
ncalexan