Bug in Graphics::drawRoundedRectangle?

Dear JUCE developer,

I have just found that Graphics::drawRoundedRectangle causes an infinite loop when giving a large rectangle such as width = 8.68231e+06 for instance.

Graphics::drawRect does not cause an infinite loop with the same width size so that I assume it is an unique symptom seen in drawRoundedrectagnle.

Would be so grateful if you could fix it, or tell me any ideas about it…
Thank you!

I tried adding the following code to the paint function of a component in a demo project and it rendered as expected, without freezing. I tested on macOS 10.15.7.

const auto largeNumber = 8.68231e6f;
const juce::Rectangle<float> rect { largeNumber, largeNumber };
g.drawRoundedRectangle (rect, 1000.0f, 2.0f);

To investigate further, we’ll need some more information. Which version of JUCE are you using, and which platform are you building for? If you can provide a small program which demonstrates the issue, that will help us to track down the issue more quickly.

Thank you for your reply.

I have investigated a bit more precisely and found that we needed to give even larger number as follows.

    const unsigned long largeNumber = 40.e6f;
   
    std::cout << "drawing a rectangle\n";
    g.drawRect(0, 0, largeNumber, largeNumber, 2);
    
    std::cout << "drawing a rounded rectangle\n";
    g.drawRoundedRectangle(0, 0, largeNumber, largeNumber, 5, 2);
    
    std::cout << "done\n";

In my environment, JUCE v6.0.8, macOS 10.15.6, g.drawRect works fine, but the program stuck in drawRoundedRectangle.
A smaller number than 40.e6f would be able to reproduce the stuck but it seems like not always.
It would be nice if you could try another number as well.

CPU is near 100% and furthermore, occupied memory size increases rapidly.

Screenshot 2021-05-27 at 00.27.37

Basically I would not use such a large number to draw a rectangle, but my program lets users zoom UIs can easily reach the number.
The zoom function is not something I can realize with AffirmTransformation but need to manipulate the component’s bounds.

Thank you for your help!

Thanks for the test case, I was able to reproduce the issue. I will update this thread if/when a fix is merged.

I’ve merged a fix for this issue: