(*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
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
This change adds an optional function Draw to the Game interface.
With Draw function, the game logic and rendering are separate.
There are some benefits:
* The API is clearer and easier to understand.
* When TPS < FPS, smoother rendering can be performed without
changing the game logic depending on TPS.
* Porting to XNA, which has separate functions Update and Draw,
would be a little easier.
Draw is optional due to backward compatibility. Game interface was
already used before v1.11.x in mobile packages, and adding a
function would break existing code unfortunately. Then, we adopted
switching the behavior based on whether Draw is implemented or not
by type assertions.
IsDrawingSkipped will always return false when Draw is implemented.
Fixes#1104
