有什么交易网站源码,企业网站制作模板,平面设计手机作图软件,西安公司地址javaone我回到希尔顿#xff08;皇家宴会厅B#xff09;看了Richard Bair的#xff08;Oracle Java Client Architect#xff09;的“ JavaFX图形技巧和窍门”。 Bair与FX Experience相关联#xff0c;并且显然了解JavaFX。 拜尔说#xff0c;他演讲的主题是表演。 他告诫… javaone 我回到希尔顿皇家宴会厅B看了Richard Bair的Oracle Java Client Architect的“ JavaFX图形技巧和窍门”。 Bair与FX Experience相关联并且显然了解JavaFX。 拜尔说他演讲的主题是表演。 他告诫说与大多数与性能相关的事情一样请避免性能预先优化。 他有一个黄色的大警告屏幕上面写着“写清楚的代码然后再配置文件”。 他说他的演讲基于JavaFX 2.2其中一些技巧可能不适用于JavaFX 8。 Bair为WindowsLinux和Mac OS X这三种不同的操作系统未指定版本上的几种浏览器提供了“ GUIMark 2 Vector”基准测试。Bair将JavaFX与这些浏览器的本机支持进行了比较。 他还指出有时SceneGraph更快有时Canvas更快。 Bair提出的许多观点在较小的设备上比在台式机上更为重要。 JavaFX比GUIMark 2 Bitmap中的浏览器快得多而JavaFX Canvas是所有浏览器中最快的。 由于速度有限GUIMark 2 Text测试无法为Windows提供有用的数据但是JavaFX在Linux和Mac OS X上表现出色。Bair打算发布基准测试方法以供公众使用他展示了一个图表该图表表明从JavaFX 2.2到2000 JavaFX 8。 Bair的绩效准则1是“少做点工作”。 Bair说“更小的系统需要更激烈的性能调整。” 他补充说“每行计数”和“额外的方法调用加起来”。 尽管在传统的桌面Java中我们已经学会了不要担心方法调用的数量但这在较小的设备上可能是个问题“过多的内联非常昂贵”而“过多的方法调用很昂贵”。 Bair展示了如何使用局部final变量来减少方法调用的次数。 他承认这是台式机上的“绝对微性能预优化”但对于较小的设备来说是一种有用的策略。 Bair说“填充率”是“几乎100确定性”的限制。 除非您有“成千上万的顶点”否则几何率不可能是JavaFX中的重要限制。 CSS开销和布局计算一样都是可能的限制。 JavaFX进行了大量的缓存而后者可能并不总是一个问题。 系统I / O很有可能会限制您特别是在较小的设备上。 拜尔Bair展示了一个“滥用填充率”的示例该方法首先绘制最远的背景然后用另一填充绘制大部分。 他有一些避免这种不必要填充的观点例如“只画改变的东西”。 Bair指出开发人员会在Swing中识别“脏区”但是JavaFX SceneGraph会“自动做到这一点” 他确实提醒JavaFX Canvas要求开发人员识别“脏区”。 提高填充率的另一种方法是“限制使用某些效果”。 “效果在您的台式机系统上几乎是免费的”但可能需要在较小的设备上更仔细地观察。 拜尔Bair讨论了一项子弹指出“限制使用非矩形非轴对齐的夹子”是提高填充率的另一种策略。 直接剪切对齐的图像很快但是抗锯齿渲染为背景图像以及旋转未对齐的像素边界的过程会“花费更多”但在大多数桌面应用程序中您不会注意到。 Bair表示减少透支是提高填充率的有效方法。 与减少透支有关他讨论了使用“图像蒙皮”的问题。 Bair在这里还提到JavaFX 8包括自动区域纹理缓存。 减少透支的其他想法包括简化样式MetroAndroid合并背景填充以及减少重叠节点的数量。 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.pulseLoggertrue系统属性可以“打印出很多有关JavaFX引擎执行的废话”。 在每个脉冲的基础上有很多提供的信息包括脉冲数自动递增的整数脉冲持续时间和自最后一个脉冲以来的时间。 该信息还包括线程详细信息和事件详细信息。 这些数据使开发人员可以查看大部分时间。 Bair用相同的鲜黄色警告幻灯片结束了会议编写干净代码然后分析 幻灯片还指出“不要过度操作否则您将陷入无法维系的困境。 参考 JavaOne 2012来自JCG合作伙伴 Dustin Marx的JavaFX图形技巧和窍门来自Inspired by Actual Events博客。 翻译自: https://www.javacodegeeks.com/2012/10/javaone-2012-javafx-graphics-tips-and.htmljavaone
