Release 2.4.0 Progress ..

Copied from this thread.

+++

 Preliminary Status Update (all things pushed to git)

- Build System
  - Using OpenJDK 17
  - Updated toolchains for MacOS + Windows
  - Minimum MacOS SDK Version is 11

- Windowing Toolkits
  - AWT OK
  - SWT 4.26 OK
  - NEWT OK

- Build OK and testing (WIP, most OK) on
  - GNU/Linux x86_64
  - Windows 10
  - MacOS x86_64, aarch64

- Merged 3 patches
  - Julien's GLProfile GL2 (manual)
  - SWT 4... patch (pre 4.26)
  - GLX extension patch

- JogAmp Server
  - Fixed git protocol access (you can close/pull via git: again)
  - Server was updated a while ago to Debian 11

TODO:
- Bugzilla still not fully working (reported by Julien)
- Complete testing across platforms, i.e. passing our unit tests.
- Release

My test/build nodes are up an running again,
naturally the Windows and MacOS machines were most annoying :)

Qualifying the unit tests across machines ..,
then I will see to our Jenkins machinery.

~Sven

Just some raw figures ..

MacOS Pbuffer has been disabled for MacOS > 10.14

A couple tests have been disabled due to prolonged hang.

In total, above disabled and failed tests should be analyzed and fixed.

Windows 10, x86_64,
=============
- Platform: WINDOWS / Windows 10 10.0 (10.0.0), amd64 (X86_64, GENERIC_ABI), 6 cores, littleEndian true
- OpenGL 4.6 (Core profile, arb, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 391.35
  - GL_RENDERER: GeForce GTX 460/PCIe/SSE2
- Java Version: 17.0.5 (17.0.5u0), VM: OpenJDK 64-Bit Server VM, Eclipse Adoptium

jogamp@jogamp01 ~/JogAmp/jogl/make
$ scripts/check-junit.sh ../build-win64

Results of ../build-win64/test/results

number of junit classes
    291    2619   88774

number of passed junit classes - failures
    290    2610   88484

number of passed junit classes - errors
    290    2610   88482

number of failed junit classes - failures
      1       9     290

number of failed junit classes - errors
      1       9     292

failed junit classes - failures
com.jogamp.opengl.test.junit.newt.TestDisplayLifecycle01NEWT

failed junit classes - errors
com.jogamp.opengl.test.junit.jogl.swt.TestSWTAccessor03AWTGLn

+++

Debian 11/Linux, x86_64,
===============
- Platform: LINUX / Linux 5.16.18 (5.16.18), amd64 (X86_64, GENERIC_ABI), 8 cores, littleEndian true
- OpenGL 4.6 (Core profile, arb, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6 (Core Profile) Mesa 20.3.5 [GL 4.6.0, vendor 20.3.5 ((Core Profile) Mesa 20.3.5)]
  - GL_RENDERER: Mesa Intel(R) UHD Graphics (CML GT2)
- Java Version: 17.0.4 (17.0.4u0), VM: OpenJDK 64-Bit Server VM, Debian

jogamp@jogamp07:~/projects/JogAmp/jogl/make$ scripts/check-junit.sh ../build-x86_64

Results of ../build-x86_64/test/results

number of junit classes
    291    2619   88768

number of passed junit classes - failures
    291    2619   88768

number of passed junit classes - errors
    288    2592   87810

number of failed junit classes - failures
      0       0       0

number of failed junit classes - errors
      3      27     958

failed junit classes - failures

failed junit classes - errors
com.jogamp.opengl.test.junit.jogl.acore.glels.TestGLContextDrawableSwitch10NEWT
com.jogamp.opengl.test.junit.jogl.acore.glels.TestGLContextDrawableSwitch11NewtAWT
com.jogamp.opengl.test.junit.newt.parenting.TestParenting01dAWT

+++

MacOS 12.6.2, x86_64
================
- Platform: MACOS / Mac OS X 12.6.2 (12.6.2), x86_64 (X86_64, GENERIC_ABI), 4 cores, littleEndian true
- OpenGL 4.1 (Core profile, arb, compat[ES2, ES3], FBO, hardware) - 4.1 INTEL-18.8.5 [GL 4.1.0, vendor 18.8.5 (INTEL-18.8.5)]
  - GL_RENDERER: Intel Iris OpenGL Engine
- Java Version: 17.0.5 (17.0.5u0), VM: OpenJDK 64-Bit Server VM, Eclipse Adoptium

jogamp03:make jogamp$ scripts/check-junit.sh ../build-macosx

Results of ../build-macosx/test/results

number of junit classes
     291    2619   93705

number of passed junit classes - failures
     288    2592   92742

number of passed junit classes - errors
     287    2583   92426

number of failed junit classes - failures
       3      27     963

number of failed junit classes - errors
       4      36    1279

failed junit classes - failures
com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2NEWT5
com.jogamp.opengl.test.junit.jogl.swt.TestSWTBug643AsyncExec
com.jogamp.opengl.test.junit.newt.event.TestParentingFocus02SwingAWTRobot

failed junit classes - errors
com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2SWT3
com.jogamp.opengl.test.junit.jogl.demos.es2.swt.TestGearsES2SWT
com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs
com.jogamp.opengl.test.junit.jogl.swt.TestSWTBug643AsyncExec

+++

MacOS 13.1, aarch64
================
- Platform: MACOS / Mac OS X 13.1 (13.1.0), aarch64 (ARM64, EABI_AARCH64), 8 cores, littleEndian true
- OpenGL 4.1 (Core profile, arb, compat[ES2, ES3], FBO, hardware) - 4.1 Metal - 83 [GL 4.1.0, vendor 0.0.0 (n/a)]
  - GL_RENDERER: Apple M1
- Java Version: 17.0.5 (17.0.5u0), VM: OpenJDK 64-Bit Server VM, Eclipse Adoptium

kaiwlan:make jogamp$ scripts/check-junit.sh ../build-macosx/

Results of ../build-macosx//test/results

number of junit classes
     291    2619   93705

number of passed junit classes - failures
     287    2583   92448

number of passed junit classes - errors
     285    2565   91783

number of failed junit classes - failures
       4      36    1257

number of failed junit classes - errors
       6      54    1922

failed junit classes - failures
com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2NEWT5
com.jogamp.opengl.test.junit.jogl.swt.TestSWTBug643AsyncExec
com.jogamp.opengl.test.junit.newt.event.TestNewtKeyCodeModifiersAWT
com.jogamp.opengl.test.junit.newt.event.TestNewtKeyCodesAWT

failed junit classes - errors
com.jogamp.opengl.test.junit.jogl.acore.TestAWTCloseX11DisplayBug565
com.jogamp.opengl.test.junit.jogl.acore.TestSharedContextVBOES2SWT3
com.jogamp.opengl.test.junit.jogl.awt.TestBug1245JTabbedPanelCrashAWT
com.jogamp.opengl.test.junit.jogl.demos.es2.swt.TestGearsES2SWT
com.jogamp.opengl.test.junit.jogl.swt.TestGLCanvasSWTNewtCanvasSWTPosInTabs
com.jogamp.opengl.test.junit.jogl.swt.TestSWTBug643AsyncExec

+++

Hi Sven,

Thanks for notifying us, that is great to see you back on stage :)

Few things that you may find useful to add to the final release
- Someone provided a bug fix on Newt windows crashing at startup on macOS. He/she pushed this on my JOGL repo.
- I tested the TextRenderer improvements that lie on a pending merge request on your github repo. I can say it handles memory more efficiently and also that the text looks greater (without blurry effect on non HiDPI screen).

Notice
- When I upgraded JOGL to support Apple M1, I encountered failing tests relating to NEWT. I was not able to fix this so I kept the console output info here. If you want to see the details, I uploaded test results here.
- When testing NewtCanvasAWT inside Jzy3D, I encountered weird lags on macOS when using mouse drag for camera rotation. I thought it could be related with the above mentioned issues. That could equally be related to my integration of Newt in Jzy3D. If you want, I can perform additional tests on your release.

You seam to also encounter failing tests in your build. Is there's a way we could help you?

Last, you may find useful to see the compatibility matrix and workaround index I made available here when I build the RC4 for Apple M1.

Cheers,

Martin

Martin wrote

Hi Sven,

Thanks for notifying us, that is great to see you back on stage :)

Thank you :)

Martin wrote

Few things that you may find useful to add to the final release
- Someone provided a bug fix on Newt windows crashing at startup on macOS. He/she pushed this on my JOGL repo.

- I figured the async context update on main thread 
- I removed the HIToolbox usage for key-symbol, since this framework is no more documented and a SIGSEGV behavior can't be accepted even if potentially used wrong.

Martin wrote

- I tested the TextRenderer improvements that lie on a pending merge request on your github repo. I can say it handles memory more efficiently and also that the text looks greater (without blurry effect on non HiDPI screen).

This is a rather long long debate.
- Author was contracted by military etc and even though, I had a convo with them back then
  - Point is they still used AWT
  - They didn't help with the merge, fix things and pass unit tests
  - Then they were gone .. (commercial/gov interest gone I assume)
- I would be interested if this will be restructured
  - Drop AWT
  - Make it as a simple stroke curve renderer (like GraphUI)
  - Then we can have two implementations
This could be a nice little contract on its own, i.e.
having two implementations of same API and fix GraphUI's font triangulation.

Martin wrote

Notice
- When I upgraded JOGL to support Apple M1, I encountered failing tests relating to NEWT. I was not able to fix this so I kept the console output info here. If you want to see the details, I uploaded test results here.
- When testing NewtCanvasAWT inside Jzy3D, I encountered weird lags on macOS when using mouse drag for camera rotation. I thought it could be related with the above mentioned issues. That could equally be related to my integration of Newt in Jzy3D. If you want, I can perform additional tests on your release.

You seam to also encounter failing tests in your build. Is there's a way we could help you?

Last, you may find useful to see the compatibility matrix and workaround index I made available here when I build the RC4 for Apple M1.

Cheers,

Martin

I saw your work over there, great job.

Let's discuss the details of possible remaining issues step by step,
best via our bugzilla (need to fix its setup).
However, I would say .. JOGL should be back to usable by now,
also on MacOS and SWT 4.26.

For now, I need to bring back our jenkins stuff and the build :)

Maybe a great time to have a public debate next week?
As always, all of this works would need funding ... see this post,
but we can and shall plan our way forward.

Thank you!

In my humble opinion, the TextRenderer improvements tested by Martin are valuable as is even though I stopped using the legacy text renderer several years ago.

I fixed a few bugs
- A hard one re MacOS + JAWT threading operation
- Workaround for MacOS + SWT (w/o AWT) issues
- ... etc ...

Jenkins is sort of operable and builds (on reduced target set as visible).

The Jenkins update removed the nice 'Aggregated Artifact' feature,
so I need to change a few lines in our aggregation scripts
to produce the combined result.

...

It's an excellent piece of news. "win7-x86_64-nvida", spelling mistake?

Do you know the root cause of the failure on TestDisplayLifecycle01NEWT under Windows?

Will triage the remaining bugs soon esp Windows GlueGen + JOGL, then install OpenCL where missing so it won't fails.

The naming scheme of node labels has typos, yes.

I also should remove the GPU name and OS version details ,
as they no more match actual machines today.
Maybe I do this before resolving the build aggregation.

Sven Gothel wrote

The naming scheme of node labels has typos, yes.

I also should remove the GPU name and OS version details ,
as they no more match actual machines today.
Maybe I do this before resolving the build aggregation.

Jenkins node-names (axis labels) are cleaned up,
including renaming old builds etc (no loss, but removed dropped platforms).

The Windows GlueGen failures (build 948)
surely had its magic ...
See fixed for build 949,
which includes my cpptask.jar changes,
finally writing out dynamic libraries as NAME.dll under Windows:

Add support for Windows dynamic library target, i.e. NAME.dll instead of libNAME.dll.

This is now required when linking a GLUENAME1.dll to TOOLNAME1.dll,
where GLUENAME1.dll is loaded via System.loadLibrary() and TOOLNAME1.dll required to be found.
Might be a change in the current ming64 toolchain.

Before this change, the library name 'libTOOLNAME1.so' was written into `libGLUENAME1.so`
and hence could not be found (manually renamed to a dll name).

Now we can also drop the manual rename of libNAME1.so -> NAME1.dll, finally :)

Good, one more regression on Windows in jogl ..

Goody, the aggregation is next, so we can have builds to test and release.

Sven Gothel wrote

The Jenkins update removed the nice 'Aggregated Artifact' feature,
so I need to change a few lines in our aggregation scripts
to produce the combined result.
...

First promoted aggregation result:

https://jogamp.org/deployment/archive/master/gluegen_950-joal_668-jogl_1514-jocl_1154/

Currently active build nodes/targets:
  android-arm64 linux-arm64 linux-x86_64 macos-x86_64 windows-x86_64

Where macos-x86_64 includes arm64 (or aarch64)

Quick bringup test
  wget https://jogamp.org/deployment/archive/master/gluegen_950-joal_668-jogl_1514-jocl_1154/fat/jogamp-fat.jar
  wget https://jogamp.org/deployment/archive/master/gluegen_950-joal_668-jogl_1514-jocl_1154/fat/jogamp-fat-test.jar
  java -jar jogamp-fat.jar
  java -jar jogamp-fat-test.jar

Sven Gothel wrote

Currently active build nodes/targets:
  android-arm64 linux-arm64 linux-x86_64 macos-x86_64 windows-x86_64

Where macos-x86_64 includes arm64 (or aarch64)

Quick bringup test
  wget https://jogamp.org/deployment/archive/master/gluegen_950-joal_668-jogl_1514-jocl_1154/fat/jogamp-fat.jar
  wget https://jogamp.org/deployment/archive/master/gluegen_950-joal_668-jogl_1514-jocl_1154/fat/jogamp-fat-test.jar
  java -jar jogamp-fat.jar
  java -jar jogamp-fat-test.jar

^^ please test a little

I will refine the aggregate and promotion scripts, then we can have a release
if there are no pressing issues.

Tested on Windows x64 under jdk 8 and jdk 17.

We've requested some testing from our users on MacOS under x86 and aarch64. We will report back as we receiver reports of success/failure.

Out of curiosity, will the 32-bit windows versions be returning in these builds? We still get a surprising number of downloads for that version.

Harvey

hharrison wrote

Tested on Windows x64 under jdk 8 and jdk 17.

Great, so no hick up here.

hharrison wrote

We've requested some testing from our users on MacOS under x86 and aarch64. We will report back as we receiver reports of success/failure.

Very good.

hharrison wrote

Out of curiosity, will the 32-bit windows versions be returning in these builds? We still get a surprising number of downloads for that version.

I reduced the target matrix to see who is complaining :)

If nobody complains it will be left out,
so seems like it windows 32bit will be back in then?

Any other platform with a big user amount?

Hi Sven,
Thank you for your work. I am busy right now but I could test this in February on Jzy3D.
Martin

That is OK Martin - by this week I will release 2.4.0 as-is.
2.4.0 will hopefully not be the end-of-all-changes :)

Here is a bugzilla query for 2.4.0, as I pushed open things to 2.5.0
https://jogamp.org/bugzilla/buglist.cgi?list_id=3050&query_format=advanced&version=2.4.0

(still have some 2.4.1 - 2.4.3 issues open)

The wiki/bugzilla sites like
https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Objectives_for_the_release_2.4.0
are still lagging.
Probably need to update the bugzilla/wiki plugin or something.
Last year (?) I checked there was little update on this sadly.

I love bugzilla's tree structure and all that, unmatched by the 'sexy UI'
of others likes gitlab issue tracker etc.
But this is a long story .. having tested the future bugzilla 'secret' work of mozilla
back then .. but bugzilla got no proper funding either.

Yes, lots of construction zones still exist.

Regarding Windows 32-bit support ..

Microsoft Windows 10 Minimum Hardware Requirements (posted 2021-11-29) 
page 30: Section 3.0 - Minimum hardware requirements for Windows 10 for desktop editions

Beginning with Windows 10, version 2004, all new Windows 10 systems will be required to use
64-bit builds and Microsoft will no longer release 32-bit builds for OEM distribution. This does
not impact 32-bit customer systems that are manufactured with earlier versions of Windows 10;
Microsoft remains committed to providing feature and security updates on these devices,
including continued 32-bit media availability in non-OEM channels to support various upgrade
installation scenarios.

and then: Windows 10, version 2004 end of servicing (all editions) on 2021-12-14

perhaps I stick with dropping 32bit support then.
Problem would be to even validate such machines due to no software updates etc.
And running a java-32bit application on top of a 64-bit Windows hardly makes any sense.

However, if we get strong reasoning or even funding (duh!) - we can add any important platform.