Fix GL profile handling for JOGL

[javagl]

JOGL has an infrastructure for selecting the "GL profile" that should be used. This is built around the GLProfile class (see https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/GLProfile.html ).

Right now, the selection of the profile is done as follows in the GltfViewerJogl class:

    GLProfile profile = GLProfile.getMaxProgrammable(true);
    logger.config("GLProfile: " + profile);
    
    GLCapabilities capabilities = new GLCapabilities(profile);
    capabilities.setNumSamples(2);
    capabilities.setSampleBuffers(true);
    
    glComponent = new GLCanvas(capabilities);

So I'm using the highest programmable profile. This will usually be a GL3 or GL4 profile on modern PCs.

The crucial point is:

If the returned profile is only a core profile, and not a "backward compatibility" profile like GL3bc, then the attempt to compile a shader that does not contain any #version information may easily cause an error during the compilation.

This was the reason for opening KhronosGroup/glTF#587 , caused problems in #11 (comment) and has already been reported elsewhere.

I never had this problem on the PCs that I tested it with, but I'm rather limited to NVIDIA/Windows right now: It seems to be related to combinations of the graphics card, driver version and operating system, but I don't have more specific information here.

In any case, I have to find a solution for that.

When this problem was reported the first time, I made the helpless attempt to solve it by inserting the following:

    if (!vertexShaderCode.contains("#version"))
    {
        logger.warning(
            "Inserting GLSL version specifier in vertex shader code");
        vertexShaderCode = "#version 120\n" + vertexShaderCode;
    }

Of course, this looks like a crude hack, but it could solve the issue - at least until KhronosGroup/glTF#587 is addressed.

The less hacky but possibly more difficult option could be to select the GLProfile manually: I could obtain all available GLProfile values, and pick the highest one for which a ...bc (backward compatibility) version exists. But even then: What if there simply is no such profile? I'm afraid that the hack of inserting the #version will be necessary at least as a last resort...

---

Considering that the version number is still 0.0.0, and the releases are still "alpha" releases, I will insert this workaround for the next release, and hope that it resolves this issue.

[javagl]

Some debugging information for the profile handling has been added in debd179.

More importantly, an attempt for a workaround for the missing shader version numbers has been added in 6b5c586

I'll leave this issue open until it becomes clearer whether this solves the problem of compilation errors for non-backward-compatible GL profiles in JOGL. I cannot test this on my current hardware. Others have reported that it basically worked, but I'll wait for further confirmation.