Refactor epigenome activity renderer to 'batched svg'

[azangru]

This is a refactoring of the svg renderer of epigenome activity track done by Codex (model gpt-5.4-mini medium)

Here are its suggestions about the improvement of performance of the component

I inspected packages/regulation/epigenome-activity and the main cost is not just “SVG”, it is “lots of SVG nodes plus full recomputation on each render”.

What I found:

- The component renders one <svg> tree for the whole track stack in packages/regulation/epigenome-activity/epigenome-activity.ts:119.
- Each visible feature becomes its own SVG element in packages/regulation/epigenome-activity/render-track.ts:20.
- Every render re-clips, maps, sorts, and dedupes all visible features in packages/regulation/epigenome-activity/prepare-data.ts:65 and again in the gapped-peak cleanup path around
  packages/regulation/epigenome-activity/prepare-data.ts:341.

Best options, in order:

1. Keep SVG, but batch aggressively

- Best if you want to preserve crisp vector output and avoid a rewrite.
- Replace many <rect>/<line> nodes with a smaller number of <path> nodes per track or per feature class.
- In this codebase, that means reworking the functions in packages/regulation/epigenome-activity/render-track.ts:20 to emit fewer elements.
- This is usually the lowest-risk performance win because the biggest cost in SVG is DOM size and diffing, not just drawing.

2. Use a hybrid Canvas 2D renderer for the dense track body

- Best if the track is mostly visual and you do not need per-feature DOM nodes.
- Keep SVG only for overlays like selected-location markers and any interactive affordances.
- This would fit the current component API well because the public inputs/outputs are already isolated in packages/regulation/epigenome-activity/epigenome-activity.ts:32.
- If you need even smoother panning/zooming, OffscreenCanvas is a good follow-up if browser support is acceptable.

3. Move to WebGL only if feature counts are very high

- This is the fastest route for massive datasets and 60fps interaction, but it is the biggest rewrite.
- Good fit only if you expect the number of rendered marks to be large enough that Canvas still struggles.
- For this component, WebGL would likely be overkill unless the dataset is much denser than the current playground suggests.

My recommendation:

- Start with batched SVG, not a full renderer swap.
- If that is still not enough, do a Canvas 2D hybrid.
- Leave WebGL as a last resort.

Why I’d start there:

- The current code already clips to the viewport in packages/regulation/epigenome-activity/prepare-data.ts:104, so the remaining hot path is mostly element count.
- A renderer swap alone will not fix the repeated full-data prep in packages/regulation/epigenome-activity/prepare-data.ts:65; that work would still need attention.

This refactor uses the "batched svg" approach that combines individual rectangles and lines into paths.

The performance profile of the playground has changed from this:

to this: