LineSymbol: Revise CenterOfGap symbols #2325
Conversation
|
It would probably be best to degrade gracefully for cases before the search start. But cases outside the path are tricky: You could reasonably argue to force them into the valid range. OTOH this may break loops which are naively limited by reaching a desired length. |
|
This PR now includes a test for actual rendering. |
dg0yt
changed the title
SplitPathCoord::at
Eplicitly omit all symbols outside start/end. Resolves failing assert() on some curves. Establishes equal rendering for straight and curved case. Avoid unequal spacing but may output less symbols.
|
Reduced this PR to changing only linesymbol, i.e. the calling site triggering the particular assert. Changes to, and tests of, |
| auto split = (position >= dash_start.clen) ? dash_start : start; | ||
| for (int i = 0; i < mid_symbols_per_spot; ++i, position += mid_symbol_distance_f) | ||
| { | ||
| if (position < start.clen) | ||
| continue; |
There was a problem hiding this comment.
Key changes for avoiding the assert.
| if (position > end.clen) | ||
| break; |
There was a problem hiding this comment.
For symmetry. Noticable when changing the direction of the path.
For GH-2324.
No change necessary or implemented for the intented use case, which is symbols which fit into the gap between the dashes.
For symbols outside the gap, this PR avoids undefined rendering behavior signaled by an assert in SplitPathCoord:at by controlling rendering based symbols being outside (omitted) or inside (rendered) of the [start,end] range passed into
createDashGroups. This interval is a moving window over start, explicit dash points, and end of a path.The new behavior also creates consistent mid symbol positions regardless of path direction.