A logging framework (SLF4J or Java Logging) should be used to log messages. Applications using JOGAMP libraries would produce consistent messages by means of a unique controllable logging framework.
(In reply to comment #0) > A logging framework (SLF4J or Java Logging) should be used to log messages. > Applications using JOGAMP libraries would produce consistent messages by > means of a unique controllable logging framework. If you like to do so .. you may go ahead. However, no extra [external] dependency shall be created _and_ the costs [performance/footprint] shall be minimal. This is a biggy .. w/ questionable results IMHO, since we only enable this logging for DEBUG cases. You may also consider that native DEBUG code also uses stderr. Current State: All DEBUG code uses the stderr channel ..
Hi Sven Thank you for the advice. I agree with you: the processing of the entire library to replace all stderr debug output is a significant task. Only the most important messages should be logged. First, I only need to disable debug outputs produced by default. This weekend, I intend to browse the code of the JOGL library (included in my project) to have a better idea of the required work.
(In reply to comment #2) > First, I only need to disable debug outputs produced by default. There should be none, ofc. But if those still exist, it's an orthogonal issue, i.e. shall be fixed by adding the typical 'if(DEBUG) { }' while still using stderr.
(In reply to comment #3) > (In reply to comment #2) I got errors from the class FPSAnimator.
21d6cfafdc088e75981d710c672a668fddfdf298 FPSAnimator debug output on stderr shall happen only if DEBUG is enabled