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.html

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