The current logic to update a window is to spawn N go routines and have each one call window.Upload() with the rectangle-bound sub-image. This is inefficient because:
1.) It spawns an unbounded amount of goroutines in a short amount of time, causing a burst of CPU usage when many rectangles are cached. Each goroutine has a short lifespan and the creation of the goroutine sometimes takes as long as the operation it performs
2.) Smaller rectangles are served last, which is computationally less desirable because it's a variant of a negated shortest-job-first scheduling algorithm, which is computationally less desirable.
The solution is to take the example from as/frame/examples/fast/fast.go and put it in every win from as/ui/win/win.go. This will make each window spawn N long-lived goroutines that do all the work, where N is the value of runtime.NumCpus.
The current logic to update a window is to spawn N go routines and have each one call window.Upload() with the rectangle-bound sub-image. This is inefficient because:
1.) It spawns an unbounded amount of goroutines in a short amount of time, causing a burst of CPU usage when many rectangles are cached. Each goroutine has a short lifespan and the creation of the goroutine sometimes takes as long as the operation it performs
2.) Smaller rectangles are served last, which is computationally less desirable because it's a variant of a negated shortest-job-first scheduling algorithm, which is computationally less desirable.
The solution is to take the example from
as/frame/examples/fast/fast.goand put it in every win fromas/ui/win/win.go. This will make each window spawn N long-lived goroutines that do all the work, where N is the value of runtime.NumCpus.