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>
For some reason, commit d331f63d20 didn't
update the generated code for material.vert properly. The outdated
version is equivalent to the new, so I only discovered this discrepancy
while changing some other shader.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
To ease the integration with foreign OpenGL contexts, carefully save the
context state before rendering a frame and restore it afterwards. Gio
rendering can then be mixed with OpenGL code that expects exclusive
control over context state.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This changes moves the macOS specific setup for desktop OpenGL to the
portable opengl package. The opengl package already takes care of the
desktop OpenGL setup for sRGB framebuffers, and by moving the code we
avoid calling the wrong OpenGL functions in case both OpenGL.framework
and ANGLE libGLESv2.dylib is linked into the program.
Remove the interface casting expressions for gl.Functions; it wasn't
worth the trouble to keep updated.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Desktop OpenGL implements a GL_FRAMEBUFFER_SRGB setting; query that instead
of the frambuffer color encoding.
With this change it is no longer necessary to enable FRAMEBUFFER_SRGB
in the macOS setup; remove it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
macOS is the only platform where desktop OpenGL is used. To support
foreign ANGLE contexts add a setting to override Gio's selection of
OpenGL implementation.
The bulk of this change is making all function pointers per-context
instead of global, and loading the OpenGL library dynamically. As a side
effect we're closer to Gio tolerating a platform without any OpenGL
implementation. For example, Apple has deprecated OpenGL and OpenGL ES
on its platforms and may remove them in the future.
Note that as a side-effect of this change, Gio needs Go 1.16 or newer to
run on iOS.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
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>
The clear background is the most useful, and the old behaviour can
be achieved by filling the entire viewport with a white paint.ColorOp.
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>
The current renderer transforms and processes paths before sending them
to the GPU. It can compute bounds during processing.
The new renderer passes paths verbatim to the GPU, but needs the bounds
for constructing clip bounds.
This change computes the bounds during construction, so it is available
at use. As a bonus for storing the bounds with the path, path caches
(such as for storing text fragments) automatically reuse the bounds
calculations as well.
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>
GPU APIs require that barrier() calls are dynamically uniform, that is
for every barrier in the code, every shader invocation in a workgroup
must all call it, or all not call it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The reflected uniform names are for the shader versions that don't use uniform
buffer objects. For UBO shaders, the names won't resolve.
This change adds a panic when shader uniforms are not found, and fixes
Fixes gio#216
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The recent changes to the compute shaders have fixed all errors
previously reported by fxc. Switch from dxc to fxc to target shader
model 5.0, supported by Direct3D 11.
Because we know dxc must be available, always build compute shaders even
though the result is not yet used.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Apparently, exec.Command.Output waits for winepath's grandchildren to
exit. However, that may take several seconds if wineserver was started
by winepath.
exec.Command.StdoutPipe works better, in that it is closed when the
winepath process exits.
A similar change may help run the fxc.exe tool under Wine, if that ever
turns out to have the same problem.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Wine tools can be slow to run, so it makes sense to batch their use.
Fortunately, winepath supports resolving multiple paths in one
execution.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Literal strings are a more compact than literal byte slices. A future
change will switch to go:embed to save even more space.
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>
The new compute renderer can draw simple strokes. Test that clipping
works with a stroke basis, and that images can be drawn into strokes.
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>
Border can be expressed in-terms of clip.Stroke:
clip.Stroke{
Path: clip.UniformRRect(r, rr).Ops(ops),
Style: clip.StrokeStyle{Width: width},
}.Add(ops)
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
There's an argument that rounded caps and joins are the simplest stroke,
in that it can be defined to cover all pixels within lineWidth distance
from the supporting path.
However, the more important reason is that the compute renderer natively
supports this stroke style (without dashes), and users that don't care
(much) about the particular stroke style should get the efficient
implementation. A good example is op/clip.Border that strokes a closed
path, where the StrokeCap is irrelevant.
This is a (subtle) API change. If you have code that relies on the
default values of clip.StrokeStyle you may want to set Cap and Join
explicitly. See the test changes for examples. On the other hand, you
will get much better performance from the default Cap and Join values
once the compute renderer becomes the default.
Disablethe TestPaintClippedBorder test; dashes round-capped,
round-joined strokes doesn't seem to work correctly.
Signed-off-by: Elias Naur <mail@eliasnaur.com>