Closed schw4rzlicht closed 6 years ago
Can you proof that the values will never go below 0, e.g. did you print out the values that you send to the gauge? Just would like to make sure that this is not the reason because normally there is no reason to show negative values if there are no negative values :)
Yep. I print the actual values right below the gauge like seen in the video. Also (because I knew you would ask š) I added debugging code before setting the values that prints the values to console/triggers a debugger breakpoint if they are below zero. If needed, I may record a video for that as well.
Ok...I've made a quick test and you are right...there seems to be something wrong here...will check...
As a quick workaround you might want to switch off the animation (animated(false)) because you seem to set the values quickly. This does not show the problems afaics.
Ok...the problem is related to the needleBehavior(Gauge.NeedleBehavior.OPTIMIZED) setting. If you just remove that it will work as expected. This should have no effect to the bar because it is just for a gauge with a needle so I need to dig into that thing a bit deeper :)
That's right, I set the value about 40 times per second. But like you said, the needle behavior did the trick. To be honest I just forgot to delete it when I switched to the linear skin. Ty š
Ok the problem is that if the needleBehavior is set to OPTIMIZED the value for the animation will be calculated differently. This is in principle only for a gauge where the needle can rotate 360 degrees. It checks which "way" for the needle is shorter and then use the shorter way for the animation which lead to the negative values if not used in such a gauge. I think I will leave it like it is and make some comment in the code to know next time :)
I am currently developing a sound meter app and I noticed that the linear skin shows values below zero although I never set them below zero. I am confident the issue is in the linear skin because using the default skin, the behavior is not reproducible.
This video shows the problem: https://youtu.be/5olzrGAXjC8. Notice that the lower number is the actual value sent to the gauge. Also it looks like if you raise input volume slow enough, the problem does not exist.
I am creating the gauge like this:
And I update the gauge using a
PropertyChangeListener
: