JogAmp Management Kick-Off Meeting

Dear all,

first allow me to recapitulate our almost 20 years of development here a little bit.

EDIT: I went a little bit through the whole project history
and produced: https://jogamp.org/cgit/jogl.git/about/#jogamp-history--milestones
Which also includes my deal old 'GL4Java' as resurrected here https://jogamp.org/cgit/gl4java.git/about/
and identifying it as JOGL's predecessor due to history and many concepts reused.

The second part attempts to lead-into the task how to continue the project.

Some 2003 - 2020 artifacts:
- 2003-06-06 1st public SCM entry
- 2003-10-12 First official Sun Microsystems commit
- 2009-07-09 completed git migration (sg215889 == sgothel), see also this blog
- 2009-11-10 Away from Sun Microsystems, see also this blog
- 2010-05-07 JogAmp launch ...
- 2013-07-24 1st JogAmp Release 2.0.2
- 2015-10-10 last JogAmp Release 2.3.2
- 2019-11-30 last blog entry covering Java11, support for DRM/GBM and iOS etc
- 2020-06-15 last work artifacts 2020, Bug 1398

Here is a list of a few other sentimental artifacts over the years, see my JogAmp blog
- 2011-02-20 My 2nd  JogAmp Production Home in Germany
- Resolution Independent NURBS @ GPU (the essential GraphUI toolkit)
  - 2011-04-01 First artifacts
  - 2011-10-05 Paper and software release
- 2011-08-17 Work on embedded devices and Android
- 2012-04-19 Added streaming audio/video player, JOGL on desktop & mobile status
- JogAmp on iOS
  - 2019-06-23 First iOS Visuals, running on my own custom OpenJDK build
  - 2019-07-08 Fully working NEWT + JOGL on iOS
- 2019-11-30 last blog entry covering Java11, support for DRM/GBM and iOS etc

We also had quite a few conferences
- Siggraph [2010, 2011, 2012, 2013, 2014]
- Fosdem [2013, 2014]

+++

Currently I am about to complete the MacOS 12 + 13 support for x86_64 and aarch64,
as well as bumping our SWT support to Eclipse 2022-12, i.e. 4.26.

Then we have to deliver the JogAmp Release 2.4.0, etc.

In April 2019 I created a SW Tracking Report Feature Objectives Overview,
marking all potential work I could think of, including Vulkan and completing GraphUI to a fully fledged 3D immersive UI experience.

Bottom line, lots of ups and down within the years enabling hardware acceleration.

This sub-forum is intended to debate how the project shall and can continue.

Base case is a path forward to have at least active maintenance releases for the supported platforms.

Best case would be to have (commercial) users of JogAmp from the embedded devices and desktop space
to chip in with resources, direction and sustainable funding.


If you think it is helpful, we can also have a remote meeting using Jitsi, e.g. via an ad-hoc meeting point.
 
Warm greetings,

~Sven

Hello

I've found difficult to compile everything for all supported platforms. Usually, I compile only under one of them at a time. Pushing things into Maven Central doesn't seem to be trivial, Martin seems to be a lot comfortable than me with that. My suggestions are these furthers:
- Use Gradle with Ant in order to simplify building a bit. Gradle can be used to put releases into Maven and as it can work with Ant, it doesn't force us to drop Ant especially where it does a better job. Personally, I find Maven as a build tool not flexible enough for our kind of project.
- Provide a solution to allow contributors to make test builds. For example, I need to test a tiny change in GLContextImpl, I commit into a separate branch, a CI/CD server builds JogAmp with my change, I take the JogAmp fat JAR and I use it in my TestNG unit test to ensure that my fix really works, the server runs our tests on all supported platforms too. Maybe it's already possible right now, maybe I'm missing something.
- Drive some parts of JOGL easier to modify without recompiling, for example adding renderer quirks, adding an alternative input manager (I really need relative mouse movement management for T.U.E.R)
- Support Foreign Function and Memory API, a memory segment created with it should be usable instead of a NIO buffer. It's not mandatory as you can create a NIO buffer from a memory segment in the meantime. If things go well, maybe this API will be suitable to do many things in Java without JNI.
- WebGPU, WebAssembly, Java to web transpiling... I don't promise to succeed but I'm on it.

I agree with having a meeting.

By the way, I can't update the tickets in Bugzilla, I get the following error message:
Software error:

Invalid Content-Type 'subtype' parameter at Bugzilla/BugMail.pm line 499.

For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.

Great stuff.

I believe each item is worth its own thread to discuss here in this sub-forum
and I love debating each one here.

I may also add another (provoking) one:
  - Investigate having a functional C++ API equivalent to nativewindow, newt and jogl.
    - the nativewindow/newt layer might be already solved
    - the GL profile abstraction might be already solved
    - find which part of JOGL's managed API might be useful

Bottom line, every crazy idea is surely of interest.

+++

Time for a meeting: 2022-01-26 Thursday 10am, 2pm or 6pm CET?
We could just try a time slot and see who will be there?

Cheers, Sven

It's not crazy, I vaguely remember that a developer told me several years ago that he had imitated some parts of JOGL in C++.

Just some ideas I've had in my head, presented only for reference if anyone else finds them interesting (and some of these may already exist)

- jogl build targets for only the platform independent parts, possibly just the fat-jar (relying on previously build natives)
  - allow for bugfixes/contributions from others without the full cross platform, or even without any native build environment at all

- static analyzer (SpotBugs) integration in the build, or even initial setup in eclipse to enable, I've found this invaluable in Jaamsim to increase confidence in new code changes

- emerging projects with cross-compilation out of the box to allow all platforms to be built on one machine
  - zig cc as a cross compiler for C code instead of MSVC, GCC, etc depending on platform

Harvey

Good stuff, yup.

hharrison wrote

- jogl build targets for only the platform independent parts, possibly just the fat-jar (relying on previously build natives)
  - allow for bugfixes/contributions from others without the full cross platform, or even without any native build environment at all

I would mark this w/ lowest prio, as it is not that hard to install the
mingw64 native build environment. But that's just me sitting in the woods :)

hharrison wrote

- static analyzer (SpotBugs) integration in the build, or even initial setup in eclipse to enable, I've found this invaluable in Jaamsim to increase confidence in new code changes

We once used FindBugs as well, you gave a good list and we once worked a few down.

Lately I use clang-tidy besides full warning analysis on gcc/clang for Direct-BT
and it gives at least a great expert resource of 'nagging' to debate, forcing you to 'defend' your code.
In general a very good thing for all projects and we should pick this up again
regularly - or whoever is working on this project.

hharrison wrote

- emerging projects with cross-compilation out of the box to allow all platforms to be built on one machine
  - zig cc as a cross compiler for C code instead of MSVC, GCC, etc depending on platform

I already use cross-compilation, e.g. using a GNU/Linux x86_64 host
producing targets
- android, multiple archs
- linux aarch64
It is easy to add Windows/mingw64 for linux as well and we once did it.

However, a JogAmp build has two parts
- build the blobs
- pass the tests
The latter surely requires a target platform.

In Direct-BT or jaulib, I also use GNU/Linux's user bin-fmt
utilizing the kernel's KVM for arm 32bit and 64bit.
Here I can also run a lot of unit tests.

So far I guess we could build everything cross using a GNU/Linux host
but MacOS due to their darn license stuff.
Surely something to keep in mind and 'play with'.
(With cygwin, the cross builds might be even possible on Windows)

Shameless friendly reminder - reaching out to companies using JogAmp ..
(if you are aware of commercial users not reading this forum, please inform them)

Sven Gothel wrote

....

This sub-forum is intended to debate how the project shall and can continue.

Base case is a path forward to have at least active maintenance releases for the supported platforms.

Best case would be to have (commercial) users of JogAmp from the embedded devices and desktop space
to chip in with resources, direction and sustainable funding.


If you think it is helpful, we can also have a remote meeting using Jitsi, e.g. via an ad-hoc meeting point.
 
Warm greetings,

~Sven

In case commercial users like to enjoy more maintenance and support,
probably more features etc .. please don't hesitate and contact Göthel Software e.K..
We can also help you with adoption and general work on your proprietary products using C, C++ and Java .. or whatever language you desire.

Cheers,

~Sven

I have updated our Feature Objectives Overview wiki page.

Perhaps this could be an inspiration for companies to see a use-case (for Java in general, btw).
IMHO the Graph UI on desktop and embedded is the most interesting case here,
besides video update and iOS etc.

Graph UI is meant to be an immersive UI within the 3D scene including text and UI objects, including user interaction.

This would allow an application to utilize one viewport or window, exposing the scene including the UI w/o the need for any external toolkit.

Think of an integrated QT or OpenJFX in your 2D/3D application working on desktop and embedded devices even w/o any windowing system on top of a plain console DRM/GBM as support by JOGL(EGL) and NEWT.

So far, github-sponsorship one 'buy me a coffee' $9 has been given.
While I dearly love this on a personal level,
it shows after one month that this can't be the way forward.

I removed the ugly 'Sponsor' button on the JogAmp + JOGL face, shortened the text a bit.

+++

Added 2 games to JOGL www page

Anything else?

+++

Seeking JogAmp funding or contracting efforts lead to one old and one new
party to have a very "soft" discussion.
Then there were one indirection interest, but no direct communication.
Nothing concrete.

I like to thank those who tried to make a contact,
perhaps one day it will work out and lose ends become support.
Its a long process, I know.

+++

My other angle, contracting for a remote position outside of JogAmp
also was not fruitful yet.
There must be some dirt sticking on me or something, I dunno.
In the last 2 1/2 years I had to reject a few offers .. better times I guess.

+++

^^ might look like an desperate unprofessional diary.

But why not sharing this journey here besides code and goals.
It's part of it and who knows, maybe one of you has a good idea.

What about Tidelift?

EDIT: I went a little bit through the whole project history
and produced: https://jogamp.org/cgit/jogl.git/about/#jogamp-history--milestones
Which also includes my deal old 'GL4Java' as resurrected here https://jogamp.org/cgit/gl4java.git/about/
and identifying it as JOGL's predecessor due to history and many concepts reused.

.. in this regard, what else should be added?

Now I brainstorm at least:
- Java3D
- Ardor3D
- ????

And in case you remember other important milestones .. bring it on :)

You can have a look at the few paragraphs I wrote about that in the wiki.