Skip to content

Decide where the client-to-surface coordinate conversion lives #282

Description

@QuentinRoy

Question

Where does the conversion from client coordinates to surface coordinates live?

Points arrive in client coordinates from the pointer (pointer-source.ts) and every drawing surface needs them in its own frame. Today renderer.ts does that conversion in three separate places — inside createStrokeLayer's throttled draw, when creating the menu, and in showFeedback — each reading parent.getBoundingClientRect() itself and calling toLocalPoint. The comment there names the reason: the projector is DOM-free, so every such conversion is the renderer's to make.

Once the surface's origin is no longer the parent's top-left, that duplicated conversion has to change at all three sites and start accounting for the surface's own offset. Decide whether it stays duplicated, becomes a small shared helper, or belongs behind an interface that owns the surface geometry and hands out already-converted points.

Apply codebase-design: the question is where the seam goes and how much the caller has to know, not just how to avoid repeating three lines.

Blocked on the element question: the origin is defined by whatever ends up being sized.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions