This is a reland of 2c9f5d9dad.
As the name is `usedAsDestination`, this should be updated whenever
the image is used as a rendering destination.
Confirmed that this change didn't cause a performance regression
like #2586.
Updates #2586
Updates #2676
As the name is `usedAsDestination`, this should be updated whenever
the image is used as a rendering destination.
Confirmed that this change didn't cause a performance regression
like #2586.
Updates #2586
Updates #2676
An image has a counter to count how many times an image is used.
Before this change, the counter was updated only when an image was moved
from a source backend to a destination backend. This seemed not enough,
and an image was likely moved to a source backend more often than
necessary (#2676).
However, there was also an issue that the counter was updated too
aggressively and the image was unlikely moved from a destination to
a source image (#2586).
In order to resolve this dilemma, let's adopt an intermediate way:
count up the counter at most once per frame.
Updates #2586
Updates #2676
This change adds a new compiler directive 'kage:unit' to Kage. This
takes one of these two values: 'pixel' and 'texel'. The default value
is 'texel'.
With the pixel-unit mode, all the built-in functions treats pixels
instead of texels, and the texCoord argument of Fragment is in pixels.
This simplifies shader programs as programs no longer have the notion
of texels.
With the texel-unit mode, the behavior is the same as the current
behavior.
Closes#1431
Before this change, texture atlases are created only for rendreing
sources.
This change enables to use texture atlases even for rendering
destinations, so that the number of textures will be drastically
reduced.
Closes#2581
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
(*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
Adjusting pixels is needed to avoid strainge rendering to avoid unexpected
rendering (#1171). However, this adjustment caused unexpected holes
especially in a thick stroke.
This change moves the logic of adjusting pixels from atlas to
graphics.QuadVertices so that adjusting works only for DrawImage and
DrawRectShader.
Updates #1171
Updates #1843
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
DrawTriangles was introduced at #1508, and apparently there is no
reason we should use ReplacePixels here. So, simplify the logic by
using only DrawTriangles.
From the reported stack trace, there could be a potential issue in
atlas.BeginFrame: images were manipulated before the images are restored.
Restoring images assumes that all images are not stale, but manipulating
images like putOnAtlas might cause other images stale in ReplacePixels.
Though we failed to reproduce the case, this fix should make sense.
Updates #2075
Now pixels are adjusted even when the graphics driver doesn't have
high-precision floats, but this should not be problematic. This was
introduced at 9bff33472a, but the
adjusting way is much different from the current way.
Updates #879Closes#1820
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
Note that this applies only to the builtin shaders - interface for Kage stays
unchanged for compatibility.
Minor compatibility delta: when interpolating alpha values, previous code has
created nonsense values, such as, when interpolating from
fully-transparent-black (0,0,0,0) to opaque-white (1,1,1,1), something like
half-transparent-grey (0.25,0.25,0.25,0.5) where half-transparent-white
(0.5,0.5,0.5,0.5) is used by the new code.
I assume this is a strict improvement, however this may warrant some testing.
Possible later improvement could be moving the premultiplication from fragment
shader to CPU. Did not do this as it makes the code rather inconsistent of Kage
vs built-in shader usage.
Updates #1772
