#Part 10. Native Graphics, Input, And Performance

#Part 10 Section 1. Resolution Is A Contract

A display mode has physical pixel width, physical pixel height, refresh rate, pixel format, stride, scale, and safe bounds. A 1920×1080 framebuffer can still look low resolution if the compositor draws a small logical canvas and stretches it, uses a nearest-neighbor scaled font, or renders low-resolution assets.

Desktop startup should enumerate the active display, select its native mode when supported, allocate buffers at that size, and pass actual dimensions through layout. Hard-coded 1280×800 windows are acceptable for an app test, not for the ClosedBitOS desktop shell.

#Part 10 Section 2. Bare Graphics Stack

ClosedBitOS does not need DirectX as its graphics API. It still needs real hardware interfaces. A practical stack is:

ClosedBit drawing commands
  -> compositor and command validation
  -> ClosedBit GPU interface
  -> vendor/device driver
  -> PCIe/MMIO/DMA/interrupts
  -> physical GPU and display engine

Start with a firmware-provided linear framebuffer for broad boot visibility. Add a software rasterizer for correctness. Then add hardware-specific drivers behind the same ClosedBit interface. “Own graphics drivers” means implementing command submission, memory management, synchronization, display modes, fault handling, and hardware validation for each supported GPU family; it does not mean hardware stops having vendor-specific protocols.

#Part 10 Section 3. Frame Pacing

Measure input-to-present latency, frame time percentiles, missed presents, compositor time, allocation rate, and GPU/CPU wait time. An average of 60 FPS can hide repeated 50 ms stalls. Report at least median, 95th percentile, and 99th percentile frame times.

Use dirty rectangles or retained surfaces when only part of the screen changes. Avoid rebuilding text layout, decoding images, or allocating large arrays every frame. Keep correctness before micro-optimization; profile the actual hot path.

#Part 10 Section 4. Input And Accessibility

Keyboard, mouse, touch, pen, gamepad, and accessibility input must enter through one timestamped event model. Track key-down separately from text input. Implement held-key repeat deliberately. Touch targets need adequate size and cannot depend on hover.

At minimum, a releasable shell needs keyboard navigation, visible focus, readable contrast, scalable text, reduced-motion behavior, and a recovery route that works without the primary pointing device.