Vaxis.Window() currently takes vx.mu just to read screenNext.size() before returning a root Window.
We should investigate whether this lock is actually needed and whether it creates avoidable contention or awkward API constraints for upcoming primary-screen rendering work.
Questions to answer:
- Is
screenNext/its size ever mutated concurrently with calls to Window() in supported usage?
- Can window sizing be read from a safer immutable/current-size field instead?
- Should
Window() avoid locking and rely on render-loop ownership instead?
- Are there other
Window methods that lock unnecessarily or assume full-screen ownership?
- How should this behave once primary-screen mode makes
Window() represent the live region rather than the full terminal?
Context: primary-screen region rendering may want Window() to return the current Vaxis-owned drawing surface. If Window() does not need to synchronize on the full Vaxis mutex, simplifying that contract may make the primary renderer easier to reason about.
Vaxis.Window()currently takesvx.mujust to readscreenNext.size()before returning a rootWindow.We should investigate whether this lock is actually needed and whether it creates avoidable contention or awkward API constraints for upcoming primary-screen rendering work.
Questions to answer:
screenNext/its size ever mutated concurrently with calls toWindow()in supported usage?Window()avoid locking and rely on render-loop ownership instead?Windowmethods that lock unnecessarily or assume full-screen ownership?Window()represent the live region rather than the full terminal?Context: primary-screen region rendering may want
Window()to return the current Vaxis-owned drawing surface. IfWindow()does not need to synchronize on the full Vaxis mutex, simplifying that contract may make the primary renderer easier to reason about.