tldraw/packages/editor
alex 79f46da199
expanded highlighter geometry (#1929)
Currently, the highlighter shape uses a single 0-width line for its
geometry, same as the draw tool. For the draw tool this works ok - the
visual line is thin enough that unless you zoom right in, it's hard to
find areas where the hover should trigger but isn't. As the highlighter
tool is much thicker though, it's relatively easy to find those areas.

The fix is for the geometry to represent the line including its thick
stroke, instead of at 0-width. There are two possible approaches here:
1. Update the polyline geometry to allow passing a stroke width.
2. Instead of a polyline, make the highlighter shape be a polygon that
traces _around_ the stroke

1 is the more accurate approach, but is hard to fit into our geometry
system. Our geometry is based around two primitives: `getVertices` which
returns an array of points around the shape, and `nearestPoint` which
returns the nearest point on the geometry to a vector we pass in. We can
account for a stroke in `nearestPoint` pretty easily, including it in
`getVertices` is hard - we'd have to expand the vertices and handle line
join/caps etc. Just making the change in `nearestPoint` does fix the
issue here, but i'm not sure about the knock-on effect elsewhere and
don't really want to introduce 1-off hacks into the core geometry
system.

2 actually means addressing the same hard problem around outlining
strokes as 1, but it lets us do it in a more tightly-scoped one-off
change just to the highlighter shape, instead of trying to come up with
a generic solution for the whole geometry system. This is the approach
I've taken in this diff. We outline the stroke using perfect-freehand,
which works pretty well but produces inaccurate results at edge-cases,
particularly when a line rapidly changes direction:

![Kapture 2023-09-19 at 13 45
01](https://github.com/tldraw/tldraw/assets/1489520/1593ac5c-e7db-4360-b97d-ba66cdfb5498)

I think that given this is scoped to just the highlighter shape and is
imo an improvement over the stroke issue from before, it's a reasonable
solution for now. If we want to in the future we could implement real
non-freehand-based outlining.

### Change Type

- [x] `patch` — Bug fix

### Test Plan

1. Create a highlight shape
2. Zoom in
3. Make sure you can interact with the shape at its edges instead of
right in the center
2023-09-26 11:21:37 +00:00
..
src expanded highlighter geometry (#1929) 2023-09-26 11:21:37 +00:00
api-extractor.json transfer-out: transfer out 2023-04-25 12:01:25 +01:00
api-report.md expanded highlighter geometry (#1929) 2023-09-26 11:21:37 +00:00
CHANGELOG.md Update CHANGELOG.md [skip ci] 2023-07-04 14:21:37 +00:00
editor.css avoid pixel rounding / transformation miscalc for overlay items (#1858) 2023-09-08 10:47:14 +00:00
LICENSE transfer-out: transfer out 2023-04-25 12:01:25 +01:00
package.json tldraw zero - package shuffle (#1710) 2023-07-17 21:22:34 +00:00
README.md transfer-out: transfer out 2023-04-25 12:01:25 +01:00
setupTests.js Styles API follow-ups (#1636) 2023-06-24 13:46:04 +00:00
tsconfig.json tldraw zero - package shuffle (#1710) 2023-07-17 21:22:34 +00:00

tldraw/tldraw

Benchmark

To run the benchmarks

yarn workspace @tldraw/tldraw benchmark

Or

yarn workspace @tldraw/tldraw benchmark "file_search_string"