vector: FillRect() with large width has wrong color

[kazzmir]

Ebitengine Version

git@f66fd7e5ee5e609c3d4f4555a78d8a3c38e1cb82 (2.10.0-alpha.10)

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

go version go1.25.0 linux/amd64

What steps will reproduce the problem?

package main

import (
    "image/color"
    "github.com/hajimehoshi/ebiten/v2"
    "github.com/hajimehoshi/ebiten/v2/vector"
)

type Engine struct{}

func (e *Engine) Update() error {
    return nil
}

func (e *Engine) Draw(screen *ebiten.Image) {
    w := screen.Bounds().Dx()
    h := screen.Bounds().Dy()

    vector.FillRect(screen, 0, 0, float32(w), float32(h), color.NRGBA{R: 100, A: 200}, true)
}

func (e *Engine) Layout(outsideWidth, outsideHeight int) (int, int) {
    return outsideWidth, outsideHeight
}

func main() {
    ebiten.SetWindowSize(2500, 800)

    ebiten.SetWindowResizingMode(ebiten.WindowResizingModeEnabled)

    var engine Engine
    ebiten.RunGame(&engine)
}

As you make the window wider, the problem becomes more apparent.

What is the expected result?

Screen is expected to be a single color red square.

What happens instead?

When the window gets wide enough the left side of the window is the correct color (the one passed as the color to FillRect) but the right side becomes a darker color, as if FillRect() is being applied twice to the left side.

Anything else you feel useful to add?

This only occurs if antialias=true in FillRect()

[kazzmir]

I could not produce an issue by forcing the height to increase. The width issue seems to occur for me when the window size is 2048 or larger

[hajimehoshi]

I failed to reproduce this on macOS. I'll try Linux later.

[kazzmir]

It seems related to drawing multiple times with offsetAndColors in fillPaths(). If I add in this hack to stop drawing after 3 loops then I see a single color at least.

for ci, oac := range offsetAndColors {
            if ci > 3 {
                break
            }

[hajimehoshi]

I could reproduce this with a big layout size:

package main

import (
	"image/color"

	"github.com/hajimehoshi/ebiten/v2"
	"github.com/hajimehoshi/ebiten/v2/vector"
)

type Engine struct{}

func (e *Engine) Update() error {
	return nil
}

func (e *Engine) Draw(screen *ebiten.Image) {
	w := screen.Bounds().Dx()
	h := screen.Bounds().Dy()

	vector.FillRect(screen, 0, 0, float32(w), float32(h), color.NRGBA{R: 100, A: 200}, true)
}

func (e *Engine) Layout(outsideWidth, outsideHeight int) (int, int) {
	return outsideWidth * 4, outsideHeight * 4
}

func main() {
	ebiten.SetWindowSize(800, 800)

	ebiten.SetWindowResizingMode(ebiten.WindowResizingModeEnabled)

	var engine Engine
	ebiten.RunGame(&engine)
}

[hajimehoshi]

A minimized test case:

func TestFillRectOnBigImage(t *testing.T) {
	dst := ebiten.NewImage(3000, 3000)
	defer dst.Deallocate()

	vector.FillRect(dst, 0, 0, 3000, 3000, color.White, true)
	if got, want := dst.At(0, 0), (color.RGBA{0xff, 0xff, 0xff, 0xff}); got != want {
		t.Errorf("got: %v, want: %v", got, want)
	}
	if got, want := dst.At(2999, 0), (color.RGBA{0xff, 0xff, 0xff, 0xff}); got != want {
		t.Errorf("got: %v, want: %v", got, want)
	}
	if got, want := dst.At(0, 2999), (color.RGBA{0xff, 0xff, 0xff, 0xff}); got != want {
		t.Errorf("got: %v, want: %v", got, want)
	}
	if got, want := dst.At(2999, 2999), (color.RGBA{0xff, 0xff, 0xff, 0xff}); got != want {
		t.Errorf("got: %v, want: %v", got, want)
	}
}

[hajimehoshi]

This is simply due to the shortage of the backend image, so this fix will work:

diff --git a/vector/atlas.go b/vector/atlas.go
index 233bab3fd..60a0dab3f 100644
--- a/vector/atlas.go
+++ b/vector/atlas.go
@@ -91,7 +91,7 @@ func (a *atlas) setPaths(dstBounds image.Rectangle, paths []*Path, bounds []imag
        }
 
        // Use 2^n - 1, as a region in internal/atlas has 1px padding.
-       maxImageSize := max(4093, dstBounds.Dx(), dstBounds.Dy())
+       maxImageSize := max(8191, dstBounds.Dx(), dstBounds.Dy())
 
        // Pack the regions into an atlas with a very simple algorithm:
        // Order the regions by height and then place them in a row.

However, there should be a better solution. Let me think.