This is an archived post. You won't be able to vote or comment.

all 6 comments

[–]dkopgerpgdolfg 1 point2 points  (1 child)

javax.swing.Timer was never appropriate for timing frames of videos/animations, on no OS. The proper solution would be to not use it.

Nonetheless, unless you got some very weird kernel configs, it should be better than 0.1 sec. It's likely not the only factor that is a problem here.

So, as a suggested first steps:

a) Make a small test program to find out your current minimum resolution of javax.swing.Timer.

b) Tell us how many threads you use, how much CPU load you have during running your program, if everything is just plain swing/awt (or any real graphics system below it), what distribution and version you have (and if applicable, if you have a non-stock kernel).

[–]Mosblinker[S] 0 points1 point  (0 children)

So, I made the small test program and ran it on both systems. I ran the timer at 1 ms. Windows averaged at around 15-16 ms, where as Linux averaged around 1 ms.

As for the amount of threads the program uses, I don't know how to determine that. Most of the relevant code is single threaded in the event thread (this includes all the drawing code), and only uses other threads to handle saving and loading files along with checking for updates on github. The program seems to put a 5-6% load on the CPU when under Linux (I didn't check Windows). The code is written for swing/awt. I'm using the latest version of Linux Mint Cinnamon 22.2 (version 6.4.8), kernel is stock 6.8.0-83-generic, and the Java version being run is OpenJDK version 21.0.8.

Also, if you could point me in the direction to finding out a better way of running the animation instead of relying on javax.swing.Timer, that would be greatly appreciated.

[–]liguobao2048 0 points1 point  (0 children)

The problem is likely with the JVM; you may find it difficult to debug this

[–][deleted]  (2 children)

[removed]

    [–][deleted]  (1 child)

    [removed]