Before this change, presenting happened when the rendering destination
was the final screen. Now this assumption is wrong as the final screen
might be used in the middle of the commands due to DrawFinalScreen.
Instead, this change adds a new argument `present` to FlushCommands to
present the screen explicitly at the end of the frame.
Closes#2386
Now Kage shaders are always used.
The situtation is different from when we fixed for #1355, so we removed
the fast path for #1335. We have to re-check the current performance.
Updates #1355
When DrawTriangles is called and then WritePixels is called on a
sub-image, a panic happened. However, this panic actually happens
only when the graphics driver requires restoring (e.g. OpenGL ES
on Android). The situation was very limited, but this was a real
problem on Android.
This panic was introduced to prevent a rendering bug by a inmature
graphics drivers, but we should no longer need this. This change
just removes the panic.
Updates #292
This function was not called actually, so this is not a real problem.
However, this could be a potential problem for a future GLES driver (#292).
Updates #292Closes#2321
DrawTriangles was introduced at #1508, and apparently there is no
reason we should use ReplacePixels here. So, simplify the logic by
using only DrawTriangles.
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
