Support interactive Pencuil UI in secondary windows

[botoddly]

Problem

WindowManager supports creating and destroying secondary windows, but the built-in Pencuil path remains tied to the primary window:

• UsePencuil registers one Pencil, PencilSystem, PencuilRenderer, and render phase for the application.
• PencilSystem receives the primary Window from dependency injection and uses its viewport.
• PencuilRenderer initializes its render targets and pipelines from WindowManager.PrimaryWindow.
• DefaultRenderContextProvider acquires only the primary window swapchain.
• Mouse window-presence tracking is limited to the primary window, while mouse and keyboard subscriptions do not expose enough window context to isolate interaction by window.
• TextInputService has window-specific operations, but PencilSystem uses the parameterless primary-window operations.

As a result, a consumer can create a secondary window but cannot attach an interactive Pencuil UI to it through the normal application-builder and render-orchestration APIs. Manual secondary-window rendering does not solve input routing or independent Pencuil state.

This blocks common secondary-window uses such as developer tools, inspectors, editors, and control panels.

Desired behavior

Provide a supported way to host an independent Pencuil UI in a selected Window, including:

• independent Pencil state and viewport per host window;
• rendering to that window through GameKit render orchestration;
• mouse, keyboard, and text input routed to the correct window;
• clean handling when a secondary window is closed and later recreated;
• unchanged behavior for existing single-window applications.

The consumer-facing API should make the target window explicit rather than requiring replacement of Pencuil internals or the application render loop.

Context

This is a follow-up to #248. The initial multi-window implementation added window lifecycle management and a manual-rendering tutorial while intentionally leaving default rendering, Pencuil, and MouseService primary-window-only.

[botoddly]

Proposal

After reviewing the current window, input, render-orchestration, DI, and Pencuil lifecycles, I think this should be treated as a windowing-model redesign rather than a Pencuil-specific compatibility layer.

The central model should be: register logical windows once in the game scope, then activate and deactivate their native resources.

GameKitAppBuilder builder = new();

builder.AddSingleton<GameState>();
builder.AddSingleton<InspectorCommands>();

builder.AddWindow<MainWindow>(window =>
{
    window.SetOptions(new WindowOptions(
        Size: new Size<uint>(1280, 720),
        Title: "Game"));

    window.ActivateOnStart();
    window.CloseBehavior = WindowCloseBehavior.StopGame;

    window.AddRenderPhase<GameRenderPhase>();
    window.UsePencuil<MainView>();
});

builder.AddWindow<InspectorWindow>(window =>
{
    window.SetOptions(new WindowOptions(
        Size: new Size<uint>(640, 480),
        Title: "Inspector"));

    window.CloseBehavior = WindowCloseBehavior.Deactivate;
    window.UsePencuil<InspectorView>();
});

AddWindow is builder-time configuration. It records a reusable logical window definition, its feature factories, and its policies; it does not create an SDL window. The public builder configures the game scope, while SDL, GPU, content, and event-loop infrastructure can remain in an internal parent/root scope.

Application logic receives the stable logical window:

public sealed class InspectorCommands
{
    private readonly GameWindow<InspectorWindow> _inspector;

    public InspectorCommands(GameWindow<InspectorWindow> inspector)
    {
        _inspector = inspector;
    }

    public void Toggle()
    {
        if (_inspector.IsActive)
        {
            _inspector.Deactivate();
        }
        else
        {
            _inspector.Activate();
        }
    }
}

The logical GameWindow<TWindow> exists for the lifetime of the game scope. Activation creates the native window, input routing, swapchain-dependent pipelines, and other native/GPU resources. Deactivation removes the window from event/update/render routing and releases those resources, while logical application and UI state can remain alive. Reopening therefore does not require rebuilding or mutating DI registrations.

Input

SDL already supplies windowID on keyboard, text, mouse motion, mouse button, mouse wheel, and window-presence events. The event pump should route each event directly to the matching active logical window. Each window owns its input context, so Pencuil does not subscribe to a global stream and filter unrelated events. Mouse coordinates, consumption, keyboard focus, and text input are isolated naturally.

Gamepads can remain game-scoped because they are not inherently owned by an SDL window.

Rendering

Replace the single-primary-window assumption with a render scheduler over active logical windows. Each window owns its render-phase collection and independently acquires and submits its command buffer and swapchain texture. A minimized or unavailable window is skipped without preventing other windows from rendering.

Render phases registered for the main window never run in an inspector window unless explicitly configured there. Shared device, shader, and asset resources remain in the parent scope; swapchain-format-dependent pipelines and render targets are activation-bound window resources.

Pencuil

Pencuil becomes a window feature rather than an application singleton. window.UsePencuil<TView>() creates one independent Pencil, ViewRegistry, update system, renderer, and render phase for that logical window.

CPU-side UI state may survive deactivation by default, while retained textures, depth buffers, pipelines, samplers, and input bindings are recreated on activation. A reset-on-activation option can be added if needed.

Lifecycle

The operations should be distinct:

• Hide: keep the native window and resources, but make it invisible.
• Deactivate: destroy native and activation-bound resources while preserving the logical window.
• Dispose: permanently destroy the logical window when its game scope ends.

An OS close request applies the window definition's CloseBehavior, such as Deactivate, Hide, or StopGame. Close/deactivation should be queued and applied at a safe lifecycle boundary rather than destroying the native window inside event dispatch.

Compatibility

I recommend making this a deliberate breaking change. Preserving the current API would leave two competing models: PrimaryWindow versus registered windows, CreateWindow versus activation, root-level versus window-level UsePencuil, and implicit versus explicit view routing.

The redesign should remove the primary-window assumptions, including root Window injection, WindowManager.PrimaryWindow, manual secondary rendering through IUpdatable, parameterless window-specific input operations, and application-level UsePencuil().

Types whose meaning remains valid, such as WindowOptions, GPU abstractions, render-pass APIs, Pencil, and IView, can remain. A migration document is preferable to carrying the old model inside the new API.

[botoddly]

After experimenting with the per-window container approach in PR #383, I think it makes window setup and ownership too complicated. Container identity is being used mainly to distinguish render-phase sets.

A simpler direction is to make TRenderContext that distinction. Each independent render graph has its own context type, context provider, and ordinary DI registrations:

services.AddSingleton<IRenderPhase<MainRenderContext>, WorldRenderer>();
services.AddSingleton<IRenderPhase<InspectorRenderContext>, InspectorRenderer>();

The context provider owns the window/swapchain association, while render phases remain registered directly on the normal service collection. This preserves constructor injection and gives mods a straightforward extension point without per-window child containers or conditional checks inside phases.

MEDI-style keyed registrations were also considered. They allow multiple graphs using the same context type and support runtime-defined groups, but add runtime keys, weaker discoverability, key propagation rules, and a substantial new feature across GameKit.DependencyInjection.

Conclusion: use typed render contexts as the primary composition boundary. Consider keyed DI later only if runtime-created, independently composed graphs sharing the same context contract become a concrete requirement.