Chapter 128: Interaction Models

交互模型把可视化从一张静态图变成一条可追踪的数据路径：用户移动指针、按下键盘、拖动刷选框或缩放视图，系统把这些输入转换成状态变更，再把状态变更转换成数据查询、GPU 资源更新、渲染请求和可见反馈。本章讨论的主问题是：怎样设计一套交互模型，使科学可视化中的 hover、selection、drag、zoom、多视图联动、loading、error 和 undo 都能被追踪、评估和调试。

贯穿本章的材料是一帧交互式流场可视化界面。界面包含三个视图：左侧是时间轴直方图，中间是二维流场热力图，右侧是三维流线视图。用户在时间轴上拖出一个 brush 区间，热力图只显示这个时间范围内的局部统计，三维视图高亮对应流线；用户 hover 某条流线时，属性面板显示速度、涡量和采样时间；用户缩放热力图时，系统按当前视口请求更细粒度 tile。这个例子覆盖输入事件、交互状态、渲染增量、多视图联动和体验评估。

本章的最终判断是：交互模型的核心产物是一份稳定的 interaction state，而交互工程的核心工作是控制这份状态如何被事件修改、如何触发最小必要渲染、如何反馈给用户、如何在多个视图之间保持一致。交互响应的好坏可以落到具体证据：事件到反馈的延迟、每次操作触发的 GPU upload、dirty region 范围、任务完成时间、误选率和撤销成本。

128.1 人机交互在可视化中的角色

科学可视化中的交互负责把“看见图像”推进到“验证数据关系”。在流场界面中，静态热力图只能告诉用户某个区域颜色较深；交互允许用户把时间区间、空间位置、流线编号和数值属性连接起来。用户拖动时间轴 brush 后，系统把时间范围写入 interaction state，热力图根据这个范围重算统计，三维视图根据同一状态高亮流线。用户得到的结论来自这一整条路径，而非来自单张图像。

交互模型首先要定义用户动作对应的工程对象。hover 对应一个临时命中对象，selection 对应一个可持久保存的数据集合，drag 对应持续变化的操作会话，zoom 对应相机或尺度状态，loading 对应异步查询或资源上传进度，error 对应可恢复的失败状态，undo 对应状态快照或可逆命令。把这些对象混在渲染函数内部，会让视觉结果难以复盘；把它们集中到 state 中，系统才能回答“哪次输入改变了哪份数据，哪份数据触发了哪次渲染”。

交互在可视化中还承担错误暴露功能。用户框选一个时间段后，热力图没有变化，可能是数据查询失败，也可能是 brush 区间没有命中数据，还可能是 GPU selection buffer 没有上传。稳定的交互模型会把这些情况拆成不同状态：loading 表示查询进行中，emptySelection 表示查询成功且结果为空，error 表示请求或解码失败，staleView 表示视图仍显示旧结果。用户界面显示的文字、遮罩和按钮，都应该来自这些状态。

下面的图描述本章使用的交互闭环。它的边界从输入事件开始，到用户看到反馈结束；数据清洗、离线预处理和后端存储属于本章前置条件。

这条路径的关键点是 state 处在中间。事件归一化把鼠标、触摸、笔和键盘输入整理成统一意图；interaction state 保存当前 hover、selection、camera、loading、error 和 undo 信息；渲染系统读取 state 并生成最小必要变化。这样设计后，RenderDoc、浏览器 Performance 面板或自定义统计日志都能对齐到同一条因果链：输入事件到达、状态变更、资源上传、draw call 或 pass 重画、反馈出现在屏幕上。

交互模型的设计目标可以用一个小表固定下来。表中的每一行都是可观察对象，调试时可以逐项检查。

交互对象	State 字段	渲染影响	可观察证据
Hover	hoverId、hoverPosition	overlay 或属性面板更新	指针移动后高亮是否跟随
Selection	selectedIds、brushRange	selection buffer、颜色编码、过滤条件更新	被选数据在多个视图是否一致
Drag	dragSession、dragOrigin、dragDelta	相机、brush、gizmo 或视口区域持续变化	拖动中是否稳定跟手
Zoom	camera、scaleDomain	view/projection 矩阵、LOD、tile 请求变化	缩放后细节和坐标读数是否匹配
Loading	pendingRequest、progress	skeleton、遮罩、渐进式结果	用户是否知道系统正在处理
Error	errorCode、retryAction	错误提示、回退视图、重试入口	失败后能否恢复到上一状态
Undo	history、currentCommand	回到上一组 state 与资源差异	撤销后视图、选择和面板是否同步

这张表也说明了交互与渲染的边界。交互层只产生命中对象、区间、相机和命令；渲染层负责根据这些状态生成图像。GPU shader 可以根据 selectedIds 改变颜色，但 shader 内部不负责判断用户拖动是否结束。API 层可以上传 selection buffer，但它不决定一次 brush 的语义。边界清楚后，复杂交互才有可维护的调试入口。

128.2 Interaction State Feedback and Event Latency Design

反馈设计的核心问题是让用户在每个交互阶段都知道系统已经接收输入、正在处理什么、当前结果是否可信。响应时间研究中常用的 0.1 秒、1 秒、10 秒界限来自人机交互领域的经典经验：约 0.1 秒内的反馈会被感知为即时，约 1 秒以内通常保持操作流，约 10 秒后需要明确进度反馈；Nielsen Norman Group 的 Response Times: The 3 Important Limits 对这三个界限有清晰描述。可视化系统不应机械套用数字，但可以用它们设计 latency budget。

在流场界面中，hover 的反馈预算最短。用户移动指针后，高亮、tooltip 锚点或属性预览应该在同一帧或下一帧出现；如果每次 hover 都触发完整数据查询，用户会看到光标和反馈脱节。稳定做法是把 hover 拆成两层：第一层只用屏幕空间 picking buffer 或 CPU 空间索引给出临时命中，第二层在属性面板中异步补齐详细字段。第一层保证跟手，第二层允许显示 loading 占位。

Selection 的反馈可以分阶段。拖动 brush 时，系统先更新屏幕上的选择框和局部高亮；拖动结束后，再触发较重的数据查询、GPU selection buffer 上传和多视图重算。D3 的 d3-brush 文档把 brushing 定义为通过指针手势指定一维或二维选区，并说明选区可以用于选择离散元素、缩放区域或交叉过滤数据。这个定义对应到工程上，就是把“拖动中的几何范围”和“提交后的数据过滤条件”分成两个状态。

下面的状态表把一个 brush 操作拆成可反馈阶段。每个阶段都能映射到界面反馈和渲染成本。

阶段	State 变化	即时反馈	延迟路径
idle	没有活跃操作	普通光标与当前选择	无
dragging	更新 brushDraftRange	选择框、局部半透明遮罩	暂停重查询
committing	brushRange = brushDraftRange	显示提交中状态	数据过滤、tile 请求、GPU upload
ready	更新 selectedIds 和统计结果	多视图高亮与面板数值	无
failed	写入 errorCode 和 retryAction	保留上一结果并显示错误	等待用户重试或撤销

这个表中的 brushDraftRange 和 brushRange 是不同状态。前者服务拖动跟手，后者服务数据语义。二者分开后，系统可以在拖动中维持 60Hz overlay 更新，同时在提交阶段只执行一次较重的过滤和上传。对于大数据集，提交阶段还可以显示局部粗略结果，再用后台任务替换成完整结果。

Pointer 输入本身也有延迟设计空间。W3C 的 Pointer Events Level 3 把 pointer 定义为硬件无关的输入点，覆盖鼠标、笔和触摸，并在 2026 年候选推荐草案中列出高频 pointerrawupdate、coalesced events 和 predicted events 等特性。可视化工具可以优先用统一的 pointer 事件处理 drag、brush 和 picking，再根据 pointerType 为笔压、触摸面积或鼠标滚轮补充特定逻辑。

事件反馈还要覆盖 loading、error 和 undo。loading 的作用是说明当前画面是否代表最新 state；error 的作用是给用户一条恢复路径；undo 的作用是把错误操作成本降下来。以时间轴 brush 为例，查询进行中时，热力图可以保持旧结果并叠加“更新中”标记；请求失败时，系统显示失败原因和重试入口，同时保留上一次成功结果；用户按下撤销时，brushRange、selectedIds、相机和属性面板一起回到上一快照。用户体验的稳定性来自这组状态的一致回退，而非来自单个提示气泡。

128.3 事件处理与实时更新

事件处理的任务是把高频、碎片化、设备相关的输入转换成少量语义清晰的状态变更。浏览器、桌面 GUI 和游戏引擎都会产生 pointer、keyboard、wheel、resize、focus、blur 等事件；科学可视化系统需要把这些事件归一化为 hover、select、pan、zoom、submit、cancel、undo 等意图。归一化层越薄越好，它只读取事件坐标、按钮、修饰键和目标视图，然后把动作交给 reducer 或 command handler。

实时更新需要把事件频率和渲染频率分开。指针移动可能高于显示刷新率，数据过滤可能低于刷新率，GPU upload 还可能受队列和资源状态影响。MDN 的 requestAnimationFrame 说明它会在下一次 repaint 前调用回调，且回调频率通常匹配显示刷新率。Web 可视化中常见做法是事件只更新 state 和 dirty 标记，真正的绘制统一排到 requestAnimationFrame。桌面引擎中同样可以用 frame scheduler 或 render loop 执行相同策略。

下面的 TypeScript 简化代码展示事件到状态、dirty flag 和增量重绘的关系。它省略框架细节，只保留关键路径。

type InteractionState = {
  hoverId: number | null;
  brushDraftRange: [number, number] | null;
  brushRange: [number, number] | null;
  selectedIds: Uint32Array;
  camera: { x: number; y: number; zoom: number };
  pendingRequest: string | null;
  errorCode: string | null;
};

type DirtyFlags = {
  overlay: boolean;
  camera: boolean;
  selectionBuffer: boolean;
  dataQuery: boolean;
};

function applyPointerMove(
  state: InteractionState,
  dirty: DirtyFlags,
  event: PointerEvent
): void {
  if (state.brushDraftRange) {
    state.brushDraftRange = updateBrushDraft(state.brushDraftRange, event.clientX);
    dirty.overlay = true;
    return;
  }

  const hit = pickFlowLine(event.clientX, event.clientY);
  if (hit.id !== state.hoverId) {
    state.hoverId = hit.id;
    dirty.overlay = true;
  }
}

function commitBrush(state: InteractionState, dirty: DirtyFlags): void {
  if (!state.brushDraftRange) return;
  state.brushRange = state.brushDraftRange;
  state.brushDraftRange = null;
  state.pendingRequest = createRequestToken();
  dirty.overlay = true;
  dirty.dataQuery = true;
}

function redraw(state: InteractionState, dirty: DirtyFlags): void {
  if (dirty.dataQuery) startFilteredDataQuery(state.brushRange, state.pendingRequest);
  if (dirty.selectionBuffer) uploadSelectionBuffer(state.selectedIds);
  if (dirty.camera) updateCameraUniform(state.camera);
  if (dirty.overlay) drawInteractionOverlay(state);
  drawFrame(state);
  clearDirtyFlags(dirty);
}

这段代码体现三个判断。第一，pointer move 的主路径只更新 hover 或 brush draft，不启动重型数据查询。第二，brush 提交才产生 dataQuery dirty flag，系统可以把它放入异步队列。第三，overlay、camera、selection buffer 和 data query 是不同脏标记，对应不同成本：overlay 通常是 CPU/UI 或轻量 pass，camera 是 uniform 更新，selection buffer 是小型 GPU upload，data query 可能触发 CPU 过滤、IO 或 compute pass。

Keyboard event 需要进入同一套意图层。Escape 可以取消当前 drag 或关闭 tooltip，Enter 可以提交当前筛选，方向键可以移动焦点，Ctrl+Z 或 Cmd+Z 可以触发 undo。键盘操作的关键是焦点和可访问性：当前焦点在哪个视图、哪个 mark 或哪个控件上，决定按键会修改相机、选择集还是 UI 控件。将键盘映射成 command 后，系统可以让鼠标、触摸和键盘共享同一套撤销栈。

Debounce 和 incremental redraw 是控制实时更新成本的两个工具。Debounce 适合把连续输入压缩成一次重计算，例如拖动结束 80 到 150 毫秒后再提交过滤请求；incremental redraw 适合把大渲染拆成局部更新，例如 brush 拖动中只更新 overlay，提交后再更新热力图 tile 和三维高亮。二者的使用依据是成本：当操作只改变屏幕几何，应走增量绘制；当操作改变数据查询，应走提交后更新；当操作改变相机，应优先更新矩阵和 LOD 请求。

实时更新还要处理过期请求。用户连续拖动时间轴时，前一次查询可能晚于后一次查询返回。状态中保存 pendingRequest token 后，系统只接受最新 token 对应的结果；旧结果到达时直接丢弃或写入缓存，但不覆盖当前视图。这个策略能保证视觉反馈对应最后一次用户意图，也能减少多视图联动中的错配。

128.4 多视图与联动交互方案

多视图联动的主问题是让多个视图共享同一份语义状态，同时保留各自的坐标系、渲染资源和视觉编码。流场界面中的时间轴、热力图和三维流线视图观察同一组数据，但它们的空间完全不同：时间轴使用时间坐标，热力图使用二维空间坐标，三维视图使用世界坐标和相机矩阵。联动层需要在这些坐标之间传递数据 ID、时间范围、空间范围和统计聚合，而非传递屏幕像素。

最稳定的联动中心是 shared selection model。它保存三类信息：数据语义 ID，例如流线编号、粒子编号或网格 cell ID；约束条件，例如时间范围、空间范围和变量阈值；来源信息，例如这次变更来自时间轴 brush、热力图框选还是三维 picking。每个视图订阅 shared model 后，根据自己的映射函数决定如何显示：时间轴显示选中时间段，热力图显示过滤后的密度，三维视图高亮命中的流线。

下面的图展示三视图联动的数据路径。图中的中心节点是 shared state，视图之间不直接互相调用。

这张图中的“视图之间不直接互相调用”是工程约束。时间轴 brush 不应该直接调用三维视图的 highlightLines；它只提交 brushRange 和 sourceView = "timeline"。三维视图收到 shared state 后，自行决定是否上传 selection buffer、是否调整材质颜色、是否显示局部 bounding box。这样处理后，加入第四个视图只需要订阅 shared state，而不会在旧视图代码中加入新依赖。

多视图联动需要处理循环更新。时间轴修改 shared state 后，热力图响应并更新；如果热力图的响应过程又提交一次等价 selection，系统可能进入循环。解决方式是在 state mutation 中保存 source 和 revision。每次提交新状态时生成递增版本号，视图在响应时只处理高于自己已处理版本的变化；由渲染反馈产生的内部更新不得再次作为用户意图提交。这个规则能把“用户操作”和“视图响应”分开。

坐标转换是联动正确性的基础。时间轴 brush 的屏幕范围要转换成时间范围，热力图的矩形框要转换成数据空间范围，三维 picking 要从屏幕坐标生成 ray，再命中世界空间对象，最终得到数据 ID。每次转换都需要记录输入、输出和精度边界。例如三维流线 picking 如果基于离屏 ID buffer，输出是一个离散对象 ID；如果基于 CPU ray intersection，输出还可能包含世界空间命中点；如果基于近似 bounding volume，输出需要二次确认。

联动渲染也要区分视觉高亮和数据过滤。视觉高亮只改变颜色、透明度、描边或标签，通常不改变数据集合；数据过滤会改变后续统计、LOD 请求和 GPU buffer 内容。用户 hover 一条流线时，三个视图可以只做高亮；用户提交 brush 时，系统需要更新 selection model，并让热力图重算统计。把两者分开后，hover 的延迟可以低，提交操作的延迟可以通过 loading 告知。

多视图方案还要定义失配时的反馈。某个视图可能暂时没有对应数据，例如时间轴选中的时间范围在三维视图中尚未加载对应 tile；某个视图也可能因缩放级别太粗，无法显示全部细节。此时视图应该显示“部分结果”“等待加载”或“当前尺度下聚合显示”之类的状态，并保留 shared state。用户需要先看到联动状态的一致性；全部视图的完整重算可以在后续帧逐步完成。

128.5 评估用户体验与效率指标

交互效果评估要把主观体验落到可采集指标。流场界面的目标任务可以设为：找到某个时间段内速度异常区域，选出相关流线，并确认三维结构中的对应位置。围绕这个任务，指标可以分成四组：响应指标、正确性指标、操作成本指标和恢复指标。每组指标都对应一类工程证据。

响应指标关注从输入到反馈的时间。可记录 pointerdown 到选择框出现的延迟、pointermove 到 hover 高亮的延迟、brush 提交到第一份过滤结果出现的延迟、完整结果替换粗略结果的延迟，以及帧时间的 P50、P95 和 P99。P50 说明常规体验，P95 和 P99 暴露偶发卡顿。对于可视化工具，偶发卡顿会破坏 drag 和 zoom 的连续性，因此尾部延迟需要单独观察。

正确性指标关注用户是否得到可信结果。selection precision 可以统计用户选中的对象中有多少属于目标区域；selection recall 可以统计目标对象中有多少被选中；多视图一致性可以比较三个视图显示的 selected ID 是否来自同一 revision；读数误差可以比较用户从图中读取的数值与数据真实值的偏差。科学可视化的交互评估必须覆盖正确性，因为一个顺滑但误导用户的联动方案会放大分析错误。

操作成本指标关注用户完成任务需要多少动作。可记录 click path、拖动距离、缩放次数、重新选择次数、tooltip 等待次数、面板切换次数和总任务时间。selection friction 可以定义为用户从开始框选到得到满意选择之间的操作次数和修正次数。对于大规模数据，可再记录每次修正触发的 query 数量、tile 请求数量和 GPU upload 字节数，把用户成本和系统成本连接起来。

恢复指标关注失败后的回退能力。可记录错误提示后用户是否能重试成功、撤销一次操作需要多少时间、撤销后多视图是否回到同一 revision、异步请求失败后旧结果是否保留、loading 时间过长时用户是否能取消。恢复能力的本质是让用户可以探索高风险数据空间，而不把一次误选、一次超范围查询或一次网络失败变成分析中断。

下面的评估表把指标与采集位置对应起来。实际工程中可以用浏览器 Performance API、引擎内部 timestamp、GPU timer query、日志埋点和用户测试记录组合采集。

指标组	采集对象	判断问题	常见证据
响应	输入时间戳、frame timestamp、request token	操作到反馈是否连续	P50/P95/P99 latency、frame time
正确性	selected ID、真实标签、revision	选择和读数是否可信	precision、recall、读数误差
操作成本	command log、view focus、panel switch	完成任务需要多少动作	click path、修正次数、任务时间
系统成本	query 数、upload 字节、draw call	交互是否触发过多资源变更	tile 请求、buffer upload、pass 数
恢复	history revision、error code、retry result	失败后能否回到稳定状态	undo 时间、重试成功率、取消次数

评估流程应先固定任务，再采集指标。直接在开发环境里观察“感觉顺不顺”会遗漏交互语义错误。更稳的流程是：给定一个数据集和任务目标，记录用户从初始视图到最终选择的 command log；用日志复放 interaction state；检查每个 revision 下三个视图的 selected ID 是否一致；再分析延迟和资源成本。这样可以把体验问题拆成状态设计问题、事件调度问题、渲染成本问题或视觉编码问题。

评估也要覆盖不同数据规模。小数据集上 hover、brush 和 zoom 都可能表现良好；大数据集会暴露异步查询、tile cache、GPU memory 和 selection buffer 更新的压力。测试矩阵至少包含小规模即时结果、中规模渐进结果、大规模部分加载三类。每类都记录同一套指标，才能判断交互模型的伸缩性。

本章建立的交互判断顺序可以收束为五步：先定义 interaction state，再设计每个用户动作如何修改 state；随后为 hover、drag、selection、zoom、loading、error 和 undo 分配反馈阶段；再把事件频率、渲染频率和数据查询频率拆开；接着用 shared state 实现多视图联动；最后用延迟、正确性、操作成本、系统成本和恢复指标评估结果。这个顺序能把“交互是否好用”落到可调试的 frame、event、state、resource 和 view evidence 上。

最小自检任务

你正在实现一个三视图科学可视化界面：时间轴、二维热力图和三维流线视图共享同一份流场数据。用户在时间轴上拖动 brush 时，热力图要显示对应时间范围内的统计结果，三维视图要高亮命中的流线。当前实现把每次 pointermove 都直接触发完整数据过滤、GPU selection buffer 上传和三个视图重绘，结果是拖动时卡顿，并且偶尔出现热力图显示新时间范围、三维视图仍显示旧高亮的情况。

请设计一套修正方案，说明 interaction state 应包含哪些关键字段，pointermove、brush 提交、查询返回和 undo 分别如何更新 state，哪些反馈应该即时出现，哪些工作应该延后到提交或异步阶段，多视图如何保持同一 revision。

答案要点

interaction state 至少应包含 brushDraftRange、brushRange、selectedIds、pendingRequest、revision、sourceView、loading、errorCode、camera 和 history。pointermove 在拖动中只更新 brushDraftRange 和 overlay dirty flag，让选择框跟手；它不触发完整数据过滤和 selection buffer 上传。brush 提交时把 brushDraftRange 写入 brushRange，生成新的 pendingRequest 和 revision，进入 loading 状态，并启动过滤查询。查询返回时先检查 token 和 revision，只接受当前请求对应的结果，再更新 selectedIds、统计数据和 GPU selection buffer dirty flag。旧请求返回后可以写入缓存，但不能覆盖当前视图。

即时反馈应包括 brush 框、局部遮罩、loading 标记和上一份稳定结果。延后工作包括大规模数据过滤、tile 请求、GPU selection buffer 上传和多个视图的完整统计重算。多视图之间通过 shared interaction state 联动：时间轴、热力图和三维视图都订阅同一 revision，根据自己的坐标和资源路径渲染结果；视图响应 shared state 时不得直接调用其他视图，也不得把渲染反馈再次提交成新的用户意图。Undo 应从 history 中恢复上一组 brushRange、selectedIds、camera 和 revision，并让三个视图以同一 revision 重绘。

本章知识点总结

• 交互闭环：科学可视化交互应从输入事件追踪到状态变更、资源更新、渲染请求和可见反馈。
• 状态中心：interaction state 是 hover、selection、drag、zoom、loading、error 和 undo 的共同事实来源。
• 反馈分层：hover 和拖动中的 overlay 应优先跟手，数据查询和 GPU upload 可以在提交阶段执行。
• 延迟预算：0.1 秒、1 秒和 10 秒界限可用于规划即时反馈、可感知处理和长任务进度提示。
• Brush 语义：拖动中的 brushDraftRange 服务视觉跟手，提交后的 brushRange 服务数据过滤和多视图联动。
• 事件归一：pointer、keyboard 和 wheel 输入应先转换成 select、pan、zoom、cancel、submit、undo 等交互意图。
• 帧调度：事件频率、渲染频率和数据查询频率应拆开，通过 dirty flag 控制最小必要重绘。
• 请求版本：异步查询需要 token 和 revision，当前视图只接受匹配最新用户意图的结果。
• 联动中心：多视图协同应通过 shared interaction state 完成，各视图根据自身坐标和资源路径响应。
• 坐标转换：时间轴、热力图和三维视图联动时，应把屏幕输入转换成时间范围、数据空间范围或数据 ID。
• 高亮过滤：视觉高亮通常只改变编码，数据过滤会改变统计、LOD 请求和 GPU buffer 内容。
• 体验评估：交互质量应同时观察响应延迟、选择正确性、操作成本、系统成本和恢复能力。
• 复放验证：command log 和 revision 可以复盘用户操作，帮助定位状态设计、调度和渲染资源问题。