Re: [Pharo-dev] OpenGL 3.0+
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hello, I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL. The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs. Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0. Another question, a core profile context is really needed? Why not starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working. Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile. As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow. OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat. For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there. I have to tell the CMakeVMMaker to also build SDL2 before building, instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4. As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image. In fact, I already started making a new 3D graphics engine Pharo, to rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine. With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job. Greetings, Ronie 2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Thanks for all the great info Ronie! On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
OK. Where is the old generator? I will look into it if nobody is already doing so. Another question, a core profile context is really needed? Why not starting
working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
Good points. Nevertheless, as I understand it, OSX does not provide a compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 core. So we are working with an API that was deprecated 6 years ago that can only take advantage of a fraction of the power of our GPUs and is discouraged/unavailable on mobile platforms. Maybe that is enough for some things but I'd like to see the door opened for more. This makes me wonder what the compatibility philosophy of Pharo is. Is it a goal that once something is developed in Pharo it will work unchanged on all future Pharo versions? I imagine one of the liberating aspects of VMs is that they can evolve, even incompatibility, because old software can continue to run on old VMs. But I am new to Smalltalk/Pharo culture so please educate me. Maybe we need a GL3ViewportMorph to live along side GLViewportMorph.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
I have read a little of this -- very exciting!
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
If there is something I can do to help with the Mac I would like to. I have to tell the CMakeVMMaker to also build SDL2 before building, instead
of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
Yes, SDL2 is the way to go. In fact, I already started making a new 3D graphics engine Pharo, to
rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
Sounds interesting!
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?). It's not clear to me how the OSWindow work will result in a faster Pharo UI. On OSX, at least, underneath everything is already an OS window that supports GL and other accelerated calls but the Pharo graphics primitives don't take advantage of this. Won't they need reworking? Greetings,
Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hello, OK. Where is the old generator? I will look into it if nobody is already
doing so.
The old generator is in the NBOpenGL Smalltalk Hub repository. It does a lot of magic so working with it can be very frustrating. Also, you are going to want to read about the fileout format( http://www.inf.ufsc.br/poo/smalltalk/stx/english/programming/fileoutFormat.h... ). Ask all the details to Igor or Jean Baptiste, they are more familiar with NBOpenGL itself. If there is something I can do to help with the Mac I would like to.
In my other post a published a bit of OSWindow. You can try to play with it or making it work on Mac. Apart from the VM changes, for Mac is missing testing for loading the SDL2 library. Very nice. Is Athens used to render the main UI elements (windows, buttons,
bitmaps, text, etc?).
I believe that most of them not, because they rely on older raster operations. I think that accelerating Morphic requires refactoring it to use Athens all the time. As for myself, I need an Athens backend for Roassal2 to avoid having cairo->form->texture transfers. Greetings, Ronie 2014-05-31 13:00 GMT-04:00 Ben Coman <btc@openinworld.com>:
Darrin Massena wrote:
Thanks for all the great info Ronie!
On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
OK. Where is the old generator? I will look into it if nobody is already doing so.
I am not involved so cannot answer directly, but I see something similar discussed here.. http://jeanbaptiste-arnaud.eu/opengl/
Another question, a core profile context is really needed? Why not
starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
Good points. Nevertheless, as I understand it, OSX does not provide a compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 core. So we are working with an API that was deprecated 6 years ago that can only take advantage of a fraction of the power of our GPUs and is discouraged/unavailable on mobile platforms. Maybe that is enough for some things but I'd like to see the door opened for more.
This makes me wonder what the compatibility philosophy of Pharo is. Is it a goal that once something is developed in Pharo it will work unchanged on all future Pharo versions? I imagine one of the liberating aspects of VMs is that they can evolve, even incompatibility, because old software can continue to run on old VMs. But I am new to Smalltalk/Pharo culture so please educate me.
Backward compatibility can be a divisive subject. The disparate views expressed at [1] will give you a general overview of Pharo's philosophy. Now your question is slightly different to the usual backward-compatibility discussion that relates to the existing codebase inherited from Squeak and before. Here on of Pharo's goal to enhance future maintainability by elimination of "legacy code", where [1] defines "legacy code" as: - a code written eons ago - original authors are gone/not interested in communicating - no documentation - a lot of patches and extensions from various authors over ears - often same functionality implemented using two different ways - things are completely bizarre, unmaintainable and unable to understand
So for the existing code, while compatibility is kept as much as possible, cleaning takes priority. While this might cause some early pain, the mid to long terms should end up better than otherwise.
Regarding "once something is developed in Pharo will it work unchanged on _all_ future Pharo versions?" I would hazard to guess, considering the keyword "all", that the answer is "no". The Pharo team are pragmatic about what they can achieve with their resources. If something can provide more (in terms of maintainability and broader usage) for a given effort, then that is probably the path to be taken.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.ht...
cheers -ben
Maybe we need a GL3ViewportMorph to live along side GLViewportMorph.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
I have read a little of this -- very exciting!
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
If there is something I can do to help with the Mac I would like to.
I have to tell the CMakeVMMaker to also build SDL2 before building,
instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
Yes, SDL2 is the way to go.
In fact, I already started making a new 3D graphics engine Pharo, to
rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
Sounds interesting!
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?).
It's not clear to me how the OSWindow work will result in a faster Pharo UI. On OSX, at least, underneath everything is already an OS window that supports GL and other accelerated calls but the Pharo graphics primitives don't take advantage of this. Won't they need reworking?
Greetings,
Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
On Sat, May 31, 2014 at 1:21 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
OK. Where is the old generator? I will look into it if nobody is already
doing so.
The old generator is in the NBOpenGL Smalltalk Hub repository. It does a lot of magic so working with it can be very frustrating. Also, you are going to want to read about the fileout format( http://www.inf.ufsc.br/poo/smalltalk/stx/english/programming/fileoutFormat.h... ).
Thanks, I'll read up.
Ask all the details to Igor or Jean Baptiste, they are more familiar with NBOpenGL itself.
If there is something I can do to help with the Mac I would like to.
In my other post a published a bit of OSWindow. You can try to play with it or making it work on Mac. Apart from the VM changes, for Mac is missing testing for loading the SDL2 library.
I'll give it a try and let you know if I can get something working.
Very nice. Is Athens used to render the main UI elements (windows,
buttons, bitmaps, text, etc?).
I believe that most of them not, because they rely on older raster operations. I think that accelerating Morphic requires refactoring it to use Athens all the time. As for myself, I need an Athens backend for Roassal2 to avoid having cairo->form->texture transfers.
On the Mac I have measured that the lowest level primitive for updating the screen (primShowRectLeft:right:top:bottom) is quite slow (48ms for a full screen update on my super-fast Mac Pro). It is doing pixel format conversion, creating a screen sized bitmap, copying the bits in, drawing the bitmap to the screen context, and then converting the pixels back. So, even without Morphic overhead it is very slow. I'll check your sources but are you reimplementing this on Linux (it was probably different to begin with)?
Greetings, Ronie
2014-05-31 13:00 GMT-04:00 Ben Coman <btc@openinworld.com>:
Darrin Massena wrote:
Thanks for all the great info Ronie!
On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
OK. Where is the old generator? I will look into it if nobody is already doing so.
I am not involved so cannot answer directly, but I see something similar discussed here.. http://jeanbaptiste-arnaud.eu/opengl/
Another question, a core profile context is really needed? Why not
starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
Good points. Nevertheless, as I understand it, OSX does not provide a compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 core. So we are working with an API that was deprecated 6 years ago that can only take advantage of a fraction of the power of our GPUs and is discouraged/unavailable on mobile platforms. Maybe that is enough for some things but I'd like to see the door opened for more.
This makes me wonder what the compatibility philosophy of Pharo is. Is it a goal that once something is developed in Pharo it will work unchanged on all future Pharo versions? I imagine one of the liberating aspects of VMs is that they can evolve, even incompatibility, because old software can continue to run on old VMs. But I am new to Smalltalk/Pharo culture so please educate me.
Backward compatibility can be a divisive subject. The disparate views expressed at [1] will give you a general overview of Pharo's philosophy. Now your question is slightly different to the usual backward-compatibility discussion that relates to the existing codebase inherited from Squeak and before. Here on of Pharo's goal to enhance future maintainability by elimination of "legacy code", where [1] defines "legacy code" as: - a code written eons ago - original authors are gone/not interested in communicating - no documentation - a lot of patches and extensions from various authors over ears - often same functionality implemented using two different ways - things are completely bizarre, unmaintainable and unable to understand
So for the existing code, while compatibility is kept as much as possible, cleaning takes priority. While this might cause some early pain, the mid to long terms should end up better than otherwise.
Regarding "once something is developed in Pharo will it work unchanged on _all_ future Pharo versions?" I would hazard to guess, considering the keyword "all", that the answer is "no". The Pharo team are pragmatic about what they can achieve with their resources. If something can provide more (in terms of maintainability and broader usage) for a given effort, then that is probably the path to be taken.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.ht...
cheers -ben
Maybe we need a GL3ViewportMorph to live along side GLViewportMorph.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
I have read a little of this -- very exciting!
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
If there is something I can do to help with the Mac I would like to.
I have to tell the CMakeVMMaker to also build SDL2 before building,
instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
Yes, SDL2 is the way to go.
In fact, I already started making a new 3D graphics engine Pharo, to
rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
Sounds interesting!
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?).
It's not clear to me how the OSWindow work will result in a faster Pharo UI. On OSX, at least, underneath everything is already an OS window that supports GL and other accelerated calls but the Pharo graphics primitives don't take advantage of this. Won't they need reworking?
Greetings,
Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
Hi darrin
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?).
I believe that most of them not, because they rely on older raster operations. I think that accelerating Morphic requires refactoring it to use Athens all the time.
Yes this is the plan. Use the athensDrawOn:, rewrite most of the drawOn: methods using Athens and having one API (Athens) with multiple back-ends. The future is what ronie and igor are doing :) and we need forces on that. Because it can change the face of Pharo for real :).
As for myself, I need an Athens backend for Roassal2 to avoid having cairo->form->texture transfer
On the Mac I have measured that the lowest level primitive for updating the screen (primShowRectLeft:right:top:bottom) is quite slow (48ms for a full screen update on my super-fast Mac Pro). It is doing pixel format conversion, creating a screen sized bitmap, copying the bits in, drawing the bitmap to the screen context, and then converting the pixels back. So, even without Morphic overhead it is very slow.
Thanks for your points. We share them. This is why igor worked to have a vector graphics solution. You should look at Athens (this is just an API but a nice one and for now it has two back-ends). Igor is working a new texteditor and after we should convert the drawing of morph to use the Athens API. We want Pharo to be a modern and fast system (so this should answer your backward compatibility questions). Better moving than dead. Stef
I'll check your sources but are you reimplementing this on Linux (it was probably different to begin with)?
Greetings, Ronie
2014-05-31 13:00 GMT-04:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:
Darrin Massena wrote:
Thanks for all the great info Ronie!
On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg@gmail.com <mailto:roniesalg@gmail.com>> wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
OK. Where is the old generator? I will look into it if nobody is already doing so.
I am not involved so cannot answer directly, but I see something similar discussed here.. http://jeanbaptiste-arnaud.eu/opengl/
Another question, a core profile context is really needed? Why not starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
Good points. Nevertheless, as I understand it, OSX does not provide a compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 core. So we are working with an API that was deprecated 6 years ago that can only take advantage of a fraction of the power of our GPUs and is discouraged/unavailable on mobile platforms. Maybe that is enough for some things but I'd like to see the door opened for more.
This makes me wonder what the compatibility philosophy of Pharo is. Is it a goal that once something is developed in Pharo it will work unchanged on all future Pharo versions? I imagine one of the liberating aspects of VMs is that they can evolve, even incompatibility, because old software can continue to run on old VMs. But I am new to Smalltalk/Pharo culture so please educate me.
Backward compatibility can be a divisive subject. The disparate views expressed at [1] will give you a general overview of Pharo's philosophy. Now your question is slightly different to the usual backward-compatibility discussion that relates to the existing codebase inherited from Squeak and before. Here on of Pharo's goal to enhance future maintainability by elimination of "legacy code", where [1] defines "legacy code" as: - a code written eons ago - original authors are gone/not interested in communicating - no documentation - a lot of patches and extensions from various authors over ears - often same functionality implemented using two different ways - things are completely bizarre, unmaintainable and unable to understand
So for the existing code, while compatibility is kept as much as possible, cleaning takes priority. While this might cause some early pain, the mid to long terms should end up better than otherwise.
Regarding "once something is developed in Pharo will it work unchanged on _all_ future Pharo versions?" I would hazard to guess, considering the keyword "all", that the answer is "no". The Pharo team are pragmatic about what they can achieve with their resources. If something can provide more (in terms of maintainability and broader usage) for a given effort, then that is probably the path to be taken.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.ht...
cheers -ben
Maybe we need a GL3ViewportMorph to live along side GLViewportMorph.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
I have read a little of this -- very exciting!
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
If there is something I can do to help with the Mac I would like to.
I have to tell the CMakeVMMaker to also build SDL2 before building, instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
Yes, SDL2 is the way to go.
In fact, I already started making a new 3D graphics engine Pharo, to rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
Sounds interesting!
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?).
It's not clear to me how the OSWindow work will result in a faster Pharo UI. On OSX, at least, underneath everything is already an OS window that supports GL and other accelerated calls but the Pharo graphics primitives don't take advantage of this. Won't they need reworking?
Greetings, Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:
darrinm wrote > Oh, and NBMacGLConstants is lacking necessary constants. Is it manually > created or generated somehow? > > - darrinm
On Sat, May 31, 2014 at 10:00 AM, Ben Coman <btc@openinworld.com> wrote:
Backward compatibility can be a divisive subject. The disparate views expressed at [1] will give you a general overview of Pharo's philosophy. Now your question is slightly different to the usual backward-compatibility discussion that relates to the existing codebase inherited from Squeak and before. Here on of Pharo's goal to enhance future maintainability by elimination of "legacy code", where [1] defines "legacy code" as: - a code written eons ago - original authors are gone/not interested in communicating - no documentation - a lot of patches and extensions from various authors over ears - often same functionality implemented using two different ways - things are completely bizarre, unmaintainable and unable to understand
So for the existing code, while compatibility is kept as much as possible, cleaning takes priority. While this might cause some early pain, the mid to long terms should end up better than otherwise.
Very reasonable and pragmatic.
Regarding "once something is developed in Pharo will it work unchanged on _all_ future Pharo versions?" I would hazard to guess, considering the keyword "all", that the answer is "no". The Pharo team are pragmatic about what they can achieve with their resources. If something can provide more (in terms of maintainability and broader usage) for a given effort, then that is probably the path to be taken.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.ht...
Thanks for the link. Very illuminating.
cheers -ben
Maybe we need a GL3ViewportMorph to live along side GLViewportMorph.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
I have read a little of this -- very exciting!
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
If there is something I can do to help with the Mac I would like to.
I have to tell the CMakeVMMaker to also build SDL2 before building,
instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
Yes, SDL2 is the way to go.
In fact, I already started making a new 3D graphics engine Pharo, to
rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
Sounds interesting!
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?).
It's not clear to me how the OSWindow work will result in a faster Pharo UI. On OSX, at least, underneath everything is already an OS window that supports GL and other accelerated calls but the Pharo graphics primitives don't take advantage of this. Won't they need reworking?
Greetings,
Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
On the Mac I have measured that the lowest level primitive for updating the screen (primShowRectLeft:right:top:bottom) is quite slow (48ms for a full screen update on my super-fast Mac Pro). It is doing pixel format conversion, creating a screen sized bitmap, copying the bits in, drawing the bitmap to the screen context, and then converting the pixels back. So, even without Morphic overhead it is very slow.
I'll check your sources but are you reimplementing this on Linux (it was probably different to begin with)?
We removed all the primitives. In the Linux OSWindow, almost everything is in the image side. The only bit in the VM, it is the one that concerns with checking for new events. 2014-06-01 15:09 GMT-04:00 Darrin Massena <darrin@massena.com>:
On Sat, May 31, 2014 at 10:00 AM, Ben Coman <btc@openinworld.com> wrote:
Backward compatibility can be a divisive subject. The disparate views expressed at [1] will give you a general overview of Pharo's philosophy. Now your question is slightly different to the usual backward-compatibility discussion that relates to the existing codebase inherited from Squeak and before. Here on of Pharo's goal to enhance future maintainability by elimination of "legacy code", where [1] defines "legacy code" as: - a code written eons ago - original authors are gone/not interested in communicating - no documentation - a lot of patches and extensions from various authors over ears - often same functionality implemented using two different ways - things are completely bizarre, unmaintainable and unable to understand
So for the existing code, while compatibility is kept as much as possible, cleaning takes priority. While this might cause some early pain, the mid to long terms should end up better than otherwise.
Very reasonable and pragmatic.
Regarding "once something is developed in Pharo will it work unchanged on _all_ future Pharo versions?" I would hazard to guess, considering the keyword "all", that the answer is "no". The Pharo team are pragmatic about what they can achieve with their resources. If something can provide more (in terms of maintainability and broader usage) for a given effort, then that is probably the path to be taken.
[1] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.ht...
Thanks for the link. Very illuminating.
cheers -ben
Maybe we need a GL3ViewportMorph to live along side GLViewportMorph.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
I have read a little of this -- very exciting!
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
If there is something I can do to help with the Mac I would like to.
I have to tell the CMakeVMMaker to also build SDL2 before building,
instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
Yes, SDL2 is the way to go.
In fact, I already started making a new 3D graphics engine Pharo, to
rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
Sounds interesting!
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?).
It's not clear to me how the OSWindow work will result in a faster Pharo UI. On OSX, at least, underneath everything is already an OS window that supports GL and other accelerated calls but the Pharo graphics primitives don't take advantage of this. Won't they need reworking?
Greetings,
Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
On 31 May 2014 02:43, Darrin Massena <darrin@massena.com> wrote:
Thanks for all the great info Ronie!
On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
OK. Where is the old generator? I will look into it if nobody is already doing so.
Everything should be hosted at http://www.smalltalkhub.com/#!/~PharoExtras/NBOpenGL see OpenGL-Specs <http://www.smalltalkhub.com/#%21/%7EPharoExtras/NBOpenGL/packages/OpenGL-Spe...> package please give me your name so i will add you as contributor, so you can commit changes there.
Another question, a core profile context is really needed? Why not
starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
Good points. Nevertheless, as I understand it, OSX does not provide a compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 core. So we are working with an API that was deprecated 6 years ago that can only take advantage of a fraction of the power of our GPUs and is discouraged/unavailable on mobile platforms. Maybe that is enough for some things but I'd like to see the door opened for more.
This makes me wonder what the compatibility philosophy of Pharo is. Is it a goal that once something is developed in Pharo it will work unchanged on all future Pharo versions? I imagine one of the liberating aspects of VMs is that they can evolve, even incompatibility, because old software can continue to run on old VMs. But I am new to Smalltalk/Pharo culture so please educate me.
Maybe we need a GL3ViewportMorph to live along side GLViewportMorph.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
I have read a little of this -- very exciting!
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
If there is something I can do to help with the Mac I would like to.
I have to tell the CMakeVMMaker to also build SDL2 before building,
instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
Yes, SDL2 is the way to go.
Well, wellcome to minimum common denominator problem :) But anyways it is good to have SDL2 backend.. however i prefer a direct communication with platform, like that, avoiding possible inefficiencies and crippling feature set (because SDL must support all of them everywhere, which is not always possible).
In fact, I already started making a new 3D graphics engine Pharo, to
rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
Sounds interesting!
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Very nice. Is Athens used to render the main UI elements (windows, buttons, bitmaps, text, etc?).
It's not clear to me how the OSWindow work will result in a faster Pharo UI. On OSX, at least, underneath everything is already an OS window that supports GL and other accelerated calls but the Pharo graphics primitives don't take advantage of this. Won't they need reworking?
because of exccesssssive buffering + implicit bits conversions. In short: the way how Morphic delivers pixels to screen is quite far from optimal. With direct access to native window/graphical context, we could do much faster.. and OSWindow gives us a precise control over data flow.
Greetings,
Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Ronie what would be good is to build milestones so that other people can play with it and demo it. So a solution even not working perfectly is better than a not working one. Stef On 31/5/14 01:06, Ronie Salgado wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
Another question, a core profile context is really needed? Why not starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
I have to tell the CMakeVMMaker to also build SDL2 before building, instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
In fact, I already started making a new 3D graphics engine Pharo, to rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Greetings, Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:
darrinm wrote > Oh, and NBMacGLConstants is lacking necessary constants. Is it manually > created or generated somehow? > > - darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Stef, I also want to do that. I think that for Linux it is quite stable. In those last days I have been messing a lot with Roassal 3D and WODEN(WOrld Dynamic ENgine). Tomorrow I will try make a clean build of the OSWindow VM(My last try required lot of manual tweaking). For Linux, I just finally added the code to also build SDL2 with the VM automatically and I want to try it on Windows. As for the next milestone, see the next post. I think that deserves his own thread. Greetings, Ronie 2014-05-31 1:57 GMT-04:00 stepharo <stepharo@free.fr>:
Ronie
what would be good is to build milestones so that other people can play with it and demo it. So a solution even not working perfectly is better than a not working one.
Stef
On 31/5/14 01:06, Ronie Salgado wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
Another question, a core profile context is really needed? Why not starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
I have to tell the CMakeVMMaker to also build SDL2 before building, instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
In fact, I already started making a new 3D graphics engine Pharo, to rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Greetings, Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com>:
darrinm wrote
Oh, and NBMacGLConstants is lacking necessary constants. Is it manually created or generated somehow?
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Ronie this is excellent! :) I love when people deeply understand: Pharo is yours :). Let us build together a cool future :). Stef
Hi Stef,
I also want to do that. I think that for Linux it is quite stable. In those last days I have been messing a lot with Roassal 3D and WODEN(WOrld Dynamic ENgine).
Tomorrow I will try make a clean build of the OSWindow VM(My last try required lot of manual tweaking). For Linux, I just finally added the code to also build SDL2 with the VM automatically and I want to try it on Windows.
As for the next milestone, see the next post. I think that deserves his own thread.
Greetings, Ronie
2014-05-31 1:57 GMT-04:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Ronie
what would be good is to build milestones so that other people can play with it and demo it. So a solution even not working perfectly is better than a not working one.
Stef
On 31/5/14 01:06, Ronie Salgado wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor was generating the bindings from older specifications of the OpenGL API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files provided by Khronos Group. In this link http://www.opengl.org/registry/#specfiles another link for a subversion repository( https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for OpenGL 3.3-4.0.
Another question, a core profile context is really needed? Why not starting working with a compatibility profile?. OpenGL API deprecation does not depend on us, it depends on what the Khronos Group and the graphics card maker decide to do. In the x86 Desktop, the three big companies cannot remove the compatibility profile, otherwise lot of older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in laptops that are only OpenGL 2.x. A better bet is to support at least the subset available in OpenGL 2.x that is also available in the core profile.
As for plans for OpenGL support, normal and accelerated GUIs, I am working in OSWindow.
OSWindow provides support to manage native operating system windows purely from image side. With Igor, we made a custom image and VM for Linux in which we removed almost everything graphic related from the VM. The only support needed in the VM is a small check for event presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce maintenance efforts for Windows and Mac OS, I made a new backend based in SDL2. It is quite complete and I have tested mostly in Linux. For Windows I could make it work, not perfect so it needs more testing and a complete removal of the old Win32 drivers. I don't have a Mac for testing, but Alex is going to help me there.
I have to tell the CMakeVMMaker to also build SDL2 before building, instead of having to build/install it manually. After that I think that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating a window with an OpenGL context. I already made it work with NBOpenGL, the only tricky part is dependency order when loading the stuff in the image.
In fact, I already started making a new 3D graphics engine Pharo, to rewrite Roassal 3D on top of this one in the near future. Soon I will be posting some screen-shots of this engine.
With this graphics engine, I am also going to try to make an Athens backend, for accelerated vector graphics. Vectorial graphics with OpenGL are very hard to do fast, specially self intersecting bezier curves. Stencil based testing is simple, fast, supported and efficient for this job.
Greetings, Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:
darrinm wrote > Oh, and NBMacGLConstants is lacking necessary constants. Is it manually > created or generated somehow? > > - darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (6)
-
Ben Coman -
Darrin Massena -
Igor Stasenko -
Ronie Salgado -
Sean P. DeNigris -
stepharo