Spec out this incomplete experimental feature,
this is a still promising one, we will reintroduce
this officially after 1.0 release
size: -2kb
issue: https://github.com/thorvg/thorvg/issues/1372
A pkgconfig file is already provided, which enables using `thorvg` once
it is installed. However, this file is not, and cannot be, available at
setup time if using `thorvg` as a subproject.
In such cases, Meson provides the `override_dependency` mechanism for a
subproject to tell its parent how to use it.
The current Paint::bounds(transform=true) returns the coordinates
of the paint in its local coordinates after transformation.
However, it did not convert the origin to the world coordinate.
This is problematic when the user wants to determine
the paint's position and size with the origin being the canvas.
Specifically, this matters that when the paint is belonged
to a certain scene.
Now, the bounds() method returns the coordinates
of the paint's bounding box with the corrected world space.
User can figure out the actual boundary within the painted result.
Remark that, this may break the functional behavior compatibility.
This utility method allows access to a specific paint instance
by its unique identifier.
Experimental API:
- const Paint* Picture::paint(uint32_t id)
- const Tvg_Paint* tvg_picture_get_paint(Tvg_Paint* paint, uint32_t id)
This function computes a unique identifier value based on the provided string.
You can use this to assign a unique ID to the Paint object.
Experimental APIs:
- uint32_t Accessorr::id(const char* name)
- uint32_t tvg_accessor_id(const char* name)
Lighten is applied, where multiple masks intersect,
the highest transparency value is used.
Darken is applied, where multiple masks intersect,
the lowest transparency value is used.
Experimental API:
- CompositeMethod::LightenMask
- CompositeMethod::DarkenMask
issue: https://github.com/thorvg/thorvg/issues/2608
For a linear gradient defined by identical start and end
points, and for a radial gradient with a radius of 0,
the rendered shape should have the color of the last
specified color stop.
The documentation has been updated accordingly.
@Issue: https://github.com/thorvg/thorvg/issues/2582
The logic of interpretation of trimming start and
end values has been moved to the sw_engine,
so the values provided by the user are not modified.
No logical changes in the interpretation alg.
For pairs of trim's start/end values where the distance
between begin and end is >= 1, the entire stroke should
be drawn, but instead, nothing or only part is drawn. Fixed.
Stroke trim docs fixed.
This corrects the return value to Result::InsufficientCondition
when a custom transform is applied.
Additionally, unnecessary x and y member fields have been removed.
it provide changes public API for webgpu canvas interface to provide nessessary handles to native window for different platforms:
API Change:
- Result target(void *instance, void *surface, uint32_t w, uint32_t h) noexcept;
NonSupport indicates unsupported options due to disabled features
or lack of system support. InvalidArgument indicates the case
such as incorrect parameter values.
The functions setting stroke's features always
returned a true. Returnig a boolen was a remnant
from a previous implementation. Since now they
never return false, they can be void functions.
The APIs description has been corrected.
New api sets/gets the trim of the stroke
along the defined path segment, allowing
control over which part of the stroke is
visible.
@issue: https://github.com/thorvg/thorvg/issues/2190
The viewport function defines the rectangular area of the canvas
that will be used for drawing operations.
It is used to clip the rendering output to the boundaries of the rectangle.
Apps can use this function to set the drawing region within the canvas.
When the ThorVG canvas is partially inside the screen area such as during scrolling
it could help enhance rendering performance.
New Experimental API:
- Result Canvas::viewport(int32_t x, int32_t y, int32_t w, int32_t h) noexcept;
Issue: https://github.com/thorvg/thorvg/issues/2274
A single animation might have a desinated markers with naming: 0 ~ 0.5 (sector A), 0.5 ~ 1.0 (sector B). Selecting one of them using a marker name(sector A) and could play only that part with animation controllers.
usage:
- `animation->segment("sectionA") // Named segment(Marker)`
- `auto cnt = animation->markerCnt()`
- `auto name = animation->markers(index)`
- `animation->segment(0, 0.5) // Segment`
- `animation->segment(&begin, &end)`
Co-authored-by: Jinny You <jinny@lottiefiles.com>
Currently, tvg ignores the frame value if the difference
is less than 0.001. In most cases, updating the frames
when the change is less than 1ms is just an unnecessary
burden on the system.
Instead, this ensures that the perfect last frame is reached.
issue: https://github.com/thorvg/thorvg/issues/2147
GL might need to generate a default target FBO
when the given target ID indicates the main surface.
However, users may want to draw visuals directly onto the main surface.
This policy must be reviewed thoroughly.
Refactor the GlCanvas::target() interface to allow
passing the drawing target ID from the user side.
Previously, it performed the drawing on the currently set FBO target.
Beta API change:
Result GlCanvas::target(uint32_t* buffer, uint32_t stride, uint32_t w, uint32_t h)
-> Result GlCanvas::target(int32_t id, uint32_t w, uint32_t h)
The previous loader cache mechanism encountered a problem
when the user changed the content of the cached data.
In such cases, a new request would not be processed
because the renderer would use the previously cached content.
So far, the TVG cache mechanism utilizes a pointer hash key
for the fastest hashing mechanism available.
One limitation is that it assumes the address is unique for the data.
To resolve this, we modified the caching policy.
Now, the renderer will not cache copied data;
it will only cache the given data when it is deemed shareable.
issue: https://github.com/thorvg/thorvg/issues/2020
