irisandClaude Opus 5
9b331a5e93
About one start in five, the window kept its 800x600 startup layout on a 1920x1200 surface for good. It was not the layout: tracing iris's own decisions into memory -- eprintln in the draw path makes the fault vanish, which is why it kept getting lost -- gives byte-identical traces for a good and a bad run. Both do redraw_all at (1920, 1200) and draw into a 1920x1200 texture with suboptimal=false. The right frame was drawn every time and the compositor kept showing the first one, and forcing a full repaint did not shift it. winit's Window::pre_present_notify, called immediately before present, is what ties the commit to the surface's frame callback on Wayland. Without it a frame with nothing following it can sit unpresented with nothing left to flush it -- which is precisely a window that has just settled after its opening resize. 0 bad in 40 with the fix, against 4 in 20 without. The stronger number is 0 in 20 in the instrumented configuration that had been 15 in 20, since that is the arrangement the fault liked most. Runtime resizing still round-trips to a byte-identical layout. Ruled out and not worth re-trying: the present mode (the fault survived AutoNoVsync -> AutoVsync at the same rate) and the size cache (redraw_all clears it). desired_maximum_frame_latency = 1 moved the rate without fixing it and was reverted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>