Posted by Sven Gothel on Feb 09, 2024; 11:05am
URL: https://forum.jogamp.org/Corrupted-frame-or-transform-Mac-OSX-OK-on-win-linux-tp4043303p4043306.html

Tobi Delbruck wrote

Hi Sven,Thanks for instantaneous response. Yes, we have a discretionary budget for some critical software support. Please write me to arrange a contract.

Sounds great, will send you an email. Some hope left to keep things going :)

...
I currently develop jAER via single dropbox on windows/linux/mac in netbeans and that is now I made the videos that I uploaded (with VNC to the mac mini) so it is pretty easy to compare and debug.

Git is preferred, but using some side-channel for media exchange is always helpful ofc.

I can try to write a standalone project that exposes this bug but that will take me a few days.

Depending on the support outcome, I will dive into it as-is.

Otherwise I can ask you for a recommendation: Should I change from using top level GLCanvas to using top level GLWindow? Could that possibly affect this problem? I'm totally clueless about the inner working and don't even know what NEWT stands for or what is the role of jogamp and jogl. We began with GLCanvas and it works wonderfully for us except on Mac OSX.

In general I am not necessarily a friend of 'change things', i.e. leave a winning team.
However, depending on your UI requirements etc (the only reason for AWT/Swing) .. we might find
a path forward away from it. NEWT in general is more reliable so replacing the UI toolkit
could end up in a more modern and sane solution. That is the whole purpose of Graph/GraphUI,
our out-of-the-box UI solution, see https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview#Graph
(yes, it is work-in-progress looking for funding etc etc, but I keep digging)

For this task here however, I would first like to fix it as-is
and leave the discussion to a future path forward open,
not pushing nor enforcing anything.

One more thing: This problem only seems to appear in the 2d rendering pipeline: jAER's 3d rendering of the event sensor events doesn't seem affected. Our 2d rendering pipeline uses 2D textures to render the different camera outputs (event/frames/annotation). This suggests to me that the problem might be related to our texture handling code in https://github.com/SensorsINI/jaer/blob/master/src/net/sf/jaer/graphics/ChipRendererDisplayMethodRGBA.java

That is very helpful, thank you!

Laters,

~Sven