perf: limit layout recalculations on hover style changes

[james-elicx]

Description

• Applies CSS to line elements that tells the browser that style changes on a code line do not affect the layout of other code lines.
• Throttles mouse move events with animation frames to reduce excessive events attempting to repaint hover highlighting.

Unfortunately I don't have a reproduction I can share with a large diff at this time, but these changes appeared to have a demonstrable improvement when testing in my own project.

Motivation & Context

Large diffs (3k+ lines) had a lot of lag when it came to the mouse hover highlights when i was trying to integrate the library with a side project i'm working on.

Type of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactoring (non-breaking change)
• New feature (non-breaking change which adds functionality). You must have
  first discussed with the dev team and they should be aware that this PR is
  being opened
• Breaking change (fix or feature that would change existing functionality).
  You must have first discussed with the dev team and they should be aware
  that this PR is being opened
• Documentation update
• Performance optimisation

Checklist

• I have read the
  contributing guidelines
• My code follows the code style of the project (bun run lint)
• My code is formatted properly (bun run format)
• I have updated the documentation accordingly (if applicable)
• I have added tests to cover my changes (if applicable)
• All new and existing tests pass (bun run diffs:test)

How was AI used in generating this PR

Opus 4.6 was used to explore parts of the codebase that related to style changes from mouse hover events, and asked to come up with theories as to why large diffs would have lots of lag when applying the hover highlights on mouse movements.

One of the theories was that the browser is repainting the entire sticky layer whenever a child element style changes due to the gutter using position sticky. It's suggestion was to add contain to line elements to tell the browser that style changes on a line cannot affect the layout or paint of other lines.

The other theory it had was that event.composedPath was causing GC pressure from allocating lots of new arrays, and triggers lots of attempts to repaint the DOM / recalculate style and make mutations for hovers. It's suggestions was to throttle mouse move events with animation frames so that we handle the latest event per animation frame, as the hover state is a visual thing and can sacrifice sub-frame precision.

It also provided the patches that you see here.

Related issues

[vercel]

@james-elicx is attempting to deploy a commit to the Pierre Computer Company Team on Vercel.

A member of the Team first needs to authorize it.

[james-elicx]

Anecdotal but I've been testing this in my project over the past few days and it's working like a charm.

[amadeus]

Hey sorry for the delays in getting back to you. Would it be possible to provide perhaps a file or diff patch file that really shows off the performance differences? In my quick tests with our demo test app, if I set VIRTUALIZE = false and CRAZY_FILE = true both seemed sluggish.

Also would be good to know what browsers you were having these issues in.

Ultimately, the debouncing thing is probably something we should do, but i'm mildly worried about the contain stuff on individual lines (that it could have various unknown future side effects) so want to do some more due diligence.

[amadeus]

Also, fwiw, in our latest beta, we are adding some virtualization features that will probably negate most of these issues in practice. The docs for it aren't published on main atm, but you can see them here: https://pierrejs-docs-2autp2v7u-pierre-computer-company.vercel.app/docs#virtualization