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.
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
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.
This is basically a reland of 9cb631e30f.
This change locks the vertices backend at the end-frame phase to
protect from vertices usages by other goroutines.
Updates #1546Closes#1681
QuadVertices or verticesBackend.slice reused its backend slice.
This caused a race condition. QuadVertices can be accessed from
multiple goroutines, and resetting the head and copying the data
at internal/graphicscommand might not be synced.
This change fixes this issue by basically reverting
9cb631e30f.
Closes#1546
This change also remove the restrictions of operations on
graphicscommand.Image. For example, now DrawTriangles and
ReplacePixels can be mixed on the same image.
Fixes#1022
Now a scissor (a clipping region) can be specified, we don't have to
worry about the rendering results out of the specified region.
Replace the implmenetation of the Fill with just a DrawTriangles with
an empty white image.
As a side effect, SubImage is avilable for Fill.
Fixes#1416
