It was actually impossible to use the common vertices backend in a
thread-safe manner, and actually this caused race conditions.
This changes fixes the issue by giving up a central backend, and
letting images have their own vertices buffer.
Closes#2473
This is a reland of 42833614fb.
Now the filter argument is not used (a4e9a05b14),
the filter value can be the nearest filter even though the shader is
for the linear filter.
As long as `canSkipMipmap` is set correctly, we don't have to consider
the parameter `filter`. We should ignore it.
Updates #2364
Now the filter argument is not used (a4e9a05b14),
the filter value can be the nearest filter even though the shader is
for the linear filter.
As long as `canSkipMipmap` is set correctly, we don't have to consider
the parameter `filter`. We should ignore it.
Updates #2364
This change replaces the member `volatile` with `imageType` to make
the code more explicit.
In the old code, it was not obvious whether a mipmap was used for a
screen image. Actually a mipmap was not used since `canSkipMipmap` is
always true for a screen image, but this was too tricky.
This reverts these commits
* 3259ef3daf
* 7c55065490
* 5bb70f485e
Reason: iOS crash. Probably we have to prepare a special rendering
pipeline for the final screen.
Closes#2278
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
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
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.