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>
Use op.Offset instead, or create and manipulate a f32.Affine2D.
API change. Update your code with a gofmt rule:
gofmt -r 'op.TransformOp{}.Offset -> op.Offset'
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Add support for affine transformations. The key changes are outlined
below.
- Painting/clipping with rectangles is handled by, for complex
transforms, creating clipping paths representing the transformed
rectangle and using a larger bounding box. Cover/Blit shaders updated
correspondingly to correctly map texture cordinates from the new
bounding boxes.
- Since path splitting must happen on CPU the transforms must happen CPU
side as well - offsets removed from shaders.
- Complex transforms will lead to different path splitting which means
that GPU arrays can no longer be cached if the transform has changed.
Thus the current transform is added as a key to the cache.
- Add a public API to op for setting Affine transformations.
There are a number of optimizations that could be explored further but
which are left out now:
- Caching also of CPU operations (e.g path splitting & transforms) and
not only caching the GPU arrays.
- Allow for re-use of cached GPU vertices if the transformation change
is a pure offset / scaling since the splitting is then the same.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
Encode TransformOp as an Affince2D matrix instead and use that in gpu and io transform handling.
There are no changes to user facing API and so far only the offset part of the matrix is used.
This patch is a step towards full affine transformations.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
This is a first step towards supporting affine drawing transforms.
The rendering algorithm relies on quadratic curves that do not cross
x = 0 more than once, thus curves must be split after any rotation/shear
transforms. Move this logic and the generation of vertices to package gpu.
Also close all curves and draw zero-width edges as preparation for
transform since the will no longer implicitly be vertical with no
effect.
This commit will severely affect performance since vertexes are now
transformed also for cached items, using cpu resources.
Signed-off-by: Viktor <viktor.ogeman@gmail.com>
Converting
macro := op.Record(ops)
...
macro.Stop()
macro.Add()
to
macro := op.Record(ops)
...
call := macro.Stop()
call.Add(ops)
Which is more general (call.Add can take a different ops than the op.Record
that started it), and enforced the order between Stop and the subsequent Add.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The only mutable field is "recording", which is used for a sanity
check. THat check is performed (less generally) by Ops.macroStack.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
To match Record, we'd like Push to return a value. To do that and
support the one-line
defer op.Push(ops).Pop()
Pop needs to use a value receiver as well. Drop the active field
and make it so. The field was only a sanity check, a check which is
already done by Ops.stackStack, albeit with a less specific panic.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
The funcs replace stack.Push and macro.Record, which become private.
This makes stack and macro faster to write, in particular for stacks
where you can just write the following line to save and restore the
state :
defer op.Push(ops).Pop()
This usage requires Push to return a pointer (since Pop has a pointer
receiver), or else the code doesn't compile.
For consistancy, I tried to do the same for op.Record, but this implied
to turn all the MacroOp fields into pointers, and this caused some
panics. As a result, op.Record doesn't return a pointer.
An other side effect pointed by Larry Clapp: StackOp and MacroOp are not
re-usable any more, you have to allocate a new one for each usage, using
the described funcs above.
Signed-off-by: Thomas Bruyelle <thomas.bruyelle@gmail.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 ability to invoke other operation lists belongs in the new CallOp.
While we're here, make MacroOp.Add use a pointer receiver to match the
other methods.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
We'd like to improve the API of Flex, Stack and similar layouts
that use MacroOps internall. Unfortunately, the
func (m MacroOp) Add(o *Ops)
method causes the MacroOp to be allocated on the heap, ruining the
nice garbage-free property of layouts.
Fortunately, layouts don't need the feature that caused the heap
allocation: invoking operation lists different than the current.
CallOp separates the invoke-different-list semantic from MacroOp,
in preparation for removing the feature from MacroOp.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Assign (per-frame) unique ids to each MacroOp and StackOp operations
and ensure that the pairwise Push/Pop and Record/End match.
In a follow-up change the Flex and Stack layouts will rely on those
checks to avoid being overlapped.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Remembering the order of the corners in the RoundRect is difficult,
which suggest that RoundRect should be a struct with named fields.
Do that, and make Rect the special case where corner radii are all
zero.
Signed-off-by: Elias Naur <mail@eliasnaur.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>
Elias Naur