This just specifies that the constant refers to the number of source images passed to a shader.
This makes a distinction with the number of dst images, that could potentially be more than 1 in the future.
A managed byte slice from the new byte slice pool has a function
to release and put it back to the pool explicitly, and this doesn't
rely on GCs.
Updates #1681Closes#2804
Bytes from a pool in a command queue is now pretty hard to use correctly
as the lifetime of a queue is not clear.
Remove the byte pools once. Let's reconsider pool usages later.
This change also removes imagesWithBuffers as this is no longer needed.
imagesWithBuffers was necessary to ensure all the bytes from the pool
of the command queue was used before the queue flushes the commands,
as the command queue cleared the pool after flushing. The lifetimes
were pretty ticky.
(*Image).WritePixels doens't send a command to the queue immediately
but caches commands internally. However, the package atlas assumed
that pixel data was sent to the cache every end of a frame. Then, byte
slices for pixels were corrupted.
This change fixes the issue by resolving all the images when flushing
commands.
Closes#2390
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
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
Inserting a dummy rendering command after ReplacePixels and before
DrawTriangles solved the issue. This is a very dirty hack, but
there seems no other better way.
Closes#2154
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
