In vase mode, different(color of) speed is displaying all over the place

[5jvm0u4]

Description of the bug

As mensioned, it seems to be just a visual bug, no actual speed changes occored in the printing process.

Project file & How to reproduce

Load the provided .3mf(zip) file as a project, it's reproducible, at least in 2.8.1
bug.zip

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.8.1+win64

Operating system

windows 11 23H2

Printer model

Voron 2.4R2 with self-designed toolhead

[u89djt]

(Intrigued fellow user going for it)
So we have implied speed variations smaller than the precision of the labels in the speed display, which is showing identical labels on each line. Most of the speeds are in the middle of the range with brief flicks to one or the other extreme. I'll start with a minimum-inputs-from-boot route to the bug, then use the original example to maybe get an idea of the size of numerical glitches.
The shortest path I've found so far from an empty slicer to seeing red and blue flecks in the speed display is as follows:
Slicer opens to MK3S 0.2mm speed profile
Add cylinder to bed
Make the following settings to instruct the slicer to output a single wall with no top, bottom, infill, brim or skirt, not in vase mode:
infill=0%
perimeters=1
bottom layers=0
top layers=0
skirt loops=0
Delete the purge line by removing its extrusion commands from the custom gcode. I did this one in the MK3S profile, so I deleted lines
{if filament_settings_id[initial_tool]=~/.Prusament PA11./}
to
{endif}
Now slice and switch to speed view to get this:
minimumchangesspeedglitch.zip

And if you need more convincing, switch on fuzzy surface to get this:

Playing with the settings in OP's project shows that the numerical glitching is something like 0.000001mm/s either side of the settings value.

Use OP's project file. You have to set the first layer speed yourself to 99.99999 because it is rounded up to 100 on saving so I can't post it with the value already filled in.

That's 99.99999 with five nines after the decimal point.
Very approximately, the first layer runs at a nominal 99.99999mm/s with jumps to about 99.999995 and 99.999985. The main body runs at 100 with jumps of again approximately 0.000005.
0.000005 in 100 is 5e-8 so wild speculation wonders about something with 24 bits being involved, but that's just a random computer scientist performing very superficial pattern matching :)
Here's the actual speed display from the same slice:

Over.

[u89djt]

Neat - looks like something eminently traceable:
boxneatglitches.zip

[u89djt]

@5jvm0u4 I dig that you found this. If this isn't effecting/reflecting disturbances in the actual gcode output, and I can't find any evidence that it is, since no-one will ever see this effect in a practical print job, I predict a "closed as not planned" in 3... 2... 1...

[u89djt]

If I vary the acceleration cap, the glitches move around, so true speed values are making their way into display decisions/values they shouldn't. It seems like a bad idea to leave that kind of crossover lying around in code.
smearedglitches.zip