May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OpenGL 3.0+

by Ronie Salgado

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(a)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(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. >> >> > >

May 31, 2014

Re: [Pharo-dev] GPU accelerated GUI

by Hilaire Fernandes

We could try to organize a task force on that matter. I will try to submit some proposals later, but now I want to prepare a delicious cake. Hilaire Le 31/05/2014 10:48, ClÃ©ment Bera a Ã©crit : > The second thing is that BitBlt is slow for 2 reasons: it is bit based > and not vector based and its implementation half in the VM half in the > image forces to copy a huge number of bits that could be avoided > > So the answer is that you need to contribute to the refactoring of > Morphic or to Athens. > > GUI hardware acceleration is clearly not the problem yet. > -- Dr. Geo http://drgeo.eu

May 31, 2014

github metacello pero and jenkins matrix builds

by Yuriy Tymchuk

Hi guys, So Iâm using this fancy metacello github urls, like: github://<user>/<project>[:<branch>|<tag>|<SHA>][/<path>] and some of my Jenkins matrix builds are randomly failing with: Error: /tmp/github-UkoRenrakumaster.zip already exists anyone has an idea how to solve this? Uko

May 31, 2014

github metacello pero and jenkins matrix builds

by Yuriy Tymchuk

Hi guys, So Iâm using this fancy metacello github urls, like: github://<user>/<project>[:<branch>|<tag>|<SHA>][/<path>] and some of my Jenkins matrix builds are randomly failing with: Error: /tmp/github-UkoRenrakumaster.zip already exists anyone has an idea how to solve this? Uko

May 31, 2014

Re: [Pharo-dev] Regular Hangouts

by phil＠highoctane.be

Plan them in google+ pharo community. It worked well with the Squeak mondays. Phil Le 31 mai 2014 08:11, "stepharo" <stepharo(a)free.fr> a Ã©crit : > Hi guys > > I would really like to launch regular hangouts because I would like to > build more contacts inside the community. > I was thinking about every two weeks around 17h-18h > > What do you think? > > Stef > >

May 31, 2014

Re: [Pharo-dev] GPU accelerated GUI

by ClÃ©ment Bera

2014-05-31 8:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > Would be good that this guy posts here > because I do not have this slack on my machine. > > > darrinm wrote >> >>> On my Mac, Pharo's UI performance (e.g. window dragging, scrolling, any >>> kind of animation) is quite a bit less than the rest of the system. I >>> expect high frame rates for such basic things. It impacts everything I do >>> and makes me sad. >>> >>> I'm still learning and would like to know: >>> >>> 1) Is this also the case on Linux and Windows? >>> >> Yes 2) I'm reading that Pharo's GUI is not hardware accelerated. Is this the >>> primary issue with UI performance? >>> 3) If so, is work to incorporate hardware acceleration in progress? >>> 4) If so, how can I help?! >> >> There are different issues there. One is that the Morphic-based UI is slow. You can see it by using the old MVC instead of Morphic which goes faster. Recently Morphic got slower on Pharo and it is now slower than in Squeak. It may be due to refactoring on Morphic in order to get it better, it may not be. I guess this is temporary. The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided So the answer is that you need to contribute to the refactoring of Morphic or to Athens. GUI hardware acceleration is clearly not the problem yet. Clement > >>> - darrinm >>> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/GPU-accelerated-GUI- >> tp4760898p4761007.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> > >

May 31, 2014

Zero Conf in windows CI

by Guillermo Polito

Hi guys! I'm trying to configure a windows (7-32bits) slave to run DBXTalk tests :). I've had a loooot of troubles already trying to configure right mingw and get it to compile C, but I succeeded. Now, I'm trying to get it run tests in Pharo, but I have problems with ZeroConf and probably temp directories. The log is here: https://ci.inria.fr/dbxtalk/job/DBXTalk-OpenDBXDriver-Mysql/PHARO_VERSION=3… In summary, I have the following output: Downloading the latest 30 Image: http://files.pharo.org/image/30/latest.zip Access denied - IMAGE.QGJEMX File not found - -NAME The *access denied* I think is from the rm -rf of the temp directory, because the temp directory is created in the workspace and the image file is there and unzipped. The *File not found* looks like coming from the find. Maybe I'm lacking some environment variables I didn't configure... I tried comparing my slaves with the ones used in Pharo and I didn't take it much further. Additionally, if I connect to the slave through remote desktop (:puke:), and try to execute the zero conf script with the same user, on the same folder from a msys console, I have no errors. Maybe someone has an idea? :) Thanks a lot, Guille

May 31, 2014

Re: [Pharo-dev] Regular Hangouts

by Yuriy Tymchuk

Sounds interesting On 31 May 2014, at 11:40, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I would really like to launch regular hangouts because I would like to build more contacts inside the community. > I was thinking about every two weeks around 17h-18h > > What do you think? > > Stef >

May 31, 2014

Re: [Pharo-dev] RBSmalllintChecker>>checkClass:

by Yuriy Tymchuk

On 31 May 2014, at 11:24, stepharo <stepharo(a)free.fr> wrote: > >> Hi guys. >> >> I have 1 important question about RBSmalllintChecker>>checkClass: >> >> In Pharo 2, implementation performs: >> >> environment definesClass: aClass >> >> while in Pharo 3 itâs: >> >> environment includesClass: aClass >> >> This means that in Pharo 3 we check classes that are not defined in the environment but only contain classes which environment extends. Is this correct? > > No idea. > Did you check the implementation of defines and includes? > Yes, it havenât changed from Pharo 2 to Pharo 3. #definesClass: checks if a package includes class, while #includesClass checks additionally if package includes extensions to this class. Uko

May 31, 2014

Re: [Pharo-dev] GPU accelerated GUI

by stepharo

Would be good that this guy posts here because I do not have this slack on my machine. > darrinm wrote >> On my Mac, Pharo's UI performance (e.g. window dragging, scrolling, any >> kind of animation) is quite a bit less than the rest of the system. I >> expect high frame rates for such basic things. It impacts everything I do >> and makes me sad. >> >> I'm still learning and would like to know: >> >> 1) Is this also the case on Linux and Windows? >> 2) I'm reading that Pharo's GUI is not hardware accelerated. Is this the >> primary issue with UI performance? >> 3) If so, is work to incorporate hardware acceleration in progress? >> 4) If so, how can I help?! >> >> - darrinm > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761007.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

May 31, 2014