This constant was set with some wrong assumptions:
1. On Android, recovering was needed.
2. On iOS, OpenGL ES was used when
a. The architecture was 386 or amd64 == an emulator is used
b. The build tag ebitengl was not specified
c. gomobile-build was used
3. On browsers, recovering was needed.
1., 2b, and 2c are correct.
2a. is not correct: Now emulators are available on all the
architectures with both Metal and OpenGL.
3. is not correct: Ebiten no longer recovers the contest lost.
Now, Ebiten can detect a context lost explicitly when
1. On Android
2. On iOS and on gomobile-build
(When gomobile-build is used, OpenGL should always be used)
Based on this fact, this change changes the constant to a variable,
and fixes the logic to set the variable.
Now the logic of graphicsDriver() is updated, this can return a Metal
graphics driver on iOS even when gomobile-build is used.
This change fixes this issue.
With DirectX, the graphics driver cannot be determined until the
main loop starts, as a transparent window cannot be treated with
DirectX so far. On the other hand, compiling shaders requires a
graphics driver as it requires information about Y directions of
NDCs and framebuffers.
This change delays compiling shaders until the graphics commands
are actually executed in the main loop.
Updates #1007
Updates #2019
There was a potential issue that commands in the queue are never
reset when an error happens and the queue continues to send errors.
This is problematic especially for testings.
This change fixes the issue by Go's defer.
This is necessary to remove the graphics driver usage from
(*ebiten.Image).At. And this is necessary to determine the graphics
driver after the window becomes transparent or not.
Unfortunately, it is not obvious to make a transparent window with
DirectX. Then, the determination of a graphics driver should be delayed.
Updates #1007
Allow overlapped regions at pixelsRecords.
This removes the members `last*` for caching. These were introduced
at 7e7751bd43, and apparently these
are no longer needed.
If regions by ReplacePixel are overlapped, this can panics. This can
happen only on Android, where a context lost can happen.
Thus, a sub-image cannot call a direct ReplacePixels. internal/buffer
has to care this.
