The only remaining use of the cache is mapping handles to textures.
Using a concrete type for the key avoids the allocation caused by convT.
If we need more caches again in the future we can copy the type, or make
it generic.
Instead of updating the benchmark, we removed it outright. It suffered
from several flaws:
- The amount of work for each iteration of b.N wasn't constant, because
the same cache was reused, growing ever larger in size.
- It only tested the cost of insertions. The comment "half are the same
and half updated" wasn't true, as calling 'put' with the same key twice
would've resulted in a panic.
- It didn't simulate any particular workload or cache size, making the
benchmark useless for comparing different cache implementations. The
cost of insertions isn't particularly interesting.
Signed-off-by: Dominik Honnef <dominik@honnef.co>
By keeping all the information in a single map, we avoid multiple
lookups and can switch between frames more easily.
Before ~35us, after ~20us for adding 50 new+old and switching
the frame.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
There are no public API that uses f32.Rectangle anymore. Move Rectangle
to an internal package for internal use.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Until now, the two renderers have shared structures and code for
decoding drawing ops and convert them to GPU-friendly structures.
However, the decoder is tailored to the old renderer and use
structures that poorly fits the new compute renderer.
This change copies the decoder and specializes the copy for the compute
renderer, avoiding a round-trip through the old renderer decoder.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The transformation information in ops.Key is a layer violation.
Introduce a key type specific to package gpu and use that instead.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This commit fixes a bug where a shape first drawn off-screen
and later moved into screen would not display properly. Since we
cache CPU operations (vertex transform / construction) we need to
upload the constructed data to the GPU after it was build, or a later
frame will use non-initialized memory for it's draw call.
Note that this fix removes the optimization of not processing clip
paths outside the screen - but this is assumed to be uncommon except
when it is first drawn off screen to later be moved in (e.g. in a scrolling list)
in which case we do want to upload the data and prepare for that later
call.
This commit also does a few minor clean ups and adds a test case.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
Benchmarking showed that the double map access calls
were a bottleneck. Rework the cache to avoid half of them.
The simplest, naive approach would have been to store a
pointer to a struct with a keep field in the map, allowing cheap
update and frame() operation. Benchmarking showed that the
increased GC pressure of that approach decreased performance
however.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
Previously the cache was only filled during gpu-buffer creation,
resulting in extra work on the CPU to transform vertices if the same
shape was used multiple times in the same frame. Cases such as font
rendering was cached already before this change as it is drawn in it's
own op.Ops that is never reset - and thus re-used from one frame
to the next.
Since we are now calling put() twice per frame an update should no
longer panic.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
Cache also CPU operations by moving pathCache into
drawOps and use it in collectOps to avoid splitting and
transformation of quads if in cache. In order to support
this use a concrete type in opCache instead of interface.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
A recent change made the OpenGL functions an interface of the functions
required for the implementation of GPU, a renderer for Gio operations.
That allowed for running Gio on external systems where OpenGL is
available.
However, to allow for non-OpenGL flavored backends such as Vulkan,
Metal and Direct3D, this change introduces Backend for the high-level
operations required by GPU. This change also adds a concrete backend
to package gl.
Type Backend is a first cut heavily based on OpenGL. Future changes will add
more backends, where the Backend interface quite possibly will need refinement.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The rendering implementation is needed for using Gio UI with external
window libraries such as GLFW. Expose it in the new package gpu.
Updates #26
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur