This adds support for nearest neighbor filtering,
which can be useful in quite a few scenarios.
img := paint.NewImageOp(m)
img.Filter = paint.FilterNearest
img.Add(gtx.Ops)
Fixes: https://todo.sr.ht/~eliasnaur/gio/414
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
Pointer hit areas and paint clip areas are separate concepts, but
similar enough to warrant merging. This change replaces pointer hit
areas with clip areas, so Gio is left with just one area concept (in
package op/clip).
The reason for separating the concepts in the original Gio release was
because of my being unsure general path/stroke hit areas would ever be
implemented, let alone efficient.
This change represents a change of mind, in the sense that it's better
to have an incomplete API than two separate area concepts.
Leave the deprecated pointer.Rect, pointer.Ellipse for temporary
backwards compatibility.
This is an API change. Most existing programs should continue to build
with this change, but may have to adjust to having all clip.Ops participate
in InputOp hit areas.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Ops is in the internal package ops, but external clients can reach its
method through op.Ops.Internal. Hide them by converting them to internal
package functions.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The op.Save and Load methods exist to support the need for
transformation, clip, pointer area state to behave as stacks. For
example, layout needs to apply an offset to its children but not
subsequent operations.
Before this change, op.Save and Load were used to save and restore the
state:
ops := new(op.Ops)
// Save state.
state := op.Save(ops)
// Apply offset.
op.Offset(...).Add(ops)
// Draw with offset applied.
draw(ops)
// Restore state.
state.Load()
A drawback with the op.Save mechanism is that there is no direct
connection between the state change and the saving and loading of state.
This causes confusion as to when a Save/Load is needed and who is
responsible for performing them, which leads to subtle bugs and over-use
of Save/Loads.
This change gets rid of the general state stack and replaces it with
per-state stacks. There is now a stack for transformation, clip, pointer
areas, and they can only be restored by the code pushing state to them.
The example above now becomes:
ops := new(op.Ops)
// Push offset to the transformation stack.
stack := op.Offset(...).Push(ops)
// Draw with offset applied.
draw(ops)
// Restore state.
stack.Pop()
For convenience, transformation also be Add'ed if the stack operation is
not required.
Simple state such as the current material no longer has a way to be
restored; it is assumed the client of a PaintOp adds their desired
material operation before it.
API change: replace op.Save/Load with explicit Push/Pop scopes for
op.TransformOps, pointer.AreaOps, clip.Ops.
To ease porting, this change retains a version of op.Save/Load that
saves and restores the transformation and clip stacks. It also retains
an Add method for clip.Op.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
There's no meaningful reason to have them separate. The intention was to
enable rendering concurrent with other processing, but that's gaining
framerate at the expense of input latency and complicating ImageOp
semantics.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The semantics were relaxed in a previous commit; this change renames
to operations accordingly.
API change. Use gofmt to adjust your code accordingly:
gofmt -r 'op.Push(a).Pop() -> op.Save(a).Load()'
gofmt -r 'op.Push(a) -> op.Save(a)'
gofmt -r 'v.Pop() -> v.Load()'
gofmt -r 'op.StackOp -> op.StateOp'
Signed-off-by: Elias Naur <mail@eliasnaur.com>
...interface{} requires constructing a slice, which is slow.
This cuts about 100ns from RRect and Border benchmark.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
color.RGBA has two problems with regards to using it.
First the color values need to be premultiplied, whereas most APIs
have non-premultiplied values. This is mainly to preserve color components
with low alpha values.
Second there are two ways to premultiply with sRGB. One is to premultiply
after sRGB conversion, the other is before. This makes using the API more
confusing.
Using color.NRGBA in sRGB makes it align with CSS.e
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
PaintOp.Rect is the wrong abstraction; it implies a clip operation
better handled by package clip, and not all paints need it (colors).
Furthermore, it's awkward to specify a PaintOp that fills up the
current clip area, regardless of its size.
Redefine PathOp to mean "fill current clip area".
API change. Replace uses of PaintOp.Rect with a TransformOp applied
before the PaintOp.
Leave a TODO for the PathOp infinity area.
Fixes gio#167
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We're about to remove PaintOp.Rect. Replacing PaintOps with Fill or
FillShape where possible will ease the transition.
Using Fill in tests exposed a problem with the infinity in paint.Fill.
Adjust it for now; it will be removed later.
Updates gio#167
Signed-off-by: Elias Naur <mail@eliasnaur.com>
This is effectively a revert of commit gioui.org/commit/69dfd2e3a5541.
ImageOp.Rect is the wrong abstraction; it implies a clipping operation that is
better handled by package clip.
API change. Uses of ImageOp.Rect should apply a clip.Rect before the PaintOp,
or use image.RGBA.SubImage (or similar).
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The new field ImageOp.Rect is initialized to cover the entire source
image, but can be modified to draw only a section of it.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Corrected the use of draw.Draw in paint.NewImageOp as the old use only works for images starting at the origin
Signed-off-by: Axel Paulander <axel.paulander@gmail.com>
The gioui.org/commit/74407a50d598bfd27e8f8e48b6832cc5df04de77
added a NewImageOp constructor that always copies the supplied
image. It does that for two reasons:
First, the image.Image reference is used in the image=>texture
map of cached textures. Without a copy, we wouldn't detect a
modified image even if a new ImageOp was created.
Second, we don't want the program to touch the image while the GPU
is uploading it.
The second reason was removed in a previous change that blocks
FrameEvent.Frame until we're done with the operations, including
uploading images to the GPU.
The first reason is easily fixed by using a unique per ImageOp,
as pointed out by Alessandro Arzilli.
This change switches to using the unique key. Alessandro's patch
avoids the copy when possible.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
By returning the allocated data buffer, Ops can become an interface
in a future change without forcing operations to allocate.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
With public ImageOp fields there was no way to mark an image.Image as modified.
Replace them with NewImageOp that always make a copy, and use the opportunity
to ensure the copy is ready to upload to a GPU texture.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Instead of adding an implicit ClipOp, return a ClipOp ready to use, freeing the
caller from recording a macro.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Admin