拜尔说，他演讲的主题是表演。 他告诫说，与大多数与性能相关的事情一样，请避免性能预先优化。 他有一个黄色的大警告屏幕，上面写着“写清楚的代码，然后再显示个人资料！”。 他说，他的演讲基于JavaFX 2.2，其中一些技巧可能不适用于JavaFX 8。
Bair为Windows，Linux和Mac OS X这三种不同的操作系统（未指定版本）上的几种浏览器提供了“ GUIMark 2 Vector”基准测试。Bair将JavaFX与这些浏览器的本机支持进行了比较。 他还指出，有时SceneGraph更快，有时Canvas更快。 Bair提出的许多观点在较小的设备上比在台式机上更为重要。
JavaFX比GUIMark 2位图中的浏览器快得多，而JavaFX Canvas是所有浏览器中最快的。 由于速度有限，GUIMark 2 Text测试无法为Windows提供有用的数据，但是JavaFX在Linux和Mac OS X上表现出色。Bair打算发布基准测试方法以供公众使用，他展示了一个图表，该图表表明从JavaFX 2.2到2007年的显着性能改进。 JavaFX 8。
拜尔的绩效准则＃1是“少做点工作”。 Bair说：“更小的系统需要更激烈的性能调整。” 他补充说，“每行计数”和“额外的方法调用加起来”。 尽管在传统的桌面Java中，我们已经学会了不要担心方法调用的数量，但这在较小的设备上可能是个问题（“过多的内联非常昂贵”，而“过多的方法调用很昂贵”）。 Bair展示了如何使用局部final变量来减少方法调用的次数。 他承认这是台式机上的“绝对微性能预优化”，但对于较小的设备来说是一种有用的策略。
Bair说，“填充率”是“几乎100％确定性”的限制。 除非您有“成千上万的顶点”，否则几何率不太可能成为JavaFX中的重要限制。 CSS开销和布局计算一样都是可能的限制。 JavaFX进行了大量的缓存，而后者可能并不总是一个问题。 系统I / O很有可能会限制您，特别是在较小的设备上。
拜尔（Bair）展示了一个“滥用填充率”的示例，该方法首先绘制最远的背景，然后用另一填充绘制大部分。 他有一些避免这种不必要填充的观点，例如“只画变化了”。 Bair指出开发人员会在Swing中识别“脏区”，但是JavaFX SceneGraph会“自动执行此操作！” 他确实警告JavaFX Canvas要求开发人员识别“脏区”。
提高填充率的另一种方法是“限制使用（某些）效果”。 “效果在您的台式机系统上几乎是免费的，”但可能需要在较小的设备上更仔细地观察。 拜尔讨论了一项子弹，指出“限制使用非矩形，无轴对齐的夹子”是提高填充率的另一种策略。 直接剪切对齐的图像很快，但是抗锯齿，渲染为背景图像以及旋转未对齐的像素边界的过程会“花费更多”（但在大多数桌面应用程序中您不会注意到）。
Bair表示，减少透支是提高填充率的有效方法。 与减少透支有关，他讨论了使用“图像蒙皮”的问题。 Bair在这里还提到JavaFX 8包括自动区域纹理缓存。 减少透支的其他想法包括简化样式（Metro，Android），合并背景填充以及减少重叠节点的数量。
Bair表示，Microsoft故意在Metro中提出了易于绘制的样式。 同样，Android样式更快，更容易绘制。
“ 遮挡剔除”可以避免绘制（剔除）不可见的东西。” 这样做可以使我们“减少过度绘制并提高渲染性能”。 JavaFX引擎可以响应JavaFX CSS不透明的插图，以了解何时不重绘这些区域。
有一些CSS成本需要注意，例如解析样式表。 贝尔（Bair）展示了一个带有.parent:hover .child {...}的“ CSS Horror Show”幻灯片，并解释了为什么如此恐怖：每次将父项悬停时，都必须重新审视所有子项。 同样，如果有大量.parent .child {...} ， .parent .child {...}可能会很糟糕，因为“当我们遇到一个带有.child样式类的节点时，我们必须沿着整个场景图走动直到找到它。” 最好将搜索限制为直接父级。
Bair指出，setStyle CSS属性非常方便，但代价可能很高。 解析和其他支持会增加性能问题。 CSS提供了功能，灵活性和便利性，但这确实是以性能为代价的。
Bair的技巧之一是“避免对SceneGraph进行结构更改”。 从变更点开始的所有CSS必须重新计算。 除了重新应用CSS外，更改SceneGraph时还需要“结构完整性检查”。 JavaFX已经优化了toFront / toBack，因此请使用它们而不是删除并添加回来。
另一个Bair技巧是“使用FXCollections”。 他对此的第一句话说：“争取最小的通知开销。” 建议使用setAll而不是clear和addAll的子项目符号。 添加了另一个子项目，“避免多次添加呼叫”。
最好使用FXColections.sort（），因为它“发送”排列”更改事件。 这意味着JavaFX引擎知道更改了什么，因此仅重新计算该特定类型更改所需的内容。 这些“排列”由“单独的快速路径处理”。
Bair表示“ ListView快速起泡”，因为它“重用节点”并保持最小的更改。 Bair总结说，该幻灯片带有“重用ListView来满足您所有的虚拟化需求！”
Bair的“手动布局”技巧包括了Region的自定义扩展的想法。 他警告说，扩展Region时，几乎总是需要实现computePrefWidth和computePrefHeight 。
Bair有一张幻灯片列出了处理布局时“ JavaFX会问”的问题。 这些问题是“您想要多大/多高？” 和“您可以调整大小吗？” 当尝试渲染布局时，JavaFX至少会问这些问题一次，有时甚至是问更多次。 定制的布局可以减少尝试的次数和提出的问题的数量。 “ JavaFX提出了很多问题”，并且“在布局期间每个节点都被问到了”。
拜尔有一个“重要提示！” 与“内容偏差”相关。 如果高度取决于宽度，则表示水平偏差。 如果宽度取决于高度，则表示您有偏见。 Bair表示“（（contentBias = null）到目前为止是最快的”（所有计算出的高度和宽度首选项都将被缓存）。 内容偏差通常为null或水平。 内在错误是“内置布局实际上未很好地支持contentBias！= null”。
到目前为止，所有内容均已符合Bair的第一条规则（减少工作量）。 规则2现在为“了解您的设备”。 Bair展示了一张幻灯片，其中将功能强大的NVidia GForce GTX 690与功能较弱的NVidia GForce 310甚至更低的PowerVR SGX543MP3进行了比较。 Bair的观点当然是，“ JavaFX为您提供了一个开发平台和一套API，但是您可以使用和不能使用哪些API将取决于设备的固有性能特征。”
Bair对设备上的JavaFX有一些经验法则。 使用桌面应用程序处理2万到10万个节点。 500到1000个节点是嵌入式的最佳范围。 对于非常小的嵌入式设备，对于JavaFX应用程序，坚持使用100到200个节点。
Bair提供了另一个与缓存有关的技巧。 他谈到要缓存图表，因为然后将其仅绘制到图像一次，然后可以快速绘制到屏幕“数十亿次”。 但是，Bair警告说，“如果节点发生很大变化，则会适得其反”。 拜尔说，他经常将缓存设置为true，制作动画，然后再次将缓存设置为false。
旋转和缩放时可以将CacheHint设置为SPEED，以获得更好的性能。 如果您希望它在旋转时能重绘以提高准确性，则可以使用除SPEED之外的其他缓存提示。
JavaFX 8具有Pulse Logger（ -Djavafx.pulseLogger=true系统属性），可以“打印出很多有关JavaFX引擎执行的废话”（很好的方式）。 在每个脉冲的基础上有很多提供的信息，包括脉冲数（自动递增的整数），脉冲持续时间以及自最后一个脉冲以来的时间。 该信息还包括线程详细信息和事件详细信息。 此数据使开发人员可以查看大部分时间。
Bair用相同的鲜黄色警告幻灯片结束了会议：编写干净代码，然后分析！ 幻灯片还指出，“不要过度操作，否则您将陷入无法维护的困境。
参考： JavaOne 2012：来自JCG合作伙伴 Dustin Marx的JavaFX图形技巧和窍门，内容来自Inspired by Actual Events博客。
翻译自: https://www.javacodegeeks.com/2012/10/javaone-2012-javafx-graphics-tips-and.html
