performance issue with too many widgets in one panel

[hajimehoshi]

A user reported that when there are for example 64k widgets like buttons in one panel, the performance was degraded. Let's investigate this.

[danielecanzoneri]

Here's a MWE:

type Game struct {
	debugui debugui.DebugUI

	length int
}

func (g *Game) Update() error {
	_, err := g.debugui.Update(func(ctx *debugui.Context) error {
		ctx.Window("Test", image.Rect(60, 60, 200, 400), func(layout debugui.ContainerLayout) {
			for i := 0; i < g.length; i++ {
				ctx.IDScope(fmt.Sprintf("%d", i), func() {
					ctx.Button(fmt.Sprintf("Button %04X", i)).On(func() {
						fmt.Printf("Pressed %04X\n", i)
					})
				})
			}
		})
		return nil
	})

	return err
}

func (g *Game) Draw(screen *ebiten.Image) {
	g.debugui.Draw(screen)
}

func (g *Game) Layout(outsideWidth, outsideHeight int) (int, int) {
	return outsideWidth, outsideHeight
}

func main() {
	if err := ebiten.RunGame(&Game{length: 0x10000}); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

I think the solution should be to somehow "not process" the widgets that are not being rendered

[hajimehoshi]

Thanks. Unfortunately, I don't think this is an easy issue to resolve with the current architecture. I'd filter buttons to show by myself instead of relying on the scroll. I'll keep this open and investigate more.

[hajimehoshi]

Apparently the current bottleneck is runtimer.Caller. I don't know how to make this faster...

[hajimehoshi]

Now the latest commit should improve the situation very much. With the latest commit,

• You have to use Loop to iterate multiple widgets. Loop was introduced in v0.2, not in v0.1.
• You have to cache button name strings in order to reduce string allocations

package main

import (
	"fmt"
	"image"
	"os"

	"github.com/ebitengine/debugui"
	"github.com/hajimehoshi/ebiten/v2"
	"github.com/hajimehoshi/ebiten/v2/ebitenutil"
)

type Game struct {
	debugui     debugui.DebugUI
	buttonTexts []string

	length int
}

func (g *Game) Update() error {
	if g.buttonTexts == nil {
		g.buttonTexts = make([]string, g.length)
	}
	_, err := g.debugui.Update(func(ctx *debugui.Context) error {
		ctx.Window("Test", image.Rect(60, 60, 200, 400), func(layout debugui.ContainerLayout) {
			ctx.Loop(g.length, func(i int) {
				if g.buttonTexts[i] == "" {
					g.buttonTexts[i] = fmt.Sprintf("Button %04X", i)
				}
				ctx.Button(g.buttonTexts[i]).On(func() {
					fmt.Printf("Pressed %04X\n", i)
				})
			})
		})
		return nil
	})

	return err
}

func (g *Game) Draw(screen *ebiten.Image) {
	g.debugui.Draw(screen)
	ebitenutil.DebugPrint(screen, fmt.Sprintf("FPS: %0.2f", ebiten.ActualFPS()))
}

func (g *Game) Layout(outsideWidth, outsideHeight int) (int, int) {
	return outsideWidth, outsideHeight
}

func main() {
	if err := ebiten.RunGame(&Game{length: 0x10000}); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

I'll take a look further so I'll leave this issue open.

[hajimehoshi]

This reaches 60 FPS on my machine:

[danielecanzoneri]

Nice! It'still a bit laggy on my machine but the situation definitely improved.
By quickly looking at profiling data the bottleneck seems to still be the caller call in the (*Context).Button.

Anyway I think little can be done with this much widgets, I solved it by showing just enough widgets to fill the space and then modifying them when needed to mimic a sort of scrolling