Windows 与 XFESystem 桌面流畅度共同验收标准 v1

验收目标是同一台实体机器上达到 Windows 的实际交互表现。一次窗口能打开、平均 FPS 高或计时器设成 240 Hz，都不足以通过。机器、主显示器、线缆/接口、3840×2160 输出、240 Hz 实际扫描模式、缩放、鼠标报告率、电源策略、温度/负载条件和输入路径必须匹配。原始数据、源码/镜像、驱动版本和测量工具均记录哈希。机器可用的 32 个逻辑处理器不能替代实际执行核心计数。

机器可读阈值及场景清单为 Tools/DesktopFluidity/Standard.json。它们是本项目明确采用的验收门槛，不宣称属于行业统一标准。

显示、内容与时间的定义

原生分辨率以最终内核 framebuffer 的实际宽高/stride 和显示器当前信号模式核对。4K 输出在 150% 下的逻辑桌面为 2560×1440，在 200% 下为 1920×1080；这些逻辑尺寸不能当作实际输出尺寸。把 1280×800 放大到 4K 屏幕不能算 4K 输出。
240 Hz 是物理显示时序，目标帧周期为 1000/240 = 4.166666… ms。EDID 是显示器能力信息；GOP 模式只给出几何及像素格式；帧循环、软件 Present 完成和 QEMU 刷新参数均不是扫描频率测量。
Windows 使用实际显示模式查询及 PresentMon 的 displayed frame time/display change 跟踪。未完成到显示阶段的数据不能算显示帧。硬件光学测量用于确认光子延迟和硬件光标轨迹；没有该证据时相关指标保留未测。
XFESystem 必须区分输入入队/消费、UI 调度、CPU 绘制、framebuffer 完成及物理扫描。没有显卡扫描完成/垂直同步证据时，物理 FPS、撕裂和 input-to-photon 指标为未知，整体流畅度验收不得通过。
连续运动只统计新输入带来实际不同内容或光标位置的帧。空闲画面不要求不断重画，重复提交同一画面不能抬高有效运动帧率。启动时间另计，从真实打开动作到完整可交互内容就绪，不把占位、源码回退或首个空窗口算完整编辑器就绪。

相同操作与采样

每个连续场景预热 5 秒，采样 30 秒，重复 5 次。使用完全相同的可公开测试文件、网页/Monaco 资源、窗口尺寸和动作序列；打开文件和冷启动单独记录。测试前记录实际 CPU/GPU、模式、缩放、实际可执行核心数、输入报告率、后台负载和电源配置。没有证据的条件不得填成相同。

需要覆盖指针移动、窗口拖动/缩放、长文本和网页滚动、普通文本和 Monaco 输入、菜单、窗口切换、冷开编辑器，以及后台初始化/编译/文件工作同时进行时的前台响应。每轮连续运动至少有 1000 个真实变化样本；输入延迟至少有 100 个能够关联输入与显示结果的样本。输入停止后的静态间隔不混入连续帧时间分布。

窗口拖动等场景不按固定 CPU 占用率判定。多核数量、后台线程数量及 GPU 使用率是定位依据，不能替代帧时间和输入延迟结果。

逐场景通过条件

比较帧间隔 P50/P95/P99、最坏值、长停顿比例、有效变化帧率和输入到显示的 P50/P95/P99，不仅比较平均 FPS。
帧间隔 P95/P99 不超过 Windows 对应值加 max(10%, 0.5 ms)；有效运动帧率至少为 Windows 的 98%。
输入到显示 P95/P99 不超过 Windows 对应值加一个实际刷新周期。在 240 Hz 下为约 4.167 ms。
超过 50 ms 的交互停顿比例不得高于 Windows 超过 0.1 个百分点；任何输入丢失、顺序错误、文本丢失、窗口残影、撕裂或内容渲染错误均单独失败。
完整编辑器就绪时间不超过 Windows 对应值加 max(10%, 10 ms)；前台响应在后台加载过程中仍必须单独通过。
所有场景和模式条件都通过才能标记 WindowsFluidityParityPassed=true。证据缺失标记“未验收”，不能解释为通过，也不能用宿主内存微基准或 QEMU 的结果补齐实体证据。

可复核的中间证据

Tools/DesktopFluidity/RenderProbe.csproj 使用实际生产 DesktopSession、CpuFramebufferCanvas 和映射内存 presenter，检查同一场景的输出哈希、pitch/边界及 CPU 帧时间。它仅用于定位与前后对照，不是 Windows 原生应用基线，也不是实体 GPU/显示性能验收。原生自动化则必须保留实际输入、完成帧和单调时钟数据；CPU 渲染完成与物理显示结果分别报告。

执行入口

dotnet run --project Tools/DesktopFluidity/RenderProbe.csproj -c Release -- build/RenderProbe-New.json：固定 4K/200% 的宿主内存绘制对照。输出包含逐帧原始 ticks、分配量、程序集与最终像素哈希；文件已存在时拒绝覆盖。
python Tools/DesktopFluidity/RunNative.py <Kernel.elf> <新证据目录> --seconds 30：验证源码绑定的自动分辨率镜像，通过实际 QMP 输入采集原生输入入队/消费和 framebuffer 完成时间。默认 WHPX，--input usb 使用真正的虚拟 xHCI HID 路径；设备实际报告率单独计量。此入口的 Completed=true 仅表示测量完成，SoftwareCadenceGoalMet 独立报告。
python Tools/IndependentKernel/TestHighResolutionDesktop.py <Kernel.elf> <System.img> <新证据目录>：实际 4K/150% 的 C# Monaco 打开、编辑、保存及新增注释字形像素检查。
Windows 对每个实际应用进程预热后运行 PresentMon.exe --process_id <PID> --timed 30 --terminate_after_timed --output_file <新CSV>；默认保留 display 和 input 跟踪。按场景重复五轮，并保留显示设备关联、实际变化帧和动作时间范围。某些应用没有独立 Present 事件；缺少归属的 DWM 多显示器混合记录不能替代该应用的帧率。
python Tools/DesktopFluidity/CheckAcceptance.py <Windows.json> <XFESystem.json> <新Result.json>：比较由真实显示/光学记录转换出的匹配数据。两份输入需引用 SHA256 绑定的原始记录和 XfeCanonicalPhysicalWorkloads 数据，场景数据必须与该原始数据一致。未取得物理显示证据时不能填成已测。

原生 F12 采集最多保存 16384 个完成帧，结束后才向诊断串口输出原始记录；30 秒/240 Hz 能装入该容量。日志状态可合并，输入、命令和原始计时样本不合并；诊断事件队列溢出会产生 XFE_DIAGNOSTIC_EVIDENCE_LOST 并使自动证据检查失败。F12 与测试期间的截图都不提供面板扫描时序。

参考：UEFI 的 Graphics Output Protocol 规定模式几何/像素格式和 SetMode；PresentMon 官方控制台说明说明实际显示跟踪和输入跟踪选项。验收门槛以上述本项目定义为准。