This patch provides initial support for the text range selector. Full support will be added gradually in subsequent steps. This is the first step.
Text range selector with following properties:
1. Text Range Selector (Units)
2. Text Style
- Fill Color
- Fill Opacity
- Stroke Color
- Stroke Width
- Stroke Opacity
- Opacity
- Rotation
- Position
- Scale
In the function calculating the tangent to a cubic bezier
at a given t, the atan was calculated using dx over dy,
instead of dy over dx. The error was visible during
the animation using auto-orient = true.
This corrects the return value to Result::InsufficientCondition
when a custom transform is applied.
Additionally, unnecessary x and y member fields have been removed.
comp pointer is used for checking if the header is ready.
It can be written in a worker thread and needs a critical
section on the reader side.
This also potentally improve the thread efficiency
from the segment() / marker() function calls.
loader->stack.pop() at line 3271 is called to remove
the defs node added to the stack due to nested graphics elements.
However, it is called in an inappropriate situation and the loader's node tree is damaged.
Fixes an error where the close tag is recognized as a `line` of the graphics tag when it is `linearGradient`.
ex)
```
<defs id="def">
<linearGradient x1="1" y1="2" x2="3" y2="4" id="l"/>
</linearGradient>
<rect x="10" y="10" width="10" height="10" fill="blue" id="r2"/>
</defs>
```
related issue: https://github.com/thorvg/thorvg/issues/2518
deprecate the `identifier()` APIs by replacing them with `type()`.
ThorVG is going to introduce an instance `id()`,
and this could be confused with the `identifier()` methods.
with this new type() method can reduce the memory size
by removing unncessary type data.
New Experimental C APIs:
- enum Tvg_Type
- Tvg_Result tvg_paint_get_type(const Tvg_Paint* paint, Tvg_Type* type)
- Tvg_Result tvg_gradient_get_type(const Tvg_Gradient* grad, Tvg_Type* type)
New Experimental C++ APIs:
- Type Paint::type() const
- Type Fill::type() const
- Type LinearGradient::type() const
- Type RadialGradient::type() const
- Type Shape::type() const
- Type Scene::type() const
- Type Picture::type() const
- Type Text::type() const
Deprecated C APIs:
- enum Tvg_Identifier
- Tvg_Result tvg_paint_get_identifier(const Tvg_Paint* paint, Tvg_Identifier* identifier)
- Tvg_Result tvg_gradient_get_identifier(const Tvg_Gradient* grad, Tvg_Identifier* identifier)
Deprecated C++ APIs:
- enum class Type
- uint32_t Paint::identifier() const
- uint32_t Fill::identifier() const
- static uint32_t Picture::identifier()
- static uint32_t Scene::identifier()
- static uint32_t Shape::identifier()
- static uint32_t LinearGradient:identifier()
- static uint32_T RadialGradient::identfier()
Removed Experimental APIs:
- static uint32_t Text::identifier()
issue: https://github.com/thorvg/thorvg/issues/1372
Performing a full-screen RenderPass resolve is too expensive.
Because most composite cases only require a small area to be rendered off-screen.
To improve performance, use the bounds of the Geometry for off-screen rendering whenever possible
Previously, the Lottie builder didn't account for image asset sharing
among multiple layers. This update rectifies the situation.
issue: https://github.com/thorvg/thorvg/issues/2428
By explicitly listing the permissions required in general, repositories
without restrictive permissions will only allocate the specified
permissions which is much safer than the default, fairly wide,
permissions grant.
Most workflows don't appear to need any permissions beyond
`contents: read` which is required for checkout (when a repository is
private). By specifying this permission, it tells GitHub not to include
any of its additional default permissions (when a repository is
configured permissively).
The .github/workflows/memcheck_*.sh scripts called by build_ubuntu.yml
require write permissions in order to post their output to a pull
request (as a comment).
In locked down GitHub repositories, unless a workflow/job asks for
write permissions, it will not have them and such API calls will result
in:
{
"message": "Resource not accessible by integration",
"documentation_url": "https://docs.github.com/rest/issues/comments#create-an-issue-comment",
"status": "403"
}
By specifically requesting the permissions, the workflow will continue
to work as expected.
Note that this workflow currently imagines writing a comment.
It does not actually try to do so, and thus there is no need to ask
for permission to use `pull-requests: write`.
If at some point, someone decides to fix that feature, they
will need to add that permission.
OTOH, using a GitHub Step Summary instead does not require any permissions.
