Get ListView Visible items

Question

I have a ListView which might contains a lot of items, so it is virtualized and recycling items. It does not use sort. I need to refresh some value display, but when there are too many items, it is too slow to update everything, so I would like to refresh only the visible items.

How could I get a list of all currently displayed items ? I tried to look into the ListView or in the ScrollViewer, but I still have no idea how to achieve this. The solution must NOT go through all items to test if they can be seen, because this would be too slow.

I'm not sure code or xaml would be useful, it is just a Virtualized/Recycling ListView with its ItemSource bound to an Array.

Edit : Answer :
thanks to akjoshi, I found the way :

• get the ScrollViewer of the ListView (with a FindDescendant method, that you can do yourself with the VisualTreeHelper ).

• read its ScrollViewer.VerticalOffset : it is the number of the first item shown

• read its ScrollViewer.ViewportHeight : it is the count of items shown.
  Rq : CanContentScroll must be true.

Solution 1

Have a look at this question on MSDN showing a technique to find out the visible ListView items -

How to find the rows (ListViewItem(s)) in a ListView that are actually visible?

Here's the relevant code from that post -

listView.ItemsSource = from i in Enumerable.Range(0, 100) select "Item" + i.ToString();
listView.Loaded += (sender, e) =>
{
    ScrollViewer scrollViewer = listView.GetVisualChild<ScrollViewer>(); //Extension method
    if (scrollViewer != null)
    {
        ScrollBar scrollBar = scrollViewer.Template.FindName("PART_VerticalScrollBar", scrollViewer) as ScrollBar;
        if (scrollBar != null)
        {
            scrollBar.ValueChanged += delegate
            {
                //VerticalOffset and ViweportHeight is actually what you want if UI virtualization is turned on.
                Console.WriteLine("Visible Item Start Index:{0}", scrollViewer.VerticalOffset);
                Console.WriteLine("Visible Item Count:{0}", scrollViewer.ViewportHeight);
            };
        }
    }
};

Another thing you should do is to use ObservableCollection as your ItemSource instead of an Array; that will definitely improve the performance.

Update:

Ya that might be true(array vs. ObservableCollection) but I would like to see some statistics related to this;

The real benefit of ObservableCollection is if you have a requirement to add/remove items from your ListView at run-time, in case of an Array you will have to reassign the ItemSource of ListView and the ListView first throws away its previous items and regenerates its entire list.

Solution 2

After trying to figure out something similar, I thought I would share my result here (as it seems easier than the other responses):

Simple visibility test I got from here.

private static bool IsUserVisible(FrameworkElement element, FrameworkElement container)
{
    if (!element.IsVisible)
        return false;

    Rect bounds =
        element.TransformToAncestor(container).TransformBounds(new Rect(0.0, 0.0, element.ActualWidth, element.ActualHeight));
    var rect = new Rect(0.0, 0.0, container.ActualWidth, container.ActualHeight);
    return rect.Contains(bounds.TopLeft) || rect.Contains(bounds.BottomRight);
}

Afterwards you can loop through the listboxitems and use that test to determine which are visible. Since the listboxitems are always ordered the same the first visible one in this list would be the first visible one to the user.

private List<object> GetVisibleItemsFromListbox(ListBox listBox, FrameworkElement parentToTestVisibility)
{
    var items = new List<object>();

    foreach (var item in PhotosListBox.Items)
    {
        if (IsUserVisible((ListBoxItem)listBox.ItemContainerGenerator.ContainerFromItem(item), parentToTestVisibility))
        {
            items.Add(item);
        }
        else if (items.Any())
        {
            break;
        }
    }

    return items;
}

Solution 3

How I see things :

• on one side, you have your data. They must be up to date, because this is where your information is in memory. Iterating on your data list should be pretty fast, and most of all, can be done on another thread, in background

• on the other side, you have the display. Your ListView already make the trick of refreshing only the datas displayed, since it's virtualizing ! You need no more tricks, it's already in place !

On last work, using a binding on an ObservableCollection is a good advice. If you intend to modify the ObservableCollection from an another thread, I would recommend this : http://blog.quantumbitdesigns.com/2008/07/22/wpf-cross-thread-collection-binding-part-1/

Comments

[Vivien Ruiz]

And if you don't know about it, you may be interested in the MVVM pattern ;)

[GameAlchemist]

i didn't investigate what was using CPU, but iterating through my list and having NotifyPropertyChanged on one property for all items was too heavy a task for the (slow) computer that must execute my program. The list might be 100.000 items long. So Virtualisation does not save the day. I tested the ObservableCollection to be >5 times slower than an array in my app.

[Vivien Ruiz]

Access to an array is definitly faster than access to an ObservableCollection. But ObservableCollection does all the work of keeping the UI up to date, using the binding. In my experience, the creation of new graphical items is what take most of the time. Not the work behind on the list of data.

[GameAlchemist]

Rq : For both performance and memory usage, the array outpasses the Observable collection by a very very large amount for my application. The number of items i use is in the 100.000-1.000.000 range.

[GameAlchemist]

The MS link you provide compares List with Observable collection, with a low item count (1000) and with virtualisation off, most probably because no noticable difference would be seen otherwise. So it does not apply to my case, and i wonder if it is even relevant for any case (why would someone turn virtualisation off ?)

[GameAlchemist]

The ListView will only regenerate items in sight, because no-one turns Virtualisation off except MS :). In my application, quite all the array might change on refresh. An ObsColl of items would cause memory exception for a count >200.000 (Win XP), and a filter time > 10 minute at that count. With an array i reached 5.000.000 below 1 minute. I wish i could provide some 'proof', but i know of no JSPerf for WPF... Bottom line for me is : ObsColl are better for not-so-big collections (and more handy), but nothing can beat an array for >> 100.000 items.

[Patrick]

Problem with ObservableCollection is it doesn't like threads, even when you use the Dispatcher. I had to switch to regular List and tell the app to just update on Count change because OC lost track of how many items it had added vs how many existed in the list, which crashed WPF.

[JobaDiniz]

And what about when CanContentScroll is false?

[akjoshi]

@JobaDiniz sry. don't remember much about this at present, there might be a way but can't recall anything ATM.

[XtianGIS]

Is this valid for a Listbox?