Long text in multiline word wrapped entries causes massive performance issues

[steampoweredtaco]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

Text entry will cause a UI to become unresponsive for large periods of time when .Multiline = true and .Wrapping = fyne.TextWrapWord. This is always on initial use of the entry but it might be happening in other cases.

How to reproduce

Easy to demonstrate, create a fyne app where the content is a scroller with a multiline entry and .Wrapping set to fyne.TextWrapWord. See code example with details and nuance.

Screenshots

Desktop.2024.12.03.-.19.44.01.13.DVR_nm.mp4

Example code

package main

import (
	"fmt"
	"fyne.io/fyne/v2"
	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/container"
	"fyne.io/fyne/v2/widget"
	"log"
	"math/rand"
	"os"
	"runtime/pprof"
	"time"
)

const (
	// At about 2K ~2s, 4K ~10s, 8K ~37-40s
	low  = 8000
	high = 8001
)

// This adds breakable characters as well to show it isn't about
// how long it takes to wrap but in general how much text there is.
func randString(low, high int) string {
	cnt := low + rand.Intn(high-low)
	s := make([]byte, cnt)
	for i := range s {
		s[i] = byte(rand.Intn('}'-' ') + ' ')
	}
	return string(s)
}

func main() {
	f, err := os.Create("cpuprof")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()
	pprof.StartCPUProfile(f)
	defer pprof.StopCPUProfile()
	a := app.New()
	w := a.NewWindow("slow render")
	w.Resize(fyne.NewSize(400, 400))
	e := widget.NewEntry()
	e.Text = randString(low, high)
	// If you comment out the next two lines there isn't an issue with
	// performance showing it has something to do with the multiline/wrap
	e.MultiLine = true
	e.Wrapping = fyne.TextWrapWord
	scroll := container.NewVScroll(e)
	// Adding the scroll content is enough to show the performance issue with large wrapped text
	n := time.Now()
	w.SetContent(scroll)
	fmt.Print("time to set content:", time.Since(n))
	// sometimes it takes the same amount of time to resize, but not always, left this out
	// w.Resize(fyne.NewSize(400, 400))
	go func() {
		time.Sleep(2 * time.Second)
		// Show no issues with resizing the window after initial load
		for i := 400.; i <= 800.; i += .5 {
			// not nearly as bad as setContent but still very slow and can start getting flickery at high counts
			w.Resize(fyne.NewSize(float32(i), 400))
		}
		w.Close()
	}()
	w.ShowAndRun()
}

Fyne version

v2.5.3-rc1 and v2.5.2 at least

Go compiler version

1.23.3

Operating system and version

Windows 10

Additional Information

At 8K characters it can take upwards of 40 seconds to set the content of a window with this entry inside of a scroll. It gets worst from there and you can easily change the example program to experiment.

This is the cpu profile at 8K characters. cpuprof.zip

A non trivial amount of time is spent in runtime slicerunetostring, but the majority seems to be throughout glDriver RenderTextSize stack and the harfbuzz algorithm.

In this video the first ~37 seconds waiting for it to load after calling .SetContent on the window. It also shows flickering/slowness of the program quickly trying to resize the width of the window containing a large entry. I am unsure if the resize slowness and flickering is related given the initial load takes so long.

[dweymouth]

This seems like a duplicate of #5059 to me

[andydotxyz]

are you sure @dweymouth ? the issue you linked does not mention wrapping at all

[dweymouth]

Maybe not? I figured it was the same root cause of Entry not being optimized for very large text, but I can reopen

[beeblebrox]

Can you also remove the duplicate tag until it is verified to be the same root cause?

I don't think it is because most of the time is being spent repeatedly calculating rune sizes; maybe there is a performance issue with that is shared between the two issues, however it feels like there is some major O(N^2) time complexity going on when wrapping and recalculating over and over again.