On 31 May 2014 02:43, Darrin Massena <dar...@massena.com> wrote: > Thanks for all the great info Ronie! > > > On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <ronies...@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-Specs> 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 <s...@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.
