You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DashedVMobject should allow for fixed-length dashes independent of the length of the underlying curves. DashedLine does, by computing the length of the curve in __init__ (see #3989), but DashedVMobject does not. This makes animated dashed CubicBeziers for example quite ugly, since their dashes will be stretched, leading not only to temporal inconsistencies, but also to inconsistencies between different-length curves (unless users find ways to compute the correct num_dashes, which I did not yet).
How can the new feature be used?
Connections between entities can be visualized with lines or curves, the style of which conveys some meaning (type of connection / relation). If the dash length is consistent, the style will be perceived as the same, so it is possible to use dashing as an indication of the type of connection / relation.
Additional comments
I looked into the implementation myself, and initially thought the reason for this is that the length of arbitrary VMobjects is hard to compute / not available. However, there is already the equal_lengths argument (defaulting to True), which causes the approximate length to be computed.
When further trying to come up with a PR, I found that the current default of num_dashes=15 prevents a backwards-compatible introduction of dash_length: float = DEFAULT_DASH_LENGTH as in DashedLine. I would suggest to really have the latter as new default behavior, but that is obviously something to be discussed and decided on.
The text was updated successfully, but these errors were encountered:
hmeine
added
the
new feature
Enhancement specifically adding a new feature (feature request should be used for issues instead)
label
Nov 4, 2024
Description of proposed feature
DashedVMobject should allow for fixed-length dashes independent of the length of the underlying curves. DashedLine does, by computing the length of the curve in
__init__
(see #3989), but DashedVMobject does not. This makes animated dashed CubicBeziers for example quite ugly, since their dashes will be stretched, leading not only to temporal inconsistencies, but also to inconsistencies between different-length curves (unless users find ways to compute the correct num_dashes, which I did not yet).How can the new feature be used?
Connections between entities can be visualized with lines or curves, the style of which conveys some meaning (type of connection / relation). If the dash length is consistent, the style will be perceived as the same, so it is possible to use dashing as an indication of the type of connection / relation.
Additional comments
I looked into the implementation myself, and initially thought the reason for this is that the length of arbitrary VMobjects is hard to compute / not available. However, there is already the
equal_lengths
argument (defaulting toTrue
), which causes the approximate length to be computed.When further trying to come up with a PR, I found that the current default of
num_dashes=15
prevents a backwards-compatible introduction ofdash_length: float = DEFAULT_DASH_LENGTH
as in DashedLine. I would suggest to really have the latter as new default behavior, but that is obviously something to be discussed and decided on.The text was updated successfully, but these errors were encountered: