Two flavors of virtualization
The IDataVirtualizingCollection is the right choice if you want to represent the whole virtualized backend in a IList-instance. The count of this list will be the same as the count of all elements stored in the virtualized backend. However, the data itself will be loaded page-wise and on demand as requested by the indexer. Each page is loaded completely (page size is configurable). The picture above illustrates a small example:
Let's say the virtualized backend contains 28 instances (datum) of data and the page size is set to five. The picture shows IDataVirtualizingCollection instances virtualizing this backend, which are in two different states. Several ways are possible to get to these states. For the partly loaded state an iteration from the 8th to the 17th datum could have taken place or maybe the 7th, 14th and 16th datum were requested explicitly without iteration. The actual request sequence doesn't matter, it is important to know that at least one of the page's datum was requested (let's ignore the preloading option for now). No instance of data from the empty pages were requested yet. Please note that in the actual implementation empty pages aren't instantiated before their data is requested, they are shown in the picture solely for illustrative purposes. In the fully loaded IDataVirtualizingCollection instance at least one datum from each page was requested. Depending on your configuration your virtualization may or may not be able to get into a fully loaded state. There are options to hoard once loaded pages or to dispose pages which weren't requested for a while (least recently used - LRU). In this example either the hoarding option was chosen or the LRU-option was set up with such an margins that no actual disposal is triggered. Note that the last page only contains three elements and not the configured page size of five. This will occur if the count of data instances in the backend doesn't divide by the page size without remainder. In this case the last page is the remainder, metaphorically speaking.
The ISlidingWindow is the right choice if you need a small section (window) of the virtualized backend at an arbitrary point (offset). I think it is best explained with a rather concrete example. Let's say you want to represent months in a tab control where each tab is representing one month and most of the time you'll be interested in the current month and the next four months. The DateTime-struct has a range "from 00:00:00 (midnight), January 1, 0001 Anno Domini (Common Era) through 11:59:59 P.M., December 31, 9999 A.D. (C.E.) in the Gregorian calendar" (see DateTime documentation). That are 119,988 months. Even if you get them UI and data virtualized, it is unpractical to show a tab control with so many tabs and scroll through them. It would be much nicer to show a section of five months (starting with the current) and have the ability to navigate this section through the range of months on demand. That is the intended use case for the ISlidingWindow.
Because the IList-interface has no concept of being a smaller section of an virtualized backend, the ISlidingWindow interface extends it in order to implement this concept. The Offset-Property is the index of the virtualized backend from which the sliding window is currently starting. The offset can be navigated by the SlidingLeft() (decreases the offset by one), SlidingRight() (increases the offset by one) and JumpTo(int index) (sets offset to given index) functions. The illustration above visualizes a sliding window applied to the same backend as in the illustration of the IDataVirtualizingCollection.
Under the hood the sliding window utilizes the same pagination system which is used by the data virtualizing collection (this is hidden from the illustration above). Conceptually the sliding window operates on top of a data virtualizing collection. Therefore the same benefits like "data only being requested on demand" and configuration options (like page size or page removal strategies) apply to a sliding window.