java - JTree 项中的 setPreferredSize 为零会导致渲染性能不佳

Question

我已经使用 View 过滤方法成功过滤了一个 JTree(在树渲染中，将首选组件大小设置为 0 以过滤掉项目)。请参阅 [ Filtering on a JTree

我有一个包含超过 100 万个树项的扩展环境。

问题是当一些树item被过滤掉时，性能会下降很多(伸展树(Splay Tree)，滚动很慢)。

我的代码如下:

public static class TreeRenderer extends DefaultTreeCellRenderer
{
    @Override
    public Component getTreeCellRendererComponent( final JTree tree, final Object value, final boolean selected,
                                                    final boolean expanded, final boolean leaf, final int row, final boolean hasFocus )
    {
        // Invoke default Implementation, setting all values of this
        super.getTreeCellRendererComponent( tree, value, selected, expanded, leaf, row, hasFocus );

        if( !isNodeVisible( (DefaultMutableTreeNode)value ) )
        {
            setPreferredSize( new Dimension( 0, 0 ) );
        }
        else
        {
            setPreferredSize( new Dimension( 200, 15 ) );
        }

        return this;
    }
}

public static boolean isNodeVisible( final DefaultMutableTreeNode value )
{
    // In this example all Nodes without a UserObject are invisible
    return value.getUserObject() != null;
}

如果我将 setPreferredSize(new Dimension(0,0)) 的值(宽度、高度)更改为 0 以外的值，性能会恢复正常。

在 Jtree 中设置大小为零的组件有何意义？我错过了什么？有什么方法可以让我仍然使用 View 方法来解决这个问题？

谢谢

Answer 1

这很有趣。不幸的是，我无法提供解决方案，但至少认为找到了性能下降的原因。

我开始调查这个，由像 JTree#setRowHeight(int) 这样的方法注释引起的直觉引导。 .特别是，我寻找高度为 0 可能具有相似的特殊含义并导致不需要的计算的地方。

我发现我认为是性能问题的真正原因。这导致了一些通常不关心的(非公共(public))类，但最终，性能问题似乎是由 javax.swing.tree.VariableHeightLayoutCache.TreeStateNode#hasValidSize() 引起的。方法:

/*
 * Returns true if this node has a valid size.
 */
public boolean hasValidSize() {
    return (preferredHeight != 0);
}

此方法用于决定是否必须更新某些组件状态。当首选大小为 0 时，此方法“验证”节点状态 - 再次导致首选高度为 0，这被视为“无效”。这会导致多次重复更新，每次更新都涉及调用单元格渲染器的getTreeCellRendererComponent 方法，因此对于具有 100 万个节点的树，该方法将被调用数百万次(相比之下当首选高度不 0 时总共调用几千次)。

---

抱歉，我知道，这对您帮助不大。相应的类不是公共(public)的，创建自己的实现将意味着构建一些相当大的基础设施(可能有自己的布局缓存和自己的 Tree UI...)。

我不确定基于模型的过滤对你来说是否是一个可行的选择 - 特别是因为我知道这也不是微不足道的，除非创建一个全新的树模型，它在在处理数百万个节点时，turn 可能不是最好的主意......

---

但是，也许这种洞察力可以帮助其他人找到解决方案。任何为此(或 view-based filtering on JTrees in general)找到好的解决方案的人都会收到我的 +1(也许还有一些赏金)。这里的“好”解决方案意味着它不应涉及任何黑客攻击。特别是，上述问题的当前解决方案是“hack”，因为它们会导致不良行为(例如，使用键盘在树中导航时仍会遍历隐藏节点)。