Gradient of "Flow" color scheme may calculate silly boundaries

[Jilocasin]

Application Version

4.10.0

Platform

Windows 10

Printer

CR-10

Reproduction steps

Sometimes when using "Fill gaps between walls" the new flow rate color scheme will calculate a really high upper boundary value.

Actual results

I believe this may technically be a valid value that is calculated due to all the factors contributing to this little inner 'blip' (like size, speed, etc.). While the flow rate at this point may really be this high for a tiny moment, it really messes up the graphical flow rate estimation of the model.

In the presented screenshot I can't really tell the flow rate of most of the model, since the blue color is somewhat in the lower third of the gradient. This little spike in calculated flow rate shouldn't contribute to the color gradient in my opinion.

When disabling "Fill gaps between walls" the gradient is calculated properly since the inner 'blip is not filled with material in this case:

Expected results

I can understand that from a technical standpoint this could be considered just an annoyance and not a bug. I still believe that such a trivial occurence of filling a hole with a single drop shouldn't mess up the UI in the way it does.

If, alternatively, there would be a way to customize the color gradient, this problem also would not occur. I have not found a way of doing so though.

Checklist of files to include

• [ ] Log file
• [X] Project file

Additional information & file uploads

Project.zip

[fvrmr]

Hi @Jilocasin I will bring this up with the team. Keep you posted.

[Jilocasin]

This ironically also seems to relate to the "Equalize filament flow" setting, which I usually leave enabled.

Having this setting turned on, the calculated flow on such fill-sections is really high:

Disabling flow equalization lowers the calculated flow rate on that segment to about half, a reasonable value:

Now, the reason for this flow rate seems to be the line being printed much faster (about double the regular speed) despite the line not being any thinner! The "Line Width" setting even shows the line with being slightly higher (maybe 10%?).

Is this a bug in the speed calculation or have I screwed up any settings?

There is another thing I don't understand in this scenario: When having flow equalization enabled, changing the "Max Speed" does not change the print speed of said line!

Cura seems to ignore the "Flow equalization max speed" setting, despite the equalization itself being the reason for the higher speed. When disabling equalization, the line is printed at regular speed.

Sorry for putting so much stuff here. I'm just trying to understand if there is any slicer error in the first place or whether I'm misunderstanding something here. I have again attached the project in question if this helps. PrintSpeedWeird.zip

[konskarm]

Thanks for the very comprehensive report! This is now in our backlog (devs see ticket CURA-8410).

[1knueller]

Id like to add that this kind of display may be easy to gauge and calculate normally but sometimes it doesnt make alot of sense

for example here my object:

see its extremely hard to guess what speeds these 2 colors mean. only the red is obvious. starting such a scale with 0 just doesnt make alot of sense. if i had to guess the main part is 2mm²/s ? what is the blue?

maybe a tooltip/hover or some other indicator on what color is what speed would make sense? or a pallete of 10 of the most used, and somewhat distinct colors in the spectrum?