2.0 Discussion: Fixed System Heights vs Content-Driven Height Expansion

[AvaTheArchitect]

Was just going over some of the goals for the 2.0 and in making changes and looking at areas to improve, this was the last list I think I could find:
2.0 goals:
• Performance overhaul
• Modular usage
• Simplified data model
• Layout/notation cleanup
• API stability layers

In our current system, and in 1.8.x each system is rendered as an independent SVG whose height expands dynamically when notation extends beyond the staff bounds (e.g., bends, stems, harmonics). So each music row has inconsistent spaces and or heights as a result.

For custom overlays and cursor layering, this dynamic resizing introduces layout instability.
As 2.0 aims to improve compression and layout consistency, have you considered optionally supporting fixed-height systems via viewBox with overflow allowance instead of dynamic SVG height expansion or evaluated using a fixed-height system with a viewBox (allowing negative Y for ornaments) in 2.0 to maintain consistent row heights while preventing clipping?

This might support the compression and layout-stability goals mentioned for 2.0, while keeping modular rendering intact.
As 2.0 aims for compression and API stability, is a fixed coordinate system worth evaluating?

Will 2.0 separate layout computation from rendering enough to allow custom header and system-level overrides?

🔷 AlphaTab (Current 1.8.x)
• Each staff system = independent SVG
• Height grows dynamically if notation exceeds staff bounds
• Staff lines = separate elements
• Layout is content-driven
• Prevents clipping by expanding container

Strengths:
• Safe against clipping
• Simple mental model
• Easy incremental rendering
• Good for lazy-loading large scores

Weaknesses:
• Variable row heights
• Layout shifts
• Harder to overlay external elements (custom cursors, headers, etc.)
• Large ornaments distort vertical rhythm

⸻

🔷 ViewBox Model Approach
• Fixed height SVG
• Uses viewBox to allow negative Y
• Notation can float outside visual box
• Staff grid often unified into a single path

Strengths:
• Stable layout
• Consistent row heights
• Easier layering (cursor behind staff, notes above cursor)
• No vertical jitter

Tradeoffs:
• Requires strict clipping logic
• Requires overflow discipline
• Harder to modularize per system
• Requires more careful bounding box math

[Danielku15]

Internally alphaTab already needs to calculate the overflows to reserve the additional space and align the staves accordingly. Hence the technical efforts to allow fixed heights would be fairly low.

But generally the approach just feels like a workaround causing a wide range of other problems. The problems already start with the assumption that we always have SVGs. alphaTab is multi-platform and rather uses raster graphics on all platforms beside web. Hence this feature would only be useful in a very specific setup.

The overflows do not only happen for effects, but for a wide range of standard elements like stems and note heads depending on height. To make a feature which does not break already at the most basic music sheets, we would need to differentiate between overflows needed for the notation itself and overflow needed by additional annotations/effects. Hence such a feature would rather be a fixed/maximum padding which the user specifies than a fixed overall height.

But all these thoughts are only rather workarounds for the fact that alphaTab should align effects more compact but it doesn't.

I think we should first invest efforts into #2010 and only think of further needs after such improvements are in place.