Loading indicator radius seems to be multiplied by 10

[zipy124]

Version of Dear PyGui

Version: 1.11.1 Operating System: Windows 11

My Issue/Question

The radius value for the loading indicator seems to be multiplied by 10 when applied

To Reproduce

Steps to reproduce the behavior:

1. Create any element with a height of say 25
2. Create a loading indicator with radius of 12.5
3. Note it is HUGE
4. Create a loading indicator of radius 1.25
5. Note it is the same size as the element with a width and height of 25

Expected behavior

1. Create any element with a height of say 25
2. Create a loading indicator with radius of 12.5
3. Note it is the same height/width

Standalone, minimal, complete and verifiable example

# Here's some code anyone can copy and paste to reproduce your issue
import dearpygui.dearpygui as dpg

dpg.create_context()
dpg.create_viewport()
dpg.setup_dearpygui()

with dpg.window(label="tutorial"):
    with dpg.group(horizontal=True):
        dpg.add_progress_bar(label="Progress Bar", default_value=0.78, overlay="78%",height=25)
        dpg.add_loading_indicator(style=1,radius=1.25)
    with dpg.group(horizontal=True):
        dpg.add_progress_bar(label="Progress Bar", default_value=0.78, overlay="78%",height=25)
        dpg.add_loading_indicator(style=1,radius=12.5)

dpg.show_viewport()
dpg.start_dearpygui()
dpg.destroy_context()

[v-ein]

The name radius is what's causing confusion here. In the C++ implementation, the corresponding argument is named indicatorRadiusFactor. That is, it isn't radius in pixels, it's just a scaling factor for the default indicator image. thickness is a scaling factor, too.

The default size (before multiplying by radius) is calculated based off font size.

FWIW, there are a couple of bugs in size calculation for style=1 indicators. If I remember correctly, one of the bugs leads to incorrect positioning (try to put an indicator into a FixedFit table cell with borders, and you'll probably see it), and the other affects radius/thickness calculations.

[zipy124]

Ahhhh, this makes a lot of sense. Perhaps we can update the documentation with this information?

[v-ein]

Yeah, doc definitely needs to explain this. Also, I'd prefer to fix the calculation bugs I mentioned earlier before we even touch the doc (just to make sure everything is consistent).