RenderScale.compareTo is not antisymmetric

[duranaaron]

Required

RenderScale.compareTo branches on this.scale == scaleOne, which is a property of the receiver rather than of the pair being compared:

override fun compareTo(other: RenderScale): Int =
    if (scale == scaleOne) scale.compareTo(other.scale)
    else comparator.compare(this, other)

With one operand at the default scale and the other not, the two directions compare different fields. One ignores relativeOffset, the other orders on it first. equals and hashCode branch the same way.

HudShader.compareTo chains RenderScale, so HudShader is not totally ordered either, and ShaderManagerImpl.hudShaders is a TreeMap keyed on HudShader.

What I ran into: 12 distinct render tuples came out as a 13 case rendertype_text.vsh, with the same tuple emitted at case 4 and case 11. From the generated shader, with whitespace added:

case 4:
    pos.x = (pos.x - (0)) * 10.0 + (0);
    xGui = ui.x * 50.0 / 100.0;
    yGui = ui.y * 100.0 / 100.0;
    break;

case 11:
    pos.x = (pos.x - (0)) * 10.0 + (0);
    xGui = ui.x * 50.0 / 100.0;
    yGui = ui.y * 100.0 / 100.0;
    break;

Byte for byte the same body. That tuple was the only one in the set with a non-default scale, the * 10.0 above, which is what puts it either side of the branch. For contrast, case 6 is the same position with no scale and appears once.

Rendering is unaffected, both cases describe the same thing. The effect is a wasted shader case and a map whose size depends on insertion order.

If relativeOffset is meant to be ignored at the default scale, normalising it at construction would let all three compare unconditionally.

The shader excerpt above is the whole of it. Happy to upload the full rendertype_text.vsh if useful, it is minified onto one line.

3. Environment

• OS: macOS
• Server version: 1.21.11
• Server platform: Paper
• BetterHud: 2.1.0-SNAPSHOT-447
• Java: OpenJDK 25.0.3