Especially in the initial phase before calling Run/RunGame, the
window position is not reliable and then getting the device scale
factor does not make sense based on the window position. Avoid
using the window position, and instead use the glfw.Monitor in
this situation.
Revert "uidriver/glfw: Bug fix: compile error on Linux"
This reverts commit 0a5126f776.
This reverts commit 3e244d7a7c.
Reason: GetMonitor is available only on fullscreen mode
On Windows, the window could be maximized even when the window was
not resizable. This behavior is confusing. Forbid it so that the
behavior will be clearer.
Especially in the initial phase before calling Run/RunGame, the
window position is not reliable and then getting the device scale
factor does not make sense based on the window position. Avoid
using the window position, and instead use the glfw.Monitor.
This change changes the behavior of WindowPosition /
SetWindowPosition. The window position is now a relative position
and the origin position is the left-upper of the current monitor.
Fixes#1115
Now a window can be floating with SetWindowFloating, the functions
that have suffix 'IsBackground' seems misleading. However, we
cannot rename them due to backward compatibility. Then, let's add
aliases and revisit them when updating the major version of Ebiten.
Fixes#1102
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).
I've been doing some profiling of a very simple ebiten project, and noticed that thread.go was doing a bunch of unnecessary allocations to accomplish its work. This change seeks to reduce GC work.
Input.go was also doing some unnecessary allocations.
The thread.go change reduces the total number of allocations per frame from 1342 to 852 (~36% reduction). The input.go change reduces it further to 752 (~44% total reduction). Perf tests were done on windows.
