Programs such as gio-example/glfw rely on Gio drawing blending with
the framebuffer background. This change makes it so when sRGB emulation
is active.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Collect is for converting ops to GPU commands, Frame is for actual
rendering. There's little practical difference, but makes profiling
easier to distinguish between conversion and rendering.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
GPU operations logically belong in the Frame method, and it's probably
best to keep them inside BeginFrame/EndFrame as well.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Before this change, the two renderers both had special case code for
approximating strokes they don't support natively. This change moves
that conversion to clip.Op.Add, for several reasons:
- The compute renderer no longer need fallback logic and caches for
strokes it doesn't support.
- The approximation logic is slow. Moving it to clip.Op.Add will not
speed it up, but will make the cost easier to spot in profiles. Until all
strokes are supported natively, users can use macros to cache
expensive strokes.
- Reduced garbage: Op.Add takes an op.Ops anyway, and can use that for
storing the approximated stroke outline.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
To avoid an import cycle in a future change, internal/stroke can no
longer import op/clip. Move required op/clip functionality to
internal/stroke and duplicate the remaining types.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Complex strokes are not yet supported in either of the current renderers,
so they are converted to filled outlines in package gpu.
We're about to move that complexity up to the op/clip package, so we're
going to need the converter available from outside package gpu. This
change extracts the conversion code and related types to the separate,
internal package stroke.
No functional changes; a follow-up moves the stroke conversion.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
In the old renderer, all strokes are converted to filled paths. The new
renderer can draw simple strokes natively. Do that, and avoid the costly
conversions.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The fill mode is now controlled by a SetFillMode command, not by flags
on each path segment and fill command.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Otherwise the padding we leave around rendered materials may contain
content from reclaimed materials.
Fixes icon "shimmering" when the kitchen example is transforming.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Since clip.Path now encodes paths in the format expected by
elements.comp, use that data directly instead of a roundtrip through
drawOps.buildVerts.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to encode clip.Paths with the format compatible with the
compute renderer. This change extracts the encoding to a re-usable
package.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
All functions left in the old package unsafe were provided byte slice
views of other types. Rename the package accordingly and avoid a name
clash with the standard library package unsafe.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This change tracks materials so that only the updated materials needs to
be rendered.
Materials are likely cheap to render each frame, at least compared to
the rest of the compute pipeline. However, the CPU fallback must
transfer all changed materials to CPU memory, and a cache is a great
improvement over fetching all materials every frame.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to cache the transformed materials. It's easier to do when
quads can be constructed before determining their atlas position.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There are no longer any importers of package backend outside of
gioui.org/gpu. Move it internally, and rename it to the slightly more
specific "driver" while we're at it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Return the output framebuffer from BeginFrame, to make it clear that
it may change between frames. Delete CurrentFramebuffer which is no
longer needed.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to change the last stage of the compute pipeline to only
accept images, not sampled textures. This change prepares materials
for pixel-aligned image copying by pre-rendering images to a texture,
applying transforms.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Gio UI may be overlaid on top of custom graphics such as in the glfw example.
That will only work if Gio doesn't clear the screen (to white).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The old renderer is still the default, so the new compute renderer will only be
used in the rare case the old renderer is not supported but the new is. That
happens on the Samsung J2 Prime and Moto C Android phones. Or set the
GIORENDERER environment variable to "forcecompute" to disable the old renderer:
$ GIORENDERER=forcecompute go run ...
Missing features:
- Gradients are not supported yet, and render as a solid color.
- Draw timers are not added, and profile.Events are not emitted.
- Stroked paths may in some cases appear corrupted because their clip
outlines are not continuous when generated by Gio. Sebastien is
working on a fix.
- The new renderer shares most CPU-side logic with the old renderer,
resulting in several inefficient conversion steps between the old
operations representation and the new. This is slower, but minimizes
divergence in features and bugs between the two renderers.
Roadmap:
- The compute renderer supports features that Gio does not yet
exploit: stroked paths with round caps, transformations, lines,
cubic beziér curves.
- More stroke styles and maybe dashed strokes natively in shaders.
- Metal and Direct3D ports.
The most important feature is porting the renderer to run on the CPU. A
CPU renderer will both support Gio on devices with insufficient GPU
support, and allow us to remove the old renderer. Two renderers is twice
the maintenance but the feature set of the weakest implementation.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur