I would like to open up a discussion with the topic OpenGL, following some considerations made in GLAbstraction.jl issue #87.
The situation with all but the core of the julia OpenGL stack is rather non-ideal. The interplay between
ModernGL.jl, GLFW.jl, GLWindow.jl and GLAbstraction.jl, is hard to figure out coming from outside with no prior knowledge of the structure.
The first two packages are pretty much perfect by themselves, all basic functionality is there and it’s clear what each of them does. This becomes a bigger problem when the latter two packages come into consideration, for example if someone would like to use some abstractions rather than the very bare functionality.
Some functions in GLWindow.jl provide constructors/wrappers around the types in GLFW.jl, also providing some extended functionality which could be used as quality of life improvements over
GLFW.jl. The trouble is that it also contains a lot of other functionality that has nothing to do with basic
OpenGL or windows/contexts as a whole.
A similar story goes for GLAbstraction.jl in regards to the ModernGL.jl package. There are certain functions/constructors/wrappers, providing very useful abstractions over the
ModernGL package, which could be perfectly bundled into an
API. Again there is a lot of functionality that wouldn’t really belong in an
API, combined with redefinitions of other structures/functions/naming schemes in GLWindow.jl which happens the other way around too.
Then there is the Reactive.jl package, which is very useful for implementing higher level functionality, but doesn’t belong on the level of an
API. It is however very much used in both
This all makes it very hard for someone to understand what he can use from what package and where the
API elements are hiding, compared with higher-level functionality.
I came to the conclusion that it would be very nice if we could bundle all the
API kind of abstractions into an
OpenGL package (name up for debate ofcourse). The question, of course, is how to exactly structure all this in a clear, useful and most importantly semi-modular way.
This is kind of the starting point that I had in mind for this discussion. To provide some starting point I have fabricobbled up a very crude structure of how I would see all of this happening. The core/basic functionality is all put into OpenGL.zip, where the things that are not there are put into a higher level package, which I didn’t have time to at least get working. Also, please understand that this is not in any way final, and I’m not in any way trying to push anything onto anyone. Aside from very very minor changes, most of the code is a 1 to 1 copy paste, meaning that I spent 0 time on the actual implementation, and praises belong to the original implementers of the aforementioned packages. It’s merely a restructure.
The idea is that the submodules are kind of stand alone, and provide some of the basic functionality. Want to use only the core
import OpenGL.CoreGL, want to also use basic windowing? add
import OpenGL.GLFW, want to use abstractions, add
import OpenGL.Abstractions, want to use higher level stuff, use the high level package.
There is the point of modularity, which is valid. Namely, it shouldn’t be necessary for someone to be able to compile
GLFW.jl to be able to use
OpenGL.CoreGL. On the other hand, as of now it seems that
GLFW.jl is the only cross-os way of providing
OpenGL contexts, making it as far as I see it the most probable tool to use. I fully favour mix-n-match functionality similar to different backends of
Plots.jl, provided there are actual working alternatives to just using
GLFW.jl. Sidenote: for the tests in both
ModernGL.jl they depend on eachother, so why not merge them.
However, as was mentioned in GLAbstraction.jl issue #87, the ModernGL.jl and GLFW.jl packages are perfect standalone packages as it is at the moment. The reason why I would put them into the same package as the
API layer, is that to me it seems nobody would not use the abstractions, if they are there, together with them. Especially when the core functionality is very directly accessible. But again, deciding upon this is exactly why this discussion exisits.
In general I lean towards more inclusive packages rather than a lot of small fragmented ones.
So to summarise the topics:
- Is an OpenGL package useful?
- Should the API-layer be included in the same package as the
- What should the general structure of the package be?
- If we would have more of a
Highlevel structure, what should be put where?
- Is it really useful to seperate the API-layer from the
Corepackage, or make them two submodules?
Please @ other people that might be concerned with the evolution of the JuliaGL stack/ OpenGL in julia.
And ofcourse Happy holidays to everyone!
EDIT1: For people interested in the refactor I provided, I annotated it using the following keys:
#Came from packageName/file.jl, where the following block of code came from.
#change:, small changes I made, mainly namingschemes, not many of those,
#question:, questions/observations/comments about certain code (why, is this used, what does it do)