JOGL TextRenderer: problem with getBounds()

I am experiencing an issue with com.jogamp.opengl.util.awt.TextRenderer that I can't quite figure out.

I create a TextRenderer once, before I start drawing, and store it in an instance variable, like so:

        renderer = new TextRenderer(font, true, true);

The, inside my GL listener's display() method, I use the same renderer object to draw text:

        renderer.beginRendering(width, height);
        Rectangle2D r = renderer.getBounds(s);
        int w = (int)(r.getWidth()+0.5);
        int h = (int)(r.getHeight()+0.5);
        renderer.draw(s, zx1 - w - 3, zy1 - h - 2);
        System.out.println("\""+s+"\": [minX:"+r.getMinX()+" minY:"+r.getMinY()+" maxX:"+r.getMaxX()+" maxY:"+r.getMaxY()+"]");
        renderer.endRendering();

Text coordinates are calculated so that the text I draw is left- and top-aligned.

The text itself (the 's' variable above) changes sometimes between calls to display(). Here's the problem, though. The first time display() is called after the text changes, the width and height of the rectangle returned by getBounds() is wrong. Here's an example (each line corresponds to a call to display()):

"0": [minX:-1.0 minY:-13.0 maxX:13.0 maxY:2.0] -- the very first time display is called(), I draw "0". Height is 15
"0": [minX:-2.0 minY:-14.0 maxX:15.0 maxY:3.0] -- on subsequent calls, getBounds() result is stable and height is 17
...
"0": [minX:-2.0 minY:-14.0 maxX:15.0 maxY:3.0]
"0": [minX:-2.0 minY:-14.0 maxX:15.0 maxY:3.0]
"1": [minX:0.0 minY:-14.0 maxX:9.0 maxY:1.0] -- text has changed to "1", height is 15
"1": [minX:-1.0 minY:-15.0 maxX:10.0 max:Y3.0] -- text is the same, but height is now 18
"1": [minX:-1.0 minY:-15.0 maxX:10.0 max:Y3.0] -- from now on, height remains 18 until the text changes again
...
"1": [minX:-1.0 minY:-15.0 maxX:10.0 maxY:3.0] -- height is still 18
"2": [minX:0.0 minY:-13.0 maxX:12.0 maxY:2.0] -- text has changed again, height is 15
"2": [minX:-1.0 minY:-14.0 maxX:14.0 maxY:3.0] -- text is the same, but height is now 17
...
"2": [minX:-1.0 minY:-14.0 maxX:14.0 maxY:3.0]
"1": [minX:-1.0 minY:-15.0 maxX:10.0 maxY:3.0]
...

The last line is sort of interesting. The text changed back to a previously used value ("1") and there is no "height jitter". It's almost as if the renderer caches bounds internally by text (I suspect there is indeed a cache involved).

My question is... am I doing something wrong, or is it a problem with the text renderer itself? I don't get any "height jitter" if I create a new text renderer every time display() is called, but that sounds awfully wasteful to me.

NB: this doesn't happen with every font, and it doesn't happen with every string. For example, I get this problem with certain font if I try to render strings with font-specific, non-standard characters (e.g. '\uE004'), and with other fonts I can get the same problem while rendering plain ASCII.

Thanks in advance.

Maybe it is caused by the caching system.

Alright, if that's the case... what would be the workaround?

I belive you have a multithread issue...
Make sure that AWT do not change s due to user input in between

        Rectangle2D r = renderer.getBounds(s); <--- here
        int w = (int)(r.getWidth()+0.5);
        int h = (int)(r.getHeight()+0.5);
        renderer.draw(s, zx1 - w - 3, zy1 - h - 2);
        System.out.println("\""+s+"\": [minX:"+r.getMinX()+" minY:"+r.getMinY()+" maxX:"+r.getMaxX()+" maxY:"+r.getMaxY()+"]");
        renderer.endRendering();  <--- and here

My code is single-threaded and there is no user input involved.

Please try to reproduce your bug with an existing test case or provide another one.

>Please try to reproduce your bug with an existing test case or provide another one.

"An existing test case"? "Another one"?

I am honestly not sure what you are asking me to do.

You have only posted a few lines of code, I need a complete and working example instead. There are unit tests on the repository and if it is not enough to reproduce your bug, you can write your own unit test. When the unit test is ready, you can write a bug report so that your bug won't be forgotten and it allows the maintainer to spend less time on bugs, it generally increases the chances of obtaining a fix. I won't fix a bug that I can't reproduce.

Alright, that makes sense. I can do that. One thing, though... it doesn't happen with every font, it doesn't happen with every character in the font that does cause problems, and I am not sure I can give the font file to you no matter how much I want that bug fixed (licensing issues).

Suggestions?

Reproduce your bug with a font that you can ship without licensing problems.