Window resize behavior conflicts with component sizing - jumping effect and inconsistent behavior

[thomasnemer]

Summary

A draft implementation of window resize handling with per-axis resize behavior has been added in PR #7. However, the implementation has several conflicts with pre-existing component sizing behaviors that need to be resolved.

Current Implementation

The PR adds:

• AxisResizeBehavior enum for independent horizontal/vertical resize control
• setAxisResizeBehavior(horizontal, vertical) method
• Integration with FlexLayout for responsive panels
• Per-axis behaviors: FIXED, SCALE, FILL

Known Issues

1. Jumping Effect on Initial Layout

Symptom: The initial layout differs significantly from the layout after the first window resize, creating a visible "jump" when the user first resizes the window.

Expected: Panels should appear at their intended sizes immediately on startup and maintain those sizes consistently.

Observed: Initial layout is incorrect, then "snaps" to correct layout on first resize.

Related Code:

• Component::setAxisResizeBehavior() - initialization of originalWidth/originalHeight
• Component::setBounds() - per-axis behavior application
• Component::onParentResize() - dimension tracking

2. Asymmetric Resize Behavior (Grows but Doesn't Shrink)

Symptom: Components with FIXED axis behavior appear to grow when the window expands, but do not shrink back when the window contracts.

Expected: Components with AxisResizeBehavior::FIXED should maintain their original size regardless of window resize direction.

Observed: Fixed-size components may still be affected by layout calculations during shrinking operations.

Potential Causes:

• Interaction between FlexLayout's shrink factors and component resize behavior
• Min/max size constraints not being properly applied
• Original dimensions being recalculated incorrectly during shrink operations

3. Conflicts with Pre-existing Sizing Behaviors

Issue: The new resize system interacts with multiple existing sizing mechanisms:

• FlexLayout's grow and shrink factors
• Component's withSize() initial dimensions
• Layout manager's setBounds() calls
• Parent/child resize propagation

These systems were not designed to work together and have unclear precedence rules.

Reproduction

1. Build and run the demo app: mise demo
2. Observe the initial panel layout (note widths/heights)
3. Resize window horizontally - observe any jumping or unexpected changes
4. Expand window vertically - observe panel heights
5. Shrink window vertically - observe if panels shrink correctly
6. Repeat with horizontal resizing

Demo App Configuration

From examples/demo_app/scenes/demo_scene.h:

// Left panel: 300px width, FIXED horizontal, FILL vertical
auto leftPanel = create<FlexPanel>().withSize(300, 0).withLayout(leftLayout).build();
leftPanel->setAxisResizeBehavior(Component::AxisResizeBehavior::FIXED, 
                                 Component::AxisResizeBehavior::FILL);

// Center panel: FILL both axes, FlexLayout grow=1
centerPanel->setAxisResizeBehavior(Component::AxisResizeBehavior::FILL,
                                   Component::AxisResizeBehavior::FILL);

// Right panel: 320px width, FIXED horizontal, FILL vertical  
auto rightPanel = create<FlexPanel>().withSize(320, 0).withLayout(rightLayout).build();
rightPanel->setAxisResizeBehavior(Component::AxisResizeBehavior::FIXED,
                                  Component::AxisResizeBehavior::FILL);

FlexLayout configuration:

mainLayout->setItemProperties({
  {.grow = 0.0f, .shrink = 0.0f, .basis = 0.0f},  // Left: no grow/shrink
  {.grow = 1.0f, .shrink = 1.0f, .basis = 0.0f},  // Center: grow/shrink
  {.grow = 0.0f, .shrink = 0.0f, .basis = 0.0f}   // Right: no grow/shrink
});

Affected Code

Key files in this PR:

• include/bombfork/prong/core/component.h - Core resize behavior implementation
• examples/demo_app/scenes/demo_scene.h - Demo app configuration
• tests/test_axis_resize.cpp - Per-axis resize tests

Possible Solutions to Investigate

1. Clearer precedence rules: Define explicit order of operations for resize calculations
2. Separate concerns: Keep layout manager sizing separate from component resize behavior
3. Better initialization: Ensure original dimensions are captured at the right time
4. Unified constraint system: Make FlexLayout constraints and resize behavior work together
5. Two-pass layout: Calculate sizes first, then apply resize behaviors

Additional Context

This is blocking the completion of window resize handling (issue #7). The resize feature is important for responsive UIs, but the current implementation needs refinement before it can be merged.

All existing tests pass, but the visual behavior in the demo app reveals the issues.

[thomasnemer]

Subtasks

This issue has been broken down into the following subtasks:

1. [#109.1] Fix jumping effect on initial layout - ensure consistent sizing from startup #126 - Fix jumping effect on initial layout - ensure consistent sizing from startup (size: s)
2. [#109.2] Fix asymmetric resize behavior - components should maintain FIXED size in both directions #127 - Fix asymmetric resize behavior - components should maintain FIXED size in both directions (size: m)
3. [#109.3] Define and document precedence rules for component sizing systems #128 - Define and document precedence rules for component sizing systems (size: s)

Recommended order: Work on these subtasks sequentially (#126 → #127 → #128) as each builds on understanding from the previous one.