Chapter 129: Interactive Visualization and UX Design

交互式可视化的工程目标，是让用户一次操作能够稳定改变数据视图，并让屏幕反馈、GPU 资源更新、摄像机状态和多视图联动处在同一条可追踪路径上。本章用一个三视图科学可视化面板作为贯穿材料：左侧是三维体数据或流场主视图，右上是二维切片视图，右下是指标曲线视图。用户可以旋转主视图、拖动切片位置、框选异常区域、切换时间步，并在数据更新时看到进度、降级质量和错误提示。

这类界面的难点来自两个事实。第一，用户操作发生在 UI 事件系统中，渲染发生在 frame loop 中，数据加载和 GPU upload 又处在异步路径中。第二，多视图共享同一份数据语义，却拥有各自的 camera、projection、selection overlay 和 label policy。一个可用的系统需要把这些对象组织成有版本、有取消、有同步边界的状态机。

读完本章后，读者应能定位一次交互从 pointer event 到屏幕反馈的路径，判断多摄像机视角如何共享语义状态，追踪实时数据如何进入 GPU buffer 或 texture，设计 frame invalidation 和取消路径，并用任务完成时间、错误率、selection friction、反馈延迟和可读性指标复盘 UX 成本。

本章使用 Web 端表达示例，原因是浏览器事件、requestAnimationFrame、AbortController 和 WebGPU buffer upload 都有清晰公开文档。这里的结构同样可以迁移到 C++ 图形工具、Qt/OpenGL、Dear ImGui + Vulkan、Metal 桌面工具或 Unity 编辑器插件。API 名称会变化，核心路径仍然是 event → state mutation → data job → GPU resource update → render request → visual feedback。

129.1 多视角交互逻辑

多视角交互首先要区分两类状态：视图状态和语义状态。视图状态描述某个 viewport 如何观察数据，例如 camera position、target、zoom、slice plane、projection matrix 和 clipping range。语义状态描述用户正在研究什么，例如选中的体素区域、当前时间步、阈值范围、聚焦变量和高亮对象。三维主视图、二维切片视图和曲线视图可以共享同一份语义状态，同时保留不同的视图状态。

在贯穿材料中，主视图使用 orbit camera 观察一份气象体数据；切片视图使用 orthographic camera 显示当前高度层；曲线视图显示被框选区域的温度或速度统计。用户在主视图中旋转 camera 时，语义状态没有变化；用户在切片视图中拖动高度滑杆时，slice plane 改变，并且主视图中的半透明切面、二维纹理采样范围和曲线统计输入一起改变。这个差异决定了状态同步的粒度。

一个稳定的多视角模型可以拆成四层。输入层把 pointer、wheel、keyboard 和 UI 控件事件转成 action。状态层把 action 规约到 view state 或 semantic state。派生层根据状态生成 camera matrices、GPU uniform、selection mask 和 label layout。渲染层只读取当前版本的派生结果。这样做的收益，是每个视图的自由操作不会污染共享语义；共享语义变化又能明确触发需要更新的视图。

下面的 Mermaid 图描述一次框选操作如何同时影响三个视图。图中的路径只覆盖同步决策和渲染请求，数据加载和 GPU upload 会在下一节展开。

这条路径的关键点是共享语义只写一次。主视图和切片视图从 Selection mask 读取高亮范围，曲线视图从 Region statistics 读取聚合结果。任何视图都不直接修改另一个视图的内部 camera。若主视图完成一次拖拽框选，它提交的是“选择了哪个数据空间区域”，随后切片视图根据自己的投影方式显示同一区域。

多摄像机控制需要统一坐标语义。屏幕坐标来自 pointer event，视图坐标来自当前 viewport，世界坐标来自 camera inverse matrix，数据坐标来自数据集的 origin、spacing 和单位。三维主视图中的一次点击，需要从 screen ray 与 volume bounding box 的交点推回数据空间；二维切片视图中的一次点击，需要从屏幕坐标映射到切片平面，再映射到体数据索引。曲线视图中的一次点击，则映射到时间步或变量值区间。

这些映射可以用一张状态表固定下来。

操作位置	输入坐标	主要状态	输出语义	需要重绘的视图
三维主视图	pointer screen position	orbit camera、viewport rect、volume bounds	数据空间射线或选区	主视图、切片视图、曲线视图
二维切片视图	pointer screen position	slice camera、slice plane、data spacing	切片内数据点或范围	切片视图、主视图、曲线视图
曲线视图	pointer screen position	chart scale、time range、selected metric	时间步或数值范围	曲线视图、主视图、切片视图

统一坐标语义后，camera 控制和 selection 控制可以共享同一个 action log。DragOrbit 改变主视图 camera；DragSlicePlane 改变切片平面；BrushMetricRange 改变语义筛选范围。action log 记录输入类型、作用视图、旧状态版本和新状态版本。它同时服务 undo、replay、性能复盘和用户研究。

多视角还需要处理主从关系。主从关系表示哪个视图拥有当前操作焦点，哪些视图根据共享语义被动更新。三维主视图通常是空间探索的主视图，切片视图是局部验证视图，曲线视图是时间或指标解释视图。用户在曲线视图选中异常峰值后，主视图可以自动高亮对应区域，但不自动改变 camera；只有用户启用“跟随 selection”时，主视图 camera 才根据 bounding box 执行 framing。这个边界能减少突兀镜头移动。

多 camera 更新应使用派生值缓存。每个 viewport 保存自己的 viewVersion，共享语义保存 semanticVersion。当 viewVersion 变化时，只更新该 viewport 的 camera uniform 和相关 overlay；当 semanticVersion 变化时，更新所有依赖 selection、threshold 或 time step 的派生资源。这样能把一次 orbit drag 的成本限制在主视图，把一次 threshold change 的成本扩展到所有相关视图。

一个简化的状态结构如下。代码展示的是状态边界，真实工程中还会有 reducer、事件队列、资源管理器和 profiler。

type ViewId = "main3d" | "slice2d" | "chart";

type CameraState = {
  eye: [number, number, number];
  target: [number, number, number];
  zoom: number;
  projection: "perspective" | "orthographic";
  version: number;
};

type SemanticState = {
  timestep: number;
  selectedRegion: DataBounds | null;
  threshold: [number, number];
  focusedVariable: "temperature" | "velocity" | "density";
  version: number;
};

type VisualizationState = {
  cameras: Record<ViewId, CameraState>;
  semantic: SemanticState;
  activeView: ViewId | null;
};

这段结构的判断价值在于边界清晰。camera 状态属于单个 viewport，semantic 状态属于整个 visualization session。渲染器读取 VisualizationState 后生成 uniform buffer、selection texture、chart vertex buffer 和 label list。调试时若切片视图高亮位置错误，应先看数据坐标映射和 selection mask；若只有主视图镜头异常，应先看该 viewport 的 camera reducer。

129.2 实时数据反馈与渲染同步

实时数据反馈的核心问题，是用户触发的状态变化何时进入 GPU 资源，并在什么时刻请求下一帧。数据流更新可以来自滑杆、时间步播放器、网络流、文件分块读取或后台计算。渲染同步需要把这些来源汇合成一个有版本号的提交路径：新数据先进入 CPU-side staging，完成校验和转换后写入 GPU buffer 或 texture，随后标记依赖视图为 dirty，并通过 frame scheduler 请求绘制。

在 Web 示例中，requestAnimationFrame 的回调会在下一次 repaint 前执行，且一次调用只安排一次回调；持续动画需要在回调中再次安排下一帧。这个事实适合可视化工具使用“按需绘制”模型：状态无变化时不提交新帧，交互拖拽、数据到达、渐进 refine 或动画播放时才请求帧。桌面工具中的 swapchain present loop、Qt update、ImGui frame tick 也可以套入同一思想。

GPU upload 的边界需要被显式建模。以 WebGPU 为例，GPUQueue.writeBuffer 会把数据源写入 GPUBuffer，文档要求目标 buffer 可用、usage 包含 COPY_DST，offset 和数据尺寸满足对齐与范围校验。迁移到 Vulkan 或 Metal 时，具体 API 名称会变成 staging buffer、copy command、resource usage 或 blit encoder，但判断点仍然是：数据尺寸、资源状态、写入偏移、同步边界和后续 shader 读取方式。

实时反馈路径可以按五个版本号组织。

版本号	记录对象	变化来源	主要用途
inputVersion	用户操作序列	pointer、keyboard、UI control	支持 replay、undo、交互延迟测量
semanticVersion	数据语义状态	selection、threshold、timestep	决定派生数据和多视图联动
dataVersion	CPU 数据快照	loader、worker、stream chunk	决定统计结果、buffer 内容和错误提示
gpuVersion	GPU 资源内容	upload 成功、texture 更新	决定 shader 读取哪一版数据
frameVersion	屏幕已展示帧	render pass 完成	判断用户看到的反馈是否追上状态

这张表可以直接用于排查。若用户拖动阈值后 UI 文本变了，图像没有变化，先比较 semanticVersion 和 gpuVersion。若 GPU 资源更新了，屏幕仍显示旧图，比较 gpuVersion 和 frameVersion。若数据流持续更新但拖拽卡顿，比较 inputVersion 增长速率和每帧 upload 字节数。

取消路径是实时反馈的稳定性基础。用户快速拖动时间轴时，旧时间步加载任务会失去显示价值。Web 平台可用 AbortController 给异步请求传递取消信号；文档说明它可以中止一个或多个 Web 请求，并通过 AbortSignal 与异步操作通信。图形工具中的文件 IO、worker 计算和 GPU 预处理也应拥有同类取消令牌。取消成功后，旧任务的 CPU 结果不得覆盖新版本状态。

下面的简化 TypeScript 片段把状态变更、取消、GPU upload 和 frame invalidation 连接起来。它属于边界示例，重点是展示版本守卫和请求帧的关系。

let semanticVersion = 0;
let gpuVersion = 0;
let scheduledFrame: number | null = null;
let activeController: AbortController | null = null;

function requestFrame(): void {
  if (scheduledFrame !== null) return;
  scheduledFrame = requestAnimationFrame(() => {
    scheduledFrame = null;
    renderFrame({ semanticVersion, gpuVersion });
  });
}

async function setTimestep(nextTimestep: number): Promise<void> {
  semanticVersion += 1;
  const targetVersion = semanticVersion;

  activeController?.abort();
  activeController = new AbortController();
  showProgress({ phase: "loading", targetVersion });
  requestFrame();

  const payload = await loadTimestepChunk(nextTimestep, activeController.signal);
  if (targetVersion !== semanticVersion) return;

  const uploadResult = uploadVolumeTexture(payload);
  gpuVersion = uploadResult.version;

  showProgress({ phase: "ready", targetVersion });
  requestFrame();
}

这段代码的关键判断是 targetVersion !== semanticVersion。它把“任务完成顺序”和“用户当前意图”分开处理。旧任务完成后可以释放资源、记录统计或写入缓存，但它没有资格更新当前可见图像。requestFrame() 使用单帧合并策略，多次状态变更在同一个 frame 前合并成一次渲染请求。

实时反馈还需要区分即时反馈和精确反馈。即时反馈是在 50 到 100 毫秒内给用户一个明确响应，例如滑杆数值、loading overlay、粗糙降采样结果或 selection outline。精确反馈是在数据加载、统计重算和 GPU upload 完成后展示的最终图像。大数据可视化中，精确反馈可能超过一个 frame；此时 UI 必须把“正在使用低精度数据”“正在加载下一个 tile”“当前结果来自上一版 GPU 资源”表达出来。

同步失败通常有三类。第一类是 stale commit：旧异步结果覆盖新状态。版本号和取消令牌负责处理。第二类是 partial GPU update：部分 buffer 或 texture 更新成功，关联 uniform、legend 或 label 仍是旧版。资源提交应使用 transaction，把一组 GPU 资源标记为同一 gpuVersion。第三类是 visual silence：状态变化已经发生，但用户没有看到任何反馈。frame invalidation、progress overlay 和错误面板负责把系统状态显性化。

在多视图面板中，实时数据路径可以使用 dependency graph 控制重算范围。时间步变化通常影响 volume texture、slice texture、chart data 和 legend；camera orbit 只影响主视图 uniform；threshold 改变影响 transfer function、selection mask 和 chart filter；窗口 resize 影响 viewport rect、projection matrix 和 label layout。依赖图越明确，交互成本越可控。

129.3 事件驱动机制

事件驱动机制负责把零散输入组织成稳定操作。pointer down、pointer move、pointer up、wheel、keydown、slider input 和 menu action 本身只是低层事件；可视化系统需要把它们提升为 BeginOrbit、UpdateBrush、CommitSlicePlane、CancelSelection 和 PlayTimestep 这类领域 action。渲染器不直接处理 DOM event 或窗口消息，它处理已经规约过的 visualization action。

事件驱动的基本路径是 capture → classify → reduce → derive → invalidate → render。capture 读取原始事件和当前 viewport；classify 判断这是 camera 操作、selection 操作、UI 控件操作还是全局快捷键；reduce 修改状态；derive 生成渲染所需派生对象；invalidate 标记需要重绘的视图；render 在 frame loop 中读取最终状态。这个路径把高频 pointer move 与昂贵渲染分离，使事件处理可以保持轻量。

在浏览器中，拖拽类操作还需要 pointer capture。setPointerCapture 的文档说明，一个元素可以成为后续 pointer event 的 capture target，直到释放 capture 或触发 pointerup。对于切片滑杆、三维旋转和框选，这能保证指针移出 viewport 边界时操作仍然连贯。桌面工具中同类能力通常由 mouse capture、grab mouse 或 active tool ownership 提供。

下面的代码展示事件进入 reducer 前的归一化。代码省略了矩阵计算，只保留事件到 action 的边界。

type VizAction =
  | { kind: "BeginOrbit"; view: ViewId; pointerId: number; x: number; y: number }
  | { kind: "UpdateOrbit"; view: ViewId; x: number; y: number }
  | { kind: "EndPointerTool"; view: ViewId; pointerId: number }
  | { kind: "BrushRegion"; view: ViewId; rect: ScreenRect }
  | { kind: "SetThreshold"; range: [number, number] };

function onPointerDown(event: PointerEvent, view: ViewId): void {
  const viewport = getViewportElement(view);
  viewport.setPointerCapture(event.pointerId);

  dispatch({
    kind: event.shiftKey ? "BrushRegion" : "BeginOrbit",
    view,
    pointerId: event.pointerId,
    x: event.clientX,
    y: event.clientY,
    rect: startRect(event.clientX, event.clientY),
  } as VizAction);
}

function onPointerMove(event: PointerEvent, view: ViewId): void {
  if (!hasActivePointerTool(view, event.pointerId)) return;
  dispatch({ kind: "UpdateOrbit", view, x: event.clientX, y: event.clientY });
}

function onPointerUp(event: PointerEvent, view: ViewId): void {
  getViewportElement(view).releasePointerCapture(event.pointerId);
  dispatch({ kind: "EndPointerTool", view, pointerId: event.pointerId });
}

这段代码刻意把 PointerEvent 限制在事件边界内。进入 reducer 后，系统只看到 VizAction。这个分层让同一套交互逻辑可迁移到原生窗口系统，也便于把 action 序列用于回放测试。代码中的类型联合为了展示边界而压缩，真实工程会拆出不同 action 构造函数，防止一个 action 同时携带无关字段。

事件频率和渲染频率需要分开控制。pointer move 可能在一个 frame 间隔内到达多次，渲染只需要读取最新状态。wheel zoom 和 slider input 可以用 coalescing 合并，keydown 操作通常需要按事件顺序执行，selection commit 则需要保留起止点和中间预览。事件队列应记录所有会影响语义的离散操作，高频连续操作可以只保留最后一个 preview state。

事件驱动还要处理焦点和模式。三维视图常见模式包括 orbit、pan、zoom、brush、inspect 和 measure。模式切换如果分散在各个 view 的事件回调中，会导致快捷键、鼠标按钮和 UI toggle 互相覆盖。更稳的结构是设置一个 active tool registry：每次 pointer down 由 registry 决定当前工具；工具拥有 begin、update、commit、cancel 四个阶段；工具提交的结果再进入共享状态。

工具阶段可以这样理解。begin 阶段锁定 pointer、记录起点和状态版本。update 阶段生成 preview，通常只触发 overlay 重绘。commit 阶段把结果写入语义状态，例如 selection bounds 或 slice plane。cancel 阶段撤销 preview，并让 UI 返回上一个稳定状态。这个阶段划分让 Esc 取消、右键中止、窗口失焦和数据加载失败都有统一入口。

事件驱动的渲染同步应使用 dirty flag 或 invalidation reason。dirtyCamera 表示只更新 camera uniform；dirtySelection 表示更新 selection overlay；dirtyData 表示需要重建 GPU 资源；dirtyLayout 表示 label 和 viewport layout 需要重新计算。frame scheduler 根据 dirty reason 决定 render pass、buffer upload 和 UI repaint 的范围。

一个实用的检查顺序是：先确认原始事件是否进入正确 viewport，再确认 action 是否带上 view id 和 pointer id，接着确认 reducer 修改的是 view state 还是 semantic state，然后看 dirty reason 是否覆盖对应资源，最后看下一帧是否读取了新版本。这个顺序能把“拖不动”“拖动延迟”“拖动影响了错误视图”拆成不同层级的问题。

129.4 多视图联动与实时更新

多视图联动的目标，是让一个视图中的操作以可解释方式影响其他视图。联动可以分为 selection linking、camera linking、time linking、filter linking 和 annotation linking。每一种联动都有不同的数据依赖。selection linking 依赖数据空间 id 或 bounds；camera linking 依赖 view transform；time linking 依赖 timestep；filter linking 依赖变量范围；annotation linking 依赖用户标注和数据坐标。

贯穿材料中的一次典型操作是：用户在曲线视图中框选一个异常峰值，系统把峰值对应的时间区间写入 semantic state，然后主视图切换到该时间步并高亮空间区域，切片视图显示同一时间步的局部切片，曲线视图保留选中区间。这里的联动主语是“时间区间和数据区域”，主视图和切片视图只是不同显示方式。

联动关系应通过 link policy 显式配置。默认策略可以是 selection 同步、time 同步、filter 同步；camera 同步需要用户开启。原因在于 camera 自动同步会改变用户的空间定位，频繁镜头跳转会增加方向恢复成本。相比之下，selection、time 和 filter 的同步更接近数据语义，用户更容易预期它们带来的视觉变化。

下面的表把常见联动和更新成本放在同一组维度下比较。

联动类型	共享状态	典型触发	GPU 或布局成本	UX 风险
selection linking	selected ids 或 data bounds	框选、点击、lasso	overlay buffer、mask texture、chart highlight	高亮过密导致读数困难
time linking	timestep 或 time range	播放、曲线框选	volume texture、streamline buffer、chart vertices	旧任务覆盖新状态
filter linking	threshold、category、metric range	slider、legend click	transfer function、instance visibility、legend	过滤条件隐藏上下文
camera linking	camera target、zoom、orientation	view sync toggle	camera uniform、culling	突然镜头移动增加恢复成本
annotation linking	note、marker、label anchor	标注、测量	label layout、marker buffer	标签遮挡数据

实时更新需要分清 preview 和 commit。用户拖动 threshold slider 时，preview 可以用低分辨率 transfer function 或上一版数据快速反馈；用户松手后再提交精确统计和高质量重绘。用户框选区域时，preview 展示屏幕空间矩形和粗略数据 bounds；commit 阶段再生成 selection mask、统计曲线和 annotation。preview 追求响应，commit 追求一致性。

多视图联动还涉及资源复用。三维主视图和二维切片视图可以共享同一份 volume texture，但使用不同 shader pass。曲线视图通常使用 CPU 或 compute pass 得到聚合统计，再上传 vertex buffer。selection mask 可以用一张 3D mask texture、一个 id buffer 或一个 bounds list 表达。选择哪种表示取决于数据规模、更新频率和 shader 读取方式。

当数据规模较大时，联动更新应支持渐进显示。时间步切换可以先展示低分辨率 volume mip 或已缓存 tile，再逐步补齐高分辨率块。selection 统计可以先显示近似计数，再显示精确曲线。UI 文案应明确当前质量级别，例如 “preview quality”、 “loading high resolution tiles” 或 “statistics updating”。这样用户能把视觉变化和系统工作阶段对应起来。

实时更新中的错误也要进入联动模型。若主视图某个 tile 加载失败，切片视图可能仍能显示已缓存的切面，曲线视图可能只能显示旧统计。此时错误状态应附着在数据版本上，而非只弹出一次 toast。视图可以分别读取错误范围：主视图显示 tile 边界 overlay，切片视图在缺失区域显示 hatch pattern，曲线视图标记统计值来自不完整样本。错误反馈越接近数据位置，用户越容易判断当前图像的可信范围。

下面的伪代码展示 link policy 如何控制多视图更新范围。它把“语义变化”和“视图响应”分开，便于测试每个联动策略。

type LinkPolicy = {
  syncSelection: boolean;
  syncTime: boolean;
  syncFilter: boolean;
  syncCamera: boolean;
};

function applySemanticChange(change: SemanticChange, policy: LinkPolicy): Invalidation[] {
  const invalidations: Invalidation[] = [];

  if (change.kind === "SelectionChanged" && policy.syncSelection) {
    invalidations.push({ view: "main3d", reason: "selection-overlay" });
    invalidations.push({ view: "slice2d", reason: "selection-overlay" });
    invalidations.push({ view: "chart", reason: "selection-statistics" });
  }

  if (change.kind === "TimestepChanged" && policy.syncTime) {
    invalidations.push({ view: "main3d", reason: "volume-texture" });
    invalidations.push({ view: "slice2d", reason: "slice-texture" });
    invalidations.push({ view: "chart", reason: "chart-buffer" });
  }

  return invalidations;
}

这段代码把联动策略转成 invalidation 列表。真实工程里，列表还会进入 resource scheduler，决定哪些 upload 可以合并，哪些视图只需更新 overlay，哪些视图需要显示 loading。若某个视图响应了错误联动，可以直接检查 change.kind、policy 和 invalidation reason。

多视图实时更新的性能瓶颈通常出现在三个位置。CPU 侧可能在每次 pointer move 中重算大范围统计；GPU 侧可能频繁上传大 texture 或重建 buffer；UI 侧可能在每帧重新布局大量 label。对应的控制方法是：preview 阶段使用轻量派生值，commit 阶段执行昂贵计算；GPU upload 按 tile、range 或 dirty span 执行；label layout 按视图和缩放层级缓存。

联动系统还需要可解释的关闭路径。用户可以临时锁定某个视图，例如锁定切片视图在当前高度层，同时继续在主视图旋转和切换时间步。锁定并不意味着视图脱离系统，它仍然读取共享数据版本和错误状态，只是忽略某些 link policy。UI 应显示锁定标识和当前数据版本，防止用户误把旧视图当成同步结果。

129.5 Visualization Usability Metrics and Interaction Cost Control

交互式可视化的 UX 质量需要用任务指标和系统指标一起评估。任务指标回答用户能否完成分析，例如任务完成时间、错误率、回退次数和答案准确性。系统指标回答界面是否及时反馈，例如 input-to-feedback latency、frame time、upload time、loading duration 和 stale frame count。可读性指标回答用户能否解释图像，例如 contrast、label density、occlusion rate、legend clarity 和 selection visibility。

任务完成时间要按具体任务定义。对于贯穿材料，可以设置三个任务：在三维主视图中定位异常区域，在切片视图中确认异常高度，在曲线视图中读出异常时间区间。每个任务记录开始时间、首次有效反馈时间、最终提交时间和纠错次数。单纯记录总耗时会隐藏问题来源；分段记录能区分“找不到入口”“反馈太慢”“读数不清”“联动造成混乱”。

错误率也要分类。selection 错误表示用户选中错误空间范围；interpretation 错误表示用户看到了正确图像但读错含义；operation 错误表示用户触发了错误工具或错误视图；stale-result 错误表示用户基于旧数据作出判断。不同错误对应不同修复路径。selection 错误需要改善 hit test、hover feedback 或 selection outline；interpretation 错误需要改善 legend、color scale 和 label；stale-result 错误需要改善版本提示和 loading state。

selection friction 可以被拆成可观察成本。一次 selection 的摩擦来自进入工具的步骤数、指针移动距离、预览反馈延迟、修正次数、取消成本和结果确认成本。工程上可以把每次 selection 记录为 action trace：tool_entered、pointer_down、preview_updated、commit、undo、reselect。trace 能还原用户在哪里犹豫、哪里误触、哪里等待。

反馈延迟应以用户可见反馈为准。pointer down 后立即出现 hover highlight 或 drag rectangle，属于低成本反馈；数据加载完成后才出现最终 volume，是高成本反馈。对交互式可视化而言，首个可见反馈的时间常常比最终精确结果的时间更影响操作节奏。一个实用预算是：同帧或下一帧给出操作确认，100 毫秒内给出明显状态变化，长任务显示进度和取消入口。

可读性指标需要落到图形结果。对体数据和流场视图，selection outline 的颜色、厚度、透明度和深度测试策略会影响可见性；对曲线视图，label density、tick spacing 和 brush overlay opacity 会影响读数；对多视图面板，legend 与视图的距离会影响用户把颜色映射回变量的速度。可读性差会直接增加任务时间和错误率。

下面的表给出一组可以在工程中落地的指标。它们不依赖特定 GPU，也不要求完整用户研究环境。

指标	采集方式	说明的问题	常见阈值判断
input-to-preview latency	action time 到 preview draw time	操作是否被立即确认	超过 100 ms 用户会感到迟滞
input-to-final latency	action time 到最终数据版本显示	精确结果是否跟上分析节奏	长任务需要进度和取消入口
stale frame count	frameVersion 落后 semanticVersion 的帧数	屏幕是否展示旧语义	持续增长说明提交路径失控
selection correction count	commit 后 undo 或 reselect 次数	selection 摩擦和命中精度	高频修正说明反馈或 hit test 有问题
task error rate	用户答案与目标结果比较	图像解释是否可靠	按任务类型分开统计
label occlusion rate	label bbox 与数据区域重叠比例	标注是否遮挡数据	高遮挡需要布局或缩放策略
frame time percentile	P50、P95、P99 frame time	卡顿是否集中在尾部	P95 更能反映交互抖动

指标采集要绑定状态版本。记录一条 latency 时，应同时写入 action kind、view id、semanticVersion、dataVersion、gpuVersion、frameVersion、dirty reason 和数据规模。这样一次慢操作可以追到具体资源路径。若 input-to-preview latency 高但没有 GPU upload，问题大概率在事件处理、layout 或主线程阻塞。若 preview 快、final 慢，问题大概率在数据加载、统计计算或 GPU 资源提交。

交互成本控制可以按优先级执行。第一层是确认反馈，任何操作都应快速显示 hover、active tool、drag outline、loading 或 error。第二层是数据版本清晰，用户应知道当前图像来自哪个时间步、哪个阈值和哪个质量级别。第三层是昂贵任务可取消，尤其是时间步加载、统计重算和高分辨率 tile 请求。第四层是多视图联动可配置，用户可以锁定视图、关闭 camera sync 或暂停自动播放。

性能优化要和 UX 指标闭环。把每次 pointer move 都上传完整 volume texture，可能让最终图像准确，但会拉高 input-to-preview latency。把所有统计计算推迟到 commit，可以保持拖拽流畅，但 preview 信息较少。合理方案通常是 preview 用轻量路径，commit 用精确路径；preview 结果必须有视觉标识，防止用户把低精度结果当成最终结论。

可用性复盘可以使用同一条检查顺序。先看任务是否有明确目标和完成条件；再看用户操作是否产生即时反馈；接着看数据、GPU 和 frame 版本是否按顺序追上；然后看多视图联动是否符合用户预期；最后看错误率和修正次数是否集中在某个工具或视图。这个顺序把主观体验拆成可测对象，能指导下一轮工程修改。

本章的核心结论是：交互式可视化 UX 是一条跨输入事件、语义状态、GPU 资源、渲染帧和用户任务指标的闭环。多视角控制解决观察路径，实时数据同步解决状态到图像的版本一致性，事件驱动机制解决输入到 action 的可追踪性，多视图联动解决同一数据语义的多种表达，可用性指标把这些工程路径转化为可复盘成本。

最小自检任务

设计一个三视图可视化面板：主视图显示三维体数据，切片视图显示当前高度层，曲线视图显示选中区域的时间序列。用户在曲线视图框选一个时间区间后，主视图和切片视图需要更新到对应时间步，并显示 loading、preview 和最终结果。请写出一次操作从事件到屏幕反馈的最小路径，并说明如何判断该路径是否存在 stale commit、selection friction 或反馈延迟过高。

答案要点

一次操作应从曲线视图的 pointer 或 brush event 开始，事件边界先把原始输入规约成 BrushMetricRange 或 TimestepChanged action。reducer 更新共享 semantic state，递增 semanticVersion，并根据 link policy 生成主视图、切片视图和曲线视图的 invalidation reason。若新时间步需要加载数据，系统创建取消令牌并取消旧任务，同时显示 loading 或 preview，随后请求下一帧。

数据到达后，系统应检查任务持有的 targetVersion 是否仍等于当前 semanticVersion。匹配时再执行 CPU 转换、GPU upload、资源版本提交和最终 frame invalidation；失配时释放旧结果或放入缓存，不更新当前可见状态。GPU 资源提交应让 volume texture、slice texture、chart buffer、legend 和错误状态进入同一 gpuVersion，防止部分资源显示新数据、部分资源仍停留在旧语义。

stale commit 的判断步骤是比较 semanticVersion、dataVersion、gpuVersion 和 frameVersion。若用户当前语义版本高于完成任务的目标版本，旧任务结果没有资格提交。selection friction 的判断步骤是查看工具进入次数、预览更新延迟、commit 后 undo 或 reselect 次数，以及框选结果是否稳定映射到数据区间。反馈延迟过高的判断步骤是测量 action time 到 preview draw time，再测量 action time 到最终数据版本显示；若 preview 超过 100 毫秒，应优先检查事件处理、layout、主线程任务和无意义的大资源 upload。

本章知识点总结

• 状态分层：多视图系统应把单个 viewport 的 camera state 和全局 semantic state 分开保存。
• 坐标映射：pointer 输入需要经过 viewport、camera、world 和 data space 的连续映射，才能形成稳定 selection。
• 共享语义：selection、time step、threshold 和 focused variable 属于共享语义，多个视图读取同一版本。
• 版本守卫：实时数据路径应使用 input、semantic、data、GPU 和 frame 版本追踪状态推进。
• 取消路径：快速切换时间步或阈值时，旧异步任务应通过取消令牌和版本检查失去提交资格。
• 帧请求：按需绘制模型用 frame invalidation 合并多次状态变化，减少无意义重绘。
• 事件规约：原始 pointer、wheel 和 keyboard 事件应先转成 visualization action，再进入状态 reducer。
• 工具阶段：交互工具应具备 begin、update、commit 和 cancel 阶段，便于处理预览、提交和中止。
• 联动策略：selection、time、filter、camera 和 annotation linking 应通过 link policy 显式控制。
• 预览提交：preview 路径提供快速反馈，commit 路径提交精确数据和最终 GPU 资源。
• 错误贴近数据：加载失败、缺失 tile 和旧统计应显示在对应数据位置或视图范围内。
• 摩擦度量：selection friction 可由工具入口、指针路径、预览延迟、修正次数和取消成本衡量。
• 延迟拆分：input-to-preview latency 和 input-to-final latency 应分别记录，分别对应操作确认和精确结果。
• 可读性指标：contrast、label density、occlusion rate 和 legend clarity 会直接影响任务完成时间和错误率。
• 复盘顺序：UX 复盘应先看任务目标，再看即时反馈、版本推进、多视图联动、错误率和修正次数。