Typeter是一种测量和分析文本/代码编辑器的视觉延迟的工具。
编辑器等待时间是输入事件和相应屏幕更新之间的延迟，特别是击键和字符外观之间的延迟。虽然存在多种延迟(插入符号移动、行编辑等)，但输入延迟是编辑器可用性的主要预测因素。
请阅读我的文章“打字”，了解更多关于编辑器延迟及其对打字性能的影响。
运行该程序需要Java 8或更高版本。您可以从官方网站下载Java。
该程序生成操作系统输入事件(按键)，并使用屏幕截图来完全自动化测试过程。
首先，在编辑器窗口中插入预定义的图案(“.”)，以便检测屏幕度量(开始位置、步长、背景等)。
在此之后，程序会键入预定义数量的“。将字符输入编辑器(以给定的周期)，测量按键和相应字符绘图之间的延迟。
为了实现高精度的测量，每个符号仅查询单个像素。此外，该程序可以在支持的平台上使用快速原生API(WinAPI、XLib)调用，提供AWT机械手作为后备选项。
同步-程序总是等待键入的字符出现，然后暂停并键入下一个字符。这是最准确的方法(因为没有线程开销)。
异步-程序独立键入和识别字符。此方法的精确度稍低，但对于测试快速键入非常有用，因为编辑器绘制可能很容易落后于多个字符。
若要仅注册必要的编辑器延迟，必须将文本直接渲染到帧缓冲区，而不进行可能导致额外延迟的中间图像处理。出于测试目的，更喜欢堆叠窗口管理器而不是合成窗口管理器，尤其是：
在Windows中切换到经典主题。Windows Aero强制内部垂直同步，从而实现最小的1帧延迟(60 Hz监视器刷新率约为17毫秒)和延迟离散化。也可以在Windows7和Windows8中直接禁用合成功能。
使用带有轻量级窗口管理器的Linux分发版，如Lubuntu(Openbox)。复杂的、基于3D的窗口管理器可能会大大增加系统渲染延迟，例如，在我的硬件上，Ubuntu的Compiz增加了大约10毫秒的不可避免的延迟。
关闭所有添加系统范围键盘挂钩的程序，因为它们可能会同步处理键盘事件并影响结果(例如，众所周知Workrave会显著增加键入延迟)。
您可以考虑将机器切换到特定的硬件模式(电源方案、集成/独立显卡等)。例如，在省电模式下(使用电池)，编辑器的响应性通常要低得多，因此有可能检测到在其他情况下不太容易观察到的重大性能故障。
在开始基准测试之前，请确保其他应用程序没有给您的系统带来明显的负载。您可以自行决定是否“预热”基于VM的编辑器，以便它们可以在继续之前预编译其代码的性能关键部分。
如果可能，在编辑器中启用非块插入符号(即下划线/竖线而不是矩形)。这可能会提高测量精度。
指定度量标题，如“Vim中的HTML”(可选，可以稍后设置)。
将编辑器插入符号放在所需的上下文中(如注释等)，放在短行/空行的末尾。
只需将焦点移回程序窗口，即可随时中断测试过程。
获得测试结果后，您可以单独分析单个数据，也可以进行额外的测试(不同的编辑器/条件)进行对比分析。
可以通过从现有CSV文件插入数据或通过在保存时将数据附加到CSV文件来合并结果。
以下是有关如何使用该工具检测文本/代码编辑器中的性能瓶颈的一些提示：
检查线路数量是否影响延迟。如果是这样的话，在一个大文件中输入可能会“滞后”。
检查编辑器窗口大小是否影响延迟。如果是这样，编辑器可能会过度重绘，而不是只绘制新插入的符号。
尝试启用突出显示/自动完成/折叠/拼写检查等。这些功能应该异步处理，而不会影响输入。
尝试在省电模式下运行测试。理想情况下，即使在功能较弱的硬件上，也应该很好地处理打字。
如果您正在实现文本/代码编辑器，请看一下显著减少绘制延迟的编程技术。
要实现基准测试，必须在初始步骤检测到正确的屏幕指标。程序尝试识别自定义图案(5个新点)，以确定以下参数：
因为有许多编辑器(以及每个编辑器的多个版本)，在不同的平台上看起来不同，并且有许多可能的配色方案和字体，所以度量识别算法必须非常灵活。虽然程序源代码包含大量测试用例，但仍有可能出现一些故障。
编辑器有一个与文本区域融合的左侧面板-隐藏面板。
您可以通过创建额外的测试用例图像(查看/src/test/resources目录中的示例)进行贡献。
快乐打字--打字延迟的人机方面，关于流行文本/代码编辑器延迟的实验数据。
深入分析了AWT/Swing架构中的低延迟绘制和Swing延迟来源，提出了显著降低绘制延迟的方法。