This CL fixes the race condtion on delayedCommands, which can be
accessed and set to nil at the same time.
This CL separates some operations for delayedCommands into slow-
paths and fast-paths, and use mutex only at slow-paths for
performance. The implementation is based on sync.Once.
Fixes#1195
This change creates a new buffered.Image even for a sub-image. This
can increase a memory usage a little, but decrease the GPU memory
usage since only the necessary pixels are allocated on a texture
atlas.
Fixes#896
Updates #1194
This change also enables to remove the optimization at
(*buffered.Image).ReplacePixels.
// This commit w/ the optimization
BenchmarkImageDrawOver-8 60225 19241 ns/op
// This commit w/o the optimization
BenchmarkImageDrawOver-8 66567 17700 ns/op
// The previous w/ the optimization
BenchmarkImageDrawOver-8 62355 19580 ns/op
// The previous w/o the optimization
BenchmarkImageDrawOver-8 54460 22768 ns/op
Updates #1137
(*Image).At can be unnecessarily slow since this tries to get
pixels from GPU. This change reduces the chance to read GPU by
using its pending pixels when possible.
Fixes#1137
This simple change brings my simple test project from 752 allocations per frame to 474 allocations per frame. It seems a shame that go's escape analysis is not smart enough to leave this variable on the stack.
GeoM is a 24-byte struct and there is a slight perf difference that we are storing it in stack, but also copying it around with this change (instead of an 8-byte pointer). This could make things faster (due to stack / CPU cache) or slower (due to copying more memory) - when I try a stress test (drawing 100K images per frame), I can't see any actual performance difference (but I do see 100K fewer allocations, and GC is no longer running almost all the time).
Now grpahicscommand saves the error and shows the error after a
while. This was good to simplify the API but was the cause to hide
some issues.
This change fixes all the errors to be returned immediately, and
buffer this in the ebiten package instead.
Fixes#971
Mipmap calculation must be executed after the main loop starts
because the graphics driver's HasHighPrecisionFloat is needed.
Then, operations on mipmap images must be called from images in
buffered package.
Updates #1044
