corfe83 b3c567de89 Fix another ~300 allocations per frame in my test project (#1089) ... 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).		2020-02-22 13:40:17 +09:00
..
command.go	buffered: Refactoring: Flush delayed functions without the lock	2020-02-16 19:53:17 +09:00
image_test.go	buffered: Bug fix: Copying pixels failed for the delayed commands	2020-02-16 20:16:04 +09:00
image.go	Fix another ~300 allocations per frame in my test project (#1089)	2020-02-22 13:40:17 +09:00