1

我在 Telerik WPF 分层网格视图中遇到了一点性能问题，并考虑了替代的第 3 方控件。

看看这个简单的场景（zip 项目） 它是一个 RadTreeListView，绑定到一个带有组合框的实体以扩展到每个级别。表演很垃圾。我正在使用轻量级 Metro (windows8) 样式，并按如下方式覆盖了 CreateCellElement（并按照推荐方式）。

public override FrameworkElement CreateCellElement(GridViewCell cell, object dataItem)
{
    if (cell.Content != null && cell.DataContext == dataItem)
    {
        return (FrameworkElement)cell.Content;
    }

    return base.CreateCellElement(cell, dataItem);
}

打开它，拖动以填充屏幕的高度，将所有项目展开几级深度（使用左上角的组合）并滚动 - 它非常滞后。在我的工作版本中，类似的场景完全无法使用，我目前被迫遍历所有展开的行并调度“ExpandHierarchyItems”调用，这将 UI 捆绑了很长时间，只是为了防止可怕的滚动体验（极慢/庞大的 UI锁定，节点未扩展，没有子节点，错误级别的行）。最新版本的 Telerik WPF，windows 7 x64 - i7s 上慢，i5 上更慢。

我现在将这个简单的场景与替代方案（devexpress 等）进行比较......

有没有人对提高性能有任何建议？或者我会采取明确的“Telerik 无法提供比这更好的，并且（其他）会”作为答案。

来自http://www.telerik.com/community/forums/wpf/treelist/radtreelistview-poor-performance.aspx的交叉帖子

4

2 回答 2

1

我刚刚播放了你的演示几分钟。

当我尝试编辑 RadTreeListView 模板时出现错误“Key cannot be null”。已ControlTemplate添加到资源中，但无法应用于控件。所以我无法播放模板。

对于性能，据我所知，我们可以考虑以下几个方面：

1)布局

查看 RadTreeListView 的可视化树（您可以使用WPF Tree Visualizer），它包含从树根到树叶递归的几个 Grid。

根据 MSDN，布局系统：

简而言之，布局是一个递归系统，它导致元素被调整大小、定位和绘制。更具体地说，布局描述了测量和排列 Panel 元素的 Children 集合的成员的过程。布局是一个密集的过程。Children 集合越大，必须进行的计算次数就越多。也可以根据拥有该集合的 Panel 元素定义的布局行为引入复杂性。

相对简单的面板（例如 Canvas）可以比更复杂的面板（例如 Grid ）具有明显更好的性能。

每次子 UIElement 更改其位置时，它都有可能触发布局系统的新传递。因此，了解可以调用布局系统的事件很重要，因为不必要的调用会导致应用程序性能下降。下面描述调用布局系统时发生的过程。

所以你的树越深，计算量就越大。

您应该尽量避免同时进行大量布局更改，并尝试在模板中使用更简单的面板（DataTemplate 和 ControlTemplate）

此链接提供了更多详细信息在渲染时间和性能方面，面板按什么顺序最有效？

2)渲染

这与 WPF 渲染实现有关。 BitmapEffect就是一个例子。

WPF 位图效果以软件模式呈现。任何应用效果的对象也将在软件中呈现。在大型视觉对象上使用位图效果或位图效果的动画属性时，性能下降最多。这并不是说您根本不应该以这种方式使用位图效果，但您应该谨慎使用并彻底测试，以确保您的用户获得您期望的体验。

于 2013-05-27T13:16:52.543 回答
0

我只是使用 WPF TreeListView。Telerik 至少对我们不起作用，速度不够快。

http://www.wpftreelistview.com

尝试了其他几个网格，但他们采用了更简单的框架更快的实现。

于 2014-10-30T16:59:11.040 回答