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.
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 <[email protected]
<mailto:[email protected]>>:
Darrin Massena wrote:
Thanks for all the great info Ronie!
On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado
<[email protected] <mailto:[email protected]>> 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.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
<[email protected] <mailto:[email protected]>>:
darrinm wrote
> Oh, and NBMacGLConstants is lacking necessary
constants. Is it manually
> created or generated somehow?
>
> - darrinm
