LWJGL: Random direction thoughts

@kappa: I missed your post earlier. It may not sound like it but we’re pretty much on the same page…“worse-is-better”. Focus on initial core functionality, any required support and avoid feature-creep-itis.

I’m just tossing out ideas and seeing what people think. Is feature-X potentially core, utility, 3rd party or WTF? If core does it make sense to do it now (low risk & dev-time…and not too many of these to keep from getting sick)?

Example: I think that “CPU local” is WTF…but it’s a feature I can’t imagine ever using. On the flip side knowing if those 4 intrinsic methods are backed by an opcode is a potential for now (as popcount IS used in a support function). Of course LWJGL direct usage of that call will never amount to anything but if someone were to use it for variable length coding, in a codec, etc…then the picture changes quite a bit. Low risk, dev-time and they can’t do themselves in java.

Even thought most of these features are “niche”…it doesn’t really matter. The target is really library writers (including higher level APIs) and advanced users.

On building custom versions: I’m ignoring people willing to go there and/or write direct native code. All of this is pretty much moot for people both able and willing to do so.

Nothing to do with version 3…what’s going on with code like this (which is all over the place):


/**
 * @return Number of buttons on this mouse
 */
public static int getButtonCount() {
  synchronized (OpenGLPackageAccess.global_lock) {
    return buttonCount;
  }
}

It’s 7 year old code related to AWT interop. Most horrible stuff in the LWJGL codebase are related to it.

Is the plan for 3.x to yank this kind of stuff? (I’ve vote for yes)

Absolutely. Thread safety responsibility is being moved from the library to the user, where appropriate (which is virtually everywhere). There’s no plan to have AWT interop in LWJGL 3 and any other kind of interop (JavaFX, SWT, etc) will be strictly “non-core”/optional functionality.