Hi All,
I am trying to lay out some small components in a circle around a centre point but I am finding the integer bounds are causing the components positions to be rounded and shifted causing some to be off the circumference of the circle. I think I could use transforms to offset the components, but i was wondering if there is an easier solution?
I was also wondering if support for floating point component bounds is on the road map for newer versions of JUCE?
Jam
It’s a change that we’d all love to make, but it’s also one where it’d be very hard not to make it break everyone’s code!
There are workarounds though - you can give your object a floating point position relative to its parent and then update the component bounds to be big enough to enclose it. Then in its paint method you just subtract the integer component position from the floating point target position and it looks correct. That’s how things like Drawables are done.
oh… an example of what mean is the ancient BouncingBallComp class in the demo. It’s a bit clunkily-written but uses the same basic principle.
I found a work-around for this. It’s not perfect, but it does work to a certain extent. (It’s way better than the big resizing jumps you normally get. Instead of this in resized():
`myComponent->setBounds(0,0,10,10);
I do this:
juce::Rectangle<float> rect_tmp(0,0,10,10);
myComponent->setBounds(rect_tmp.toNearestInt());
This generally results in a more accurate placement than the first method. I don’t know why, probably math or some shit. But it works.
So in your case, you’d make a rect, and then do rect_tmp.setCentre(sins and cos and blah blah); then setBounds(rect.toNearestInt()) and that way all your circle math is sub-pixel floating point accurate, and the most anything will be off is half a pixel, which is generally good enough for government work.
Just to follow up from Jam… What we’re actually doing is a bit more complex. We have complex nested SVG documents that represent our UI. Then specially named SVG objects get replaced by custom components. Of course these SVG sub-objects are represented as drawables, which are subpixel accurate. But when we replace one of these drawables with a component it gets truncated to the integer bounds. Storing the difference between the floating point bounds and the integer bounds and using this as a transform somehow seems to be the way to go.
I’m fighting this issue as well. I’m just use enlarged integer bounds and then a Point offset which goes from 0|0 to 1|1 to offset the drawing by adding it to all the coords… which feels super-clunky.
Back in the days of VSTGUI2 they made the transition from int to float coords and it was painful to migrate the code. It can be done by using a coordinate type and compiler flags to use int for older projects and float for newer projects. IMHO the sooner JUCE would go through that a bit painful transition the better.
Yeah, that’s mainly why we were asking the JUCE team here if there is plan on the roadmap for it! Since there would be a bit of effort to get what were doing working. And if floating-point Component bounds were just around the proverbial corner then we might just wait since it’s not massively urgent for our release schedule.
why not just setTransform (…), translate the component for the fraction of pixels, much easier adding the an offset to all coordinates