- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OpenGL 3.0+

by Igor Stasenko

On 31 May 2014 02:43, Darrin Massena <darrin(a)massena.com> wrote: > Thanks for all the great info Ronie! > > > On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg(a)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-Sp…> 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(a)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.

June 3, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by stepharo

Nice! Alain restarted to work on Bloc and the result looks nice. I'm trying to get some influence and rewrite clean what I see that can be cleaned. Stef > Hi, > > I created a job that bootstraps MorphicCore - an image that contains > runable subset of Morphic that is able only to display a simple morph > and handle mouse and keyboard events on it. Please, try to test the > image on Mac. > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > Cheers, > -- Pavel

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by Clara Allende

haha, well, if any of you can provide a way to reproduce the problem, I will take a look. 2014-06-03 14:46 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > 2014-06-03 14:09 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > >> On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel(a)gmail.com> >> wrote: >> >> >> On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> Hello, >> >> It happens sometimes when you edit a blockClosure code and that the >> debugger cannot find it on stack. >> >> >> Why would the debugger need to find a context for an edited block? >> The only reason I see would be on-stack replacement, but AFAIK the >> debugger doesn't do that, does it? >> >> >> I have spotted this problem too, outside block closures. It is not every >> time but it happens occasionally. >> I think is some sort of bug :( >> > > Yeah I also had the problem ... > > Fortunately, one of the debugger implementor (that I will not name here) > is working in our team right now and she may be able to fix it :-) > > >> >> Esteban >> >> >> >> Isn't that your case ? >> >> >> 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> While debugging, I modify the code of the method, then accept, then >>> restart. >>> >>> But when going back to the method in the browser, it is unchanged. >>> >>> What I am doing wrong or is this something other people do encounter? >>> >>> I didn't had this in 2.0 >>> >>> Phil >>> >> >> >> >> >

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by phil＠highoctane.be

On Tue, Jun 3, 2014 at 2:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > It happens sometimes when you edit a blockClosure code and that the > debugger cannot find it on stack. > > > Why would the debugger need to find a context for an edited block? > The only reason I see would be on-stack replacement, but AFAIK the > debugger doesn't do that, does it? > > > I have spotted this problem too, outside block closures. It is not every > time but it happens occasionally. > I think is some sort of bug :( > I takes away a lot of the fun... Especially when my image gets locked, no matter how much I hit the interrupt key sequence. 'Through', 'Over', 'Restart', ... it is not working nicely. Is that because of the new debugger/compiler chain? Phil > > Esteban > > > > Isn't that your case ? > > > 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> While debugging, I modify the code of the method, then accept, then >> restart. >> >> But when going back to the method in the browser, it is unchanged. >> >> What I am doing wrong or is this something other people do encounter? >> >> I didn't had this in 2.0 >> >> Phil >> > > > >

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by ClÃ©ment Bera

2014-06-03 14:09 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > It happens sometimes when you edit a blockClosure code and that the > debugger cannot find it on stack. > > > Why would the debugger need to find a context for an edited block? > The only reason I see would be on-stack replacement, but AFAIK the > debugger doesn't do that, does it? > > > I have spotted this problem too, outside block closures. It is not every > time but it happens occasionally. > I think is some sort of bug :( > Yeah I also had the problem ... Fortunately, one of the debugger implementor (that I will not name here) is working in our team right now and she may be able to fix it :-) > > Esteban > > > > Isn't that your case ? > > > 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> While debugging, I modify the code of the method, then accept, then >> restart. >> >> But when going back to the method in the browser, it is unchanged. >> >> What I am doing wrong or is this something other people do encounter? >> >> I didn't had this in 2.0 >> >> Phil >> > > > >

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by ClÃ©ment Bera

2014-06-03 13:52 GMT+02:00 Camille Teruel <camille.teruel(a)gmail.com>: > > On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > It happens sometimes when you edit a blockClosure code and that the > debugger cannot find it on stack. > > > Why would the debugger need to find a context for an edited block? > The only reason I see would be on-stack replacement, but AFAIK the > debugger doesn't do that, does it? > > I was talking about this case: DebugContext>>blockNotFoundDialog: aMethod with: aText | browser message result | message := 'Method for block not found on stack, can''t edit and continue'. [ ... ] > Isn't that your case ? > > > 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> While debugging, I modify the code of the method, then accept, then >> restart. >> >> But when going back to the method in the browser, it is unchanged. >> >> What I am doing wrong or is this something other people do encounter? >> >> I didn't had this in 2.0 >> >> Phil >> > > >

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by Esteban Lorenzano

On 03 Jun 2014, at 08:52, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, >> >> It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack. > > Why would the debugger need to find a context for an edited block? > The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it? I have spotted this problem too, outside block closures. It is not every time but it happens occasionally. I think is some sort of bug :( Esteban > >> >> Isn't that your case ? >> >> >> 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> While debugging, I modify the code of the method, then accept, then restart. >> >> But when going back to the method in the browser, it is unchanged. >> >> What I am doing wrong or is this something other people do encounter? >> >> I didn't had this in 2.0 >> >> Phil >> >

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by Camille Teruel

On 3 juin 2014, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack. Why would the debugger need to find a context for an edited block? The only reason I see would be on-stack replacement, but AFAIK the debugger doesn't do that, does it? > > Isn't that your case ? > > > 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > While debugging, I modify the code of the method, then accept, then restart. > > But when going back to the method in the browser, it is unchanged. > > What I am doing wrong or is this something other people do encounter? > > I didn't had this in 2.0 > > Phil >

June 3, 2014

Re: [Pharo-dev] Debugger weirdness

by ClÃ©ment Bera

Hello, It happens sometimes when you edit a blockClosure code and that the debugger cannot find it on stack. Isn't that your case ? 2014-06-03 13:13 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > While debugging, I modify the code of the method, then accept, then > restart. > > But when going back to the method in the browser, it is unchanged. > > What I am doing wrong or is this something other people do encounter? > > I didn't had this in 2.0 > > Phil >

June 3, 2014

Debugger weirdness

by phil＠highoctane.be

While debugging, I modify the code of the method, then accept, then restart. But when going back to the method in the browser, it is unchanged. What I am doing wrong or is this something other people do encounter? I didn't had this in 2.0 Phil

June 3, 2014