LinearGradient renders with wrong axis — Paint.Flush() writes End.Y twice (should be End.X)

[cchafer]

Submission checklist

• I have confirmed the issue is present in the latest version of the Rive Unity package
• I have searched the documentation and forums and could not find an answer
• I have searched existing issues and this is not a duplicate

Description

Version: v0.4.3 (also present on main as of June 2026).

Bug

In package/Runtime/Renderer.cs, Paint.Flush() serializes a linear gradient's end point. The linear (else) branch writes linear.End.Y twice instead of linear.End.X then linear.End.Y:

else
{
    var linear = Gradient as LinearGradient;
    bytes = BitConverter.GetBytes(linear.End.Y);   // BUG: should be linear.End.X
    for (int j = 0; j < 4; j++) { buffer[offset++] = bytes[j]; }
    bytes = BitConverter.GetBytes(linear.End.Y);    // End.Y (correct)
    for (int j = 0; j < 4; j++) { buffer[offset++] = bytes[j]; }
}

So the native renderer receives end = (End.Y, End.Y) — End.X is never sent. Any linear gradient with End.X != End.Y (i.e. virtually all of them) renders with the wrong axis (the gradient collapses/rotates).

Fix

The first write should be linear.End.X:

bytes = BitConverter.GetBytes(linear.End.X);

Previous working version

No response

Reproduction steps / code

Repro

Procedurally draw a Path filled with a Paint whose Gradient is:

new LinearGradient(new Vector2(0f, 0f), new Vector2(100f, 0f), colors, stops)

Expected: a left→right gradient. Actual: wrong direction (behaves as if end = (0, 0)). RadialGradient is unaffected.

Upload your reproduction files / stack trace

No response

Source .riv / .rev file

No response

Screenshots / video

No response

Unity Editor log file

No response

Rive Unity package version

0.4.3

Unity version

6000.3.18f1

Target platform

macOS

Editor OS & version

No response

Additional context

No response

[damzobridge]

Thanks for reporting this. The low-level API, including procedural drawing, has been deprecated in favor of scripting in the Rive Editor, as that gives proper access to primitives you might need. As such, the procedural API is no longer supported.

It seems like we missed some methods and classes like Renderer.cs, but those will be marked as Obsolete in the next release, and removed completely in a following release.