统940和高等 待时间子系统950。可以针对低等待时间子系统940和高等待时间子系统950以不同速率 生成事件，因为低等待时间子系统能够比高等待时间子系统更快地处理事件，以高速率向 高等待时间子系统发送事件可能会淹没该子系统。因此，低和高等待时间子系统的对用户 输入的响应是独立的，但是，是协调的。在一个实施例中，一个子系统充当"主控"，设置其他 子系统在用户输入之间的状态。在一个实施例中，低和高等待时间子系统之间的关系包括 两个子系统之间的同步。在一个实施例中，低和高等待时间子系统之间的关系包括高等待 时间子系统向低等待时间子系统940分摊处理的能力。在一个实施例中，低和高等待时间 子系统之间的关系包括低等待时间子系统940的降低其处理负载和/或使用高等待时间子 系统950来进行预处理或预先渲染的能力。在一个实施例中，第二图形处理和输出系统的 响应取决于第一图形处理和输出系统，并且状态信息被从第一图形处理和输出系统传递到 第二图形处理和输出系统。在这样的实施例中，从第一图形处理和输出系统传递到第二图 形处理和输出系统的信息包括描述用户接口中的图形元素中的一个或多个的一个或多个 数据片。此数据可以是，例如，用户接口中的图形元素的大小、位置、外观、替代的外观、对用 户输入的响应，以及类型。从第一图形处理和输出系统传递到第二图形处理和输出系统的 数据可以被存储在对第二图形处理和输出系统可用的高速存储器中。传递的数据可以描述 按钮、滑块、可拖拽和/或可调整大小的GUI元素、可滚动列表、旋转器、下拉列表、菜单、工 具栏、组合框、可移动图标、固定图标、树视图、网格视图、滚动条、可滚动窗口，或用户接口 元素的外观和/或行为。
[0061] 在一个实施例中，输入处理系统在用户输入信号由第一或第二图形处理和输出系 统中的一个或两者接收到之前对用户输入信号执行抽取（decimation)。基于有关从第一图 形处理和输出系统发送的用户接口的信息，从所有输入信号的组中选择抽取的输入信号或 非抽取的信号。可以通过将输入信号组逻辑地组合到较小的输入信号组，执行输入信号的 抽取。输入信号的逻辑组合可以通过取窗平均（windowed averaging)来执行。当缩小输 入信号组的大小时，抽取考虑用户输入信号的时间。输入信号的逻辑组合可以通过加权平 均来执行。在一个实施例中，由第一和第二图形处理和输出系统接收到的用户输入信号被 差分地处理。
[0062] 在一个实施例中，高等待时间和低等待时间层之间的通信是重要的。下面将描述 在确定高和低等待时间子系统如何保持同步时考虑的某些点： ?等待时间差异：低等待时间响应可以使用有关高和低等待时间层之间的等待时间差 异的信息来使响应同步。在一个实施例中，这些等待时间值是静态的，如此，被预编程到 FPGA中。在等待时间水平可能在任一子系统中变化的实施例中，将等待时间水平固定在始 终能实现的常数，而非具有可能会变得不同步的动态值，或者提供显式同步机制可能是有 利的。在等待时间水平可能在任一子系统中变化的实施例中，可以使用动态值，然而，应该 小心避免变得不同步。在等待时间水平可能在任一子系统中变化的实施例中，可以在子系 统940,950之间提供显式的同步机制。 ?命中测试：命中测试决定常常取决于关于可见UI元素的视觉层次结构和属性的数 据。在实施例中，可以通过禁止重叠包围矩形，要求n的平坦"命中测试友好"图，来解决 此考虑。在一个实施例中，单独的命中测试可以向低等待时间子系统提供必要的信息（对 象状态、Z轴顺序，以及听者）。在一个实施例中，低和高等待时间子系统两者可以并行地进 行命中测试。在一个实施例中，低等待时间子系统进行命中测试，并向高等待时间子系统提 供结果。 ?有条件的响应：许多接口视觉化不仅取决于即时用户输入，而且还进一步取决于应用 逻辑中定义的决策逻辑。
[0063] 条件响应逻辑的两个说明性示例如下：考虑信用卡购买提交按钮，该按钮被编程 为当被按下时禁用（以防止双重记账），但是只在验证被输入到表单中的数据时。在这样的 情况下，按钮的行为不仅依赖于即时用户交互，而且还取决于额外的信息和处理。还考虑链 接的视觉化，诸如图10所示出的那一个。在此情况下，反馈不仅通过用户正在操纵1010的 n元素，而且还通过第二n元素1020被提供到用户。这些示例可以被直接编程到低等待 时间子系统中。
[0064] 在一个实施例中，高和低等待时间子系统之间的分割可以独立于任何用户接口元 素。实际上，子系统之间的责任分摊可以基于任意数量的因素来定制，并且在缺乏用户接口 工具箱的系统中，或实际上在包括使用和不使用可能可用的UI工具箱来开发应用程序的 机制的系统中将仍是可能的。在一个实施例中，两个子系统之间的责任分摊可以在子系统 正在运行时被动态地改变。在一个实施例中，n工具箱本身可以被包括在低等待时间子系 统内。在不偏离此处所描述的系统和方法的情况下，可以以许多方式向应用程序开发人员 提供定制响应的能力。在一个实施例中，响应可以被定制为在n控件中调整的参数。在一 个实施例中，可以通过在本身在低等待时间子系统中执行的代码中或在另一种高或低等待 时间组件中允许直接向低等待时间子系统提供指令的能力来定制响应。在一个实施例中， 可以使用由应用程序代码所生成的数据例如在运行时设置低等待时间子系统的状态。
[0065] 尽管上文所描述的许多示例是在触摸输入的上下文中所提供的，但是，其他实施 例也是可以的，包括，但不仅限于，笔输入、鼠标输入、间接触摸输入（例如，跟踪板）、空中 姿势输入、口头输入和/或其他输入模态。所描述的体系结构将同样地适用于任何种类的 用户输入事件，包括但不仅限于混合的输入事件（即，支持来自一个以上的模态的输入）。 在一个实施例中，混合的输入设备可以导致相同数量的事件被生成，来供由低和高等待时 间子系统中的每一个处理。在一个实施例中，混合的输入设备将在生成的事件的数量上被 区分，如此，例如，触摸输入可能比笔输入具有较少的事件。在一个实施例中，每一输入模态 都包括其自己的低等待时间子系统。在实施例中，在包括多个用于多个输入模态的低等待 时间子系统的系统中，子系统可以进行通信，以协调它们的响应。在实施例中，在包括用于 多个输入模态的多个低等待时间子系统的系统中，多个子系统可以共享公用存储器区域， 以实现协调。 输入处理
[0066] 在本发明的实施例中，来自输入硬件的低等待时间输入数据被最低限度地处理为 快速的输入事件的流。此事件的流被直接发送到低等待时间子系统，用于进一步处理。然 后，在被发送到高等待时间子系统之前，可以删除来自此同一流的事件，或可以以别的方式 缩小或过滤该流。可以针对低等待时间子系统940和高等待时间子系统950以不同速率生 成事件，因为低等待时间子系统能够比高等待时间子系统更快地处理事件，以高速率向高 等待时间子系统发送事件可能会淹没该子系统。因此，低和高等待时间子系统的对用户输 入的响应可以独立的，但是，是协调的。
[0067] 可以对事件的减少进行最优化。在一个实施例中，可以基于与应用程序、UI元素、 输入设备等等中的一项或多项相关联的准则，从候选事件选择代表性事件。当用户正在绘 制数字墨水笔画时笔输入的此情况的示例可包括选择最适合用户的绘制的笔画的事件。对 于语音输入的另一个示例是偏好其中输出流中的随后的事件将具有类似的音量，由此，使 来自麦克风的声音"平滑"的事件。触摸输入的另一个示例是偏好将导致具有一致的速度， 从而提供比较"平稳"输出的输出事件流的事件。这种智能减少的形式充当智能过滤器，而 不会降低高等待时间子系统的性能。在一个实施例中，可以生成表示输入流中的其他事件 的聚集的新事件（例如，合并的事件或伪事件）。在一个实施例中，可以生成表示更加合乎 需要的输入流的新事件（例如，校正的时间、合并的事件或伪事件），例如，校正或平滑化。 例如，对于空中姿势输入，对于来自高速输入设备的每10个事件，可以给高等待时间子系 统发送相同数量或较少的事件，它们提供真实输入事件的"平均"，由此平滑化输入并移除 抖动。也可以生成是输入设备的各种参数的多个"所希望的"水平的混合物的新事件。例 如，如果触笔的倾斜和压力属性的智能减少将导致选择不同的事件，则可以创建单个新事 件对象（或修改一个或多个现有的事件对象），以包括这些属性中的每一个的所需值。
[0068] 在一个实施例中，或低等待时间子系统可以被用来给高等待时间系统提供经 过处理的输入信息。可以使用方法中的一个或多个来协调两个子系统的活动。这些包括： a.在一个实施例中，低等待时间子系统可以立即对所有用户输入作出响应，但是，在将 输入提供到高等待时间系统之前，等待用户停止输入（例如，抬起手指或笔，终止姿势）。这 具有在用户交互过程中避免阻塞系统同时仍处理全部数据的优点。 b.在一个实施例中，低等待时间系统可以几乎实时地提供输入的缩小的估计；并可以 任选地存储可以应请求对高等待时间系统可用的完整的输入队列。 C.在一个实施例中，用户反馈可以被分成两个步骤。第一低等待时间反馈将提供图11 中的用户输入1130的粗略即时表示。每当高等待时间系统能够计算细化的响应时，例如， 在笔1150尖被抬起之后，第二高等待时间系统响应1140可以替换第一 1130。可另选地，高 等待时间反馈可以连续地"追上"（并可能包含）低等待时间反馈。 d. 在实施例中，低等待时间系统可以从输入流推断简单姿势动作，由此生成包括在输 入队列中的姿势事件来作为原始事件的补充，或替换原始事件。 e. 在一个实施例中，IPU或低等待时间子系统可以使用多个输入位置来预测将来的输 入位置。此预测可以被传递到高等待时间子系统，以降低其有效等待时间。 f. 在一个实施例中，在IPU或低等待时间子系统中执行可以得益于附加样本或较早的 检测的算法。在一个实施例中，这些事件的执行会在时间方面受限制。例如，初始50个事 件可以被用来将输入分类为特定手指，或区分手指和笔输入。在一个实施例中，这些算法可 以连续地运行。 g. 在实施例中，低等待时间子系统将事件流传递到高等待时间子系统的过程可以被 延迟，以便接收和处理否则可能被不正确地视为不相关的输入的附加连续或同时的相关输 入。例如，字母"t"常常被绘制为两个单独的，但是相关的笔画。在正常的过程中，输入流 中从低等待时间系统传递到高等待时间系统的部分将在绘制第一线结束时包括"提笔（pen up) "信号。在实施例中，在窗口内在显示器上再次检测到笔的情形中，降低过程等待采样时 窗内的输入的最后帧，以传递"上（up) "事件，如此，消除对事件的需要。 硬件体系结构
[0069] 在一个实施例中，数据通过系统的组件流过两个重叠路径，以支持高和低等待时 间反馈两者。图12示出了一个这样的系统，该系统包括输入设备1210、IPU 1220、系统总 线1230、连接到显示器1290的CPU 1240和GPU 1280。用户1200使用输入设备1210来执 行输入。此输入由IPU 1220感应，在各实施例中，该IPU 1220可以是FPGA、ASIC，或集成 到GPU 1280、MPU或者SoC中的额外的软件和硬件逻辑。此时，控制流分为两支，并遵循通 过系统的两个单独的路径。对于对输入的低等待时间响应，1220通过系统总线1230将 输入事件发送到GPU 1280,绕过CPU 1240。然后，GPU 1280快速地向用户1200显示反馈。 对于对输入的高等待时间响应，1220通过系统总线1230将输入事件发送到CPU 1240， 该CPU 1240运行图形应用程序并可以与其他系统组件进行交互。然后，CPU 1240通过系 统总线1230将命令发送到GPU 1280,以便向用户1200提供图形反馈。从输入设备1210到 IPU 1220到系统总线1230到GPU 1280的低等待时间路径主要是硬件，并以低等待时间操 作。从输入设备1210到IPU 1220到系统总线1230到CPU 1240回到系统总线1230到GPU 1280的高等待时间路径，由于在此描述中前面所描述的因素，是高等待时间。在相关的实施 例中，输入设备1210直接与GPU 1280进行通信并绕过系统总线1230。
[0070] 图13示出了叫做"模型视图控制器"的熟悉的编程范例。在此范例中，用户1300 在控制器1310上执行输入，控制器1310又基于此输入，操纵模型1320。模型1320中的变 化导致由用户1300观察到的对视图1330的更改。由本发明解决的某些等待时间归因于输 入、这些组件之中的通信，以及由视图1330组件所生成的图形的显示中的等待时间。
[0071] 图14示出了支持利用混合的对用户输入的高和低等待时间响应来在系统上开 发和运行应用程序的体系结构的实施例。用户1400利用输入设备1410执行输入。此输 入由IPU 1420接收。IPU 1420通过传统的机制同时将输入事件发送到在高等待时间子 系统中运行的控制器1430,以及在低等待时间子系统中运行的ViewModel (视图模型） (L) 1490。输入由控制器1430处理，控制器1430操纵在高等待时间子系统中运行的模型 1440,模型1440可以与易失性存储器1450、固定存储器1470、网络资源1460等等中的数 据进行交互（引入迟延的所有交互）。由Vi ewM〇del(L) 1490接收到的输入事件导致对 ViewModel(L)的更改，这些更改被反映在对被用户1400看见的View(L)1491的更改中。 对模型1440的更改导致对也被用户1400看见的高等待时间子系统的View(H) 1480的更 改。在一个实施例中，在相同显示器上示出了由用户看见这两种类型的变化。在一个实施 例中，这两种类型的变化通过其他输出模态（诸如，例如，声音或振动）被反映到用户。在 一个实施例中，在输入之间，模型1440更新ViewModel (L) 1490和View (L) 1491的状态，以 便ViewModel (L) 1490包含用于在系统的显示器上的正确的位置呈现⑶I的组件的所需的 数据，以便ViewModel (L) 1490可以在模型1440的上下文中正确地解释来自IPU1420的输 入；以便View(L) 1491可以在模型1440的当前状态的上下文中正确地生成图形供显示。
[0072] 作为示例，考虑带有按钮的触敏应用程序，在其功能当中，该按钮通过改变指出它 已经被激活的其外观，对用户的触摸作出响应。当应用程序运行时，应用程序从存储器和编 译的应用程序代码读取按钮的位置、大小，以及外观的细节。View(H) 1480代码生成呈现给 用户以显示此按钮的必要的图形。模型1440更新ViewModel (L) 1490的状态以记录此图形 元素是按钮，当被触摸时，它应该将外观从"正常的"外观改变为"被按下"外观。模型1440 还更新View(视图）（L) 1491的状态，以在ViewModel (L) 1490中记录"正常的"以及"被按 下"状态的正确的外观。此外观可以是低保真度图形元素，或要显示的完整光栅的描述。在 此示例中，"被按下"状态通过在按钮的位置周围显示白框来表示。
[0073] 用户对触摸屏显示器进行触摸，由IPU 1420在小于1毫秒以后接收描述该触摸 的输入数据。IPU 1420从输入数据创建表示触摸事件的输入事件，并将此输入事件发送 到应用程序控制器1430。控制器1430操纵模型1440。在此情况下，控制器1430向模型 1440指示，按钮被触摸，以及应用程序应该执行与此按钮相关联的任何命令。在IPU 1420 将事件发送到控制器1430的同时，它将事件发送到ViewModel (L) 1490,指示按钮已经被触 摸。ViewModel (L) 1490预先由模型1440指示在触摸的情况下做什么，并且在此情况下， 它通过将其状态改变为"被按下"对触摸事件作出响应。View(L) 1491通过在按钮周围显 示白框，对应于其"被按下"外观的反馈，对此变化作出响应。对模型1440的更改（按钮 被触摸）导致View (H) 1480的更新，以便它也反映按钮现在被触摸。看见View (H) 1480和 View(L)1491的用户通过View(L)1491看见他们的触摸的即时反馈，几分之一秒以后，跟着 来自View⑶1480的反馈。
[0074] 在本申请的文本中，使用单词"事件"来描述说明用户输入的属性的信息。此术语 一般性地使用，如此，包括其中使用事件驱动的体系结构的各实施例（实际事件对象在软 件元件之间传递），以及其中被描述的"事件"简单地存在于信息的流中的更多基本输入流。 这样的事件可以是，例如，非面向对象类型的事件或面向对象的类型的事件。
[0075] 参考方法和包括能够接收并对用户输入作出响应的计算机系统的设备的框图和 操作说明描述了当前系统和方法。应该理解，框图或操作说明中的每一个框，以及框图或操 作说明中的方框的组合，可以通过模拟或数字硬件和计算机程序指令来实现。这些计算机 程序指令可以被提供到通用计算机、专用计算机、ASIC，或其他可编程数据处理设备的处理 器，以便通过计算机或其他可编程数据处理设备的处理器执行的指令实现在框图或操作框 所指定的功能/动作。在某些替代实现中，在框中所指出的功能/动作可以不按照操作说 明中所说明的顺序发生。例如，取决于所涉及的功能/动作，连续示出的两个框实际上可以 基本上同时执行，或者这些框有时可以按相反的次序来执行。
[0076] 虽然是参考其优选实施例示出和描述本发明的，但是，那些精通本技术的人员将 理解，在不偏离本发明的精神和范围的情况下，可以对形式和细节进行各种修改。
【主权项】
1. 一种用于处理用户输入的系统，包括： 包括用户接口的视觉化的显示器； 包括从由接触输入和笔输入构成的组中选择的至少一个的用户输入设备，所述用户输 入设备适于输出对应于用户输入的信号； 操作地连接到所述用户输入设备的输入处理系统，所述输入处理系统适于接收对应于 用户输入的所述信号以及发出对应于所述接收到的信号的信号； 包括在软件堆栈中运行的软件的第一图形处理和输出系统，所述第一图形处理和输出 系统适于接收至少某些所述发出的信号以及响应于所述至少某些所述发出的信号，生成会 影响所述显示器上的所述用户接口的所述视觉化的高等待时间数据并输出所述高等待时 间数据以供所述显示器使用； 至少部分地以硬件实现的第二图形处理和输出系统，所述第二图形处理和输出系统 适于基本上同时接收所述至少某些所述发出的信号，并响应于所述至少某些所述发出的信 号，生成会影响所述显示器上的所述用户接口的所述视觉化的低等待时间数据，并输出所 述生成的低等待时间数据以供所述显示器使用； 其中，关于对所述至少某些所述发出的信号的所述响应，所述第二图形处理和输出系 统适于相对于由所述第一图形处理和输出系统的所述高等待时间数据的所述输出，在低等 待时间下输出所述生成的低等待时间数据；以及 所述显示器被配置成在所述用户接口的所述视觉化时显示至少某些所述低等待时间 数据和至少某些所述高等待时间数据。2. 如权利要求1所述的用于处理用户输入的系统，其特征在于，通过将对应于所定义 的响应的数据与所述至少某些所述发出的信号中的一个或多个相关联，来生成所述低等待 时间数据。3. 如权利要求1所述的用于处理用户输入的系统，其特征在于，通过渲染对与所述至 少某些所述发出的信号中的一个或多