* WORK IN PROGRESS * This post will be updated over the next days with additional info and results of the discussion that will follow.
So, it's time to start talking about LWJGL 3.0. For those that haven't heard it before, this next major release will not be backward compatible with the current one. The plan is to clean up some legacy stuff and improve the library design so that we can support features that are either impossible right now or too hard to implement. Any feedback on the proposed changes or suggestions for additional ones will be very welcome.
First, lets get something clear up front. The static nature of the AL/CL/GL bindings, which sets LWJGL apart from similar libraries, will NOT change. This means that when migrating to 3.0, required changes will be quite limited. Everything else is subject to discussion (context management, input APIs, utility classes, etc).
[ High Level Goals ]
- Migrate the codebase to Git and possibly host on Github. The existing codebase will remain on SVN/Sourceforge for critical/minor fixes only.
The main incentive is to attract more contributions to LWJGL. Git is more popular than SVN, hence more likely to be already installed on a potential contributor's environment, removing one extra step from the process. It operates
more efficiently than SVN and allows for cheap branching, essential for exploring new features. Github is a great hosting environment and free for OS projects. Even though alternatives exists, it's the most mature and popular one. The brilliant pull request automation is another feature that will hopefully attract more contributions.
- Improve context management. Allow LWJGL to more easily use external contexts. Better support multiple contexts.
The goal here is to expose much more of the functionality currently hidden behind Context and Drawable. The critical change for this to happen is to make the native layer much lighter; we need to transform it to a simple binding layer, like the GL extensions, and move all the complicated functionality to Java code. In the process, we'll expose the low-level APIs so that advanced users will be able to take over context management and do things we didn't predict or didn't have the time to implement.
- Fully expose vendor-specific and OS-specific extensions, just like we do with normal GL extensions (with automated generation with the extension generator).
Similar to the above goal, this will allow users to easily explore advanced features (multi-GPU solutions, video I/O, etc).
- Move the native windowing system to an independent package. Remove any dependencies between the windowing system and GL contexts. Make windowing system pluggable.
Besides the obvious cleanup that is required, this is probably the most complicated problem we have. Discussion below.
- The native Display should be OOfied to allow for multiple native windows.
The benefit for this is arguably limited, but since we're refactoring everything, it shouldn't be too hard to accomplish.
- Remove legacy features: pbuffers, AWT integration, the debug jar, the util package, deprecated functions.
pbuffers are obsolete, AWT/Swing are basically dead (JavaFX is everywhere we want LWJGL to run anyway), the debug jar is useless since ARB_debug_output (and well, there are
other debug tools too). I guess we should talk a bit about the util package, but imho it belongs to a higher-level library than LWJGL.
[ Technical Issues ]
- Bump minimum required JRE version to 6.0. Or maybe 7.0?
- Bump minimum required GL version from 1.1 to 2.0 (or 2.1?). This will allow us to unify the GL11..GL20 classes for convenience.
- The extension generator uses annotation processing through apt, which has been deprecated since Java 6 and removed in Java 8. It needs to be updated to use javax.annotation.processing instead. Another option is to re-implement the whole thing without annotations; the current code is very powerful but also a nightmare to understand and maintain. There are easier/cleaner ways to do what it does. This of course will require a different representation for the extension templates, something other than Java interface + annotations.
- I'd be nice to remove the license message that exists in every LWJGL source file. We could replace it with something much more compact, like a
link to the actual license.
- Support for OpenGL ES should be cleaned up and no dependencies should exist between ES and desktop GL. Improve the build process and provide pre-built binaries if possible.
[ Other features (not critical for 3.0) ]
- Provide "profile-based" GL classes. An example would be a GLCore class that contains all the functions/tokens from 1.1 to 3.1 (or 3.2), without the deprecated stuff.
- Allow building LWJGL with extension filters. For example, a user might want a light build without any vendor-specific extensions, only core + ARB/EXT extensions.
- Implement JavaFX integration if technically possible.
[ Discussion ]
We have two major issues: What to do exactly about the windowing system and how to organize the library in general.
- Windowing System
There's the current solution and there are the alternatives. Obviously, what we have now is years of battle-tested code, it works well but it's also a THE major headache to maintain and improve. The multi-platform nature of the code and the fact that we're targetting Java developers has made it very hard over the years to find reliable people to contribute changes to the windowing system. On the other hand, having our own solution is an obvious huge benefit, so far we have never depended on a third-party for new features and fixes.
Alternatives exist. The JogAmp people seem to have done a good job with NEWT, though I haven't explored their code yet and am not sure if it covers everything we need. JavaFX is getting fully open sourced soon (last I heard was January?) and its Glass Windowing Toolkit is another solution. Though, we're not sure how full the open sourcing will be and if we'll be able to use it, both for technical and licensing reasons. Then there are
various C/C++ based cross-platform windowing toolkits we could bind to. Again, we'd need to explore and choose a solution that fits our needs.
To me it seems that the best way forward would be to abstract away the windowing system. It would take too much time to decide and commit to a single solution. It's better to go through the pain of hidding the current solution behind an interface and enable pluggable windowing systems.
- Library Organization
A few issues here:
1. How to handle the util package and other utility classes. I would like to see a more clean separation between what's essential and what's an utility. The extreme would be to move everything out of LWJGL and create a separate library (maintained either by us or a third-party if there's interest) that takes care of simplifying people's life. This library would probably get richer than what we currently have, a propery vector lib, shader utilities, etc. Personally I would happily contribute to such a library (I got a lot of stuff hanging around that I use in my various projects). LWJGL would only keep the absolutely basics, like the BufferUtils class.
2. There's plenty of duplicated code in LWJGL that we haven't eliminated so far in the name of proper encapsulation (e.g. package private classes) or maybe safety. I'm tired of this bullshit tbh and I plan to just make stuff public and reusable. For where this code will reside we have 2 options: a) Create an "org.lwjgl.impl" package and b) Create a package that doesn't start with "org.lwjgl", equivalent to the com.sun or com.oracle packages in the JRE. In either case the message to the user would be: "don't care about what's in here, it's only stuff we use to implement the library". I've seen both ways in other projects and I personally don't care what we choose. Let me know if anyone has a preference either way or maybe a package name suggestion.
3. Deployment and modularity. Depending on what we decide with the windowing toolkits, the util package and the cleanup of dependencies in general, we might want to revisit how we build and deploy the library. Continue with one fat jar or split it up a bit?