Yes, that is a good trick.

I’m glad you’re enjoying working with our platform :) Although we have some rough edges, I am overall very proud of what we have accomplished.

Bea

Oh yes I know how hard it can be to combine family life, programming as a work, programming as a passion, and additional hobbies :-)

I am aware of the “reverse binding” (Target To Source”) scenario, but thanks for reminding me. Maybe I can use that in some cases.

In the typical case where I need this, however, I don’t think it’s possible. Typically, I’d like to pass a reference to a FrameworkElement to the converter, so that I can perform a “TryFindResource” on that element. Currently, I am using a MultiBinding to do that, where the first Binding is the FrameworkElement (RelativeSource Self), and the second value is the actual value I want to convert. That’s a neat trick (Thanks Dr WPF…) but it’s just a trick.

Anyway :-) Finding a workaround to these problems has been a very interesting and creative task for me these last weeks, so thank the team for me :-)

Greetings,
Laurent

I appreciate your nice words. I’m planning to starting being more active in my blog. It’s been really hard to manage a more than full time job, an active blog, and a life. However, I really miss writing and plan to do it more often.

Yes, we’ve heard that suggestion before. I explained a partial workaround in this blog post, under the “Binding to methods” section. However, it’s not a complete workaround – it doesn’t work for many common scenarios.

We would like to support this scenario, but we can’t simply make those properties DPs because that would mean Binding and ObjectDataProvider would have to be DOs. Apart from possibly affecting perf, it would open up many illegal scenarios that would greatly increase our test matrix. We would like to come up with a design that would allow a Binding to depend on data without necessarily allowing it to be data bound. We have a work item to do this, but it will require some cleaver designing.

Thanks a lot for your suggestions!

Bea

Your thorough comment is very very appreciated! I brought your ideas to my team, and here is what we discussed:

1) You mention that scrolling speed degrades linearly with the number of items displayed. If you want to scroll from item 1 to item 30, the total number of items in your ListBox should not affect perf that much. It will affect a little because of the lack of data virtualization, but since ListBox has UI virtualization, we don’t create wrappers for the items that are not visible. However, if you are constantly scrolling to sections that haven’t been rendered before, then there will be a delay because we need to create the UI wrappers for those items every time you scroll. This is the price we pay to have good initial rendering speed.
Having said that, I must add that we’ve been investigating possible improvements for this scenario. It’s heard to say at this point whether we’ll be able to improve it or not, but I’m keeping my fingers crossed.

2) That’s a great idea – giving the user the capability to control the latency of the discarding of off-screen items. I’ve already added it to our list of feature ideas for the future. I don’t think we should allow customers to specify the delay in the form of time, but we could certainly allow control about the priority of this operation in the dispatcher queue. You would like the discarding of the items to have a lower priority, and we got feedback recently from another customer that would like that operation to have higher priority. The other customer mentioned to us that, if you keep scrolling up and down very quickly, the non-visible items are not discarded, and the memory consumption keep growing. By giving him an API to increase the priority of the discarding operation, he could adjust the behavior of his scenario.

3) Actually, we already detect that scenario today, and it’s possible we’ll be able to improve this scenario a little. We are not looking into layout optimizations in particular, we’re mostly researching the implications of recycling containers. But here’s a tip that you can use today: the more fixed widths and heights you have in your elements, the cheaper the layout will be.

4) Actually, this is the first time we hear this. Do you have a specific sample that you can share with us that shows slow keyboard scrolling? We would be happy to run perf tests on your scenario and see if there is anything we can do to improve that.

Thank you so much for your thorough comment! Feedback like yours greatly helps us improve WPF, and make sure that it solves what customers want!

Bea

It’s great to see you posting again. I have trained quite a few people to WPF lately in my firm, and always mention your blog as *the* place to find information about binding. I unfortunately had to add “but she didn’t post much recently”. Hopefully now I can stop saying this :-)

Side note for the binding team: We really need to be able to bind constructor parameters or method parameters to other elements in XAML. For example something like:

<ObjectDataProvider x:Key=”MyODP”>
<ObjectDataProvider.ConstructorParameters>
<sys:Int32>
<Binding ElementName=”MainWindow” Path=”ActualWidth”/>
</sys:Int32>
</ObjectDataProvider.ConstructorParameters>
</ObjectDataProvider>

Also, why not do ConverterParameter a DP so that we can bind to it:

<Button>
<Binding Source=”{StaticResource Something}”
Path=”MyProperty”
Converter=”{StaticResource MyConverter}”
ConverterParameter=”{Binding ElementName=MyElement, Path=MyValue}”>
</Binding>
</Button>

That would be really helpful!

Keep posting :-)
Laurent

My tricks are very simple to implement. It is definetely possible to implement really fancy and solid data and UI virtualization custom solutions specific to particular scenarios, but I am not planning to cover that.

I appreciate your excitement though :)

Bea

I’ve some comments about the performance of the existing VirtualizingStackPanel when used with large data sets. I don’t know what can be done about these problems in the current version, but hopefully you’ll be able to improve on them in the future:

1) Initial rendering speed is fixed and at an acceptable level, but scrolling/repainting speed degrades linearly as the number of items displayed is increased and/or the complexity of the item templates is increased. There is a noticeable delay when the scrollbar is moved to an area that was not previously rendered (the scrollbar thumb lags significantly behind the mouse cursor), and the scrolling experience becomes choppy.

2) I noticed that as long as the user continues scrolling (without releasing the mouse button) and returns to items that were already visited, the scrolling becomes smooth. It seems that the off-screen items that were visited are retained during the scrolling interaction. However, once the user releases the mouse button, all off-screen items are immediately discarded, and on the next scrolling the same choppy behavior will be manifested. I found no programmatic way to control the latency of the discarding of off-screen items, which can be useful in many cases.

3) I also found no programmatic way to inform the VirtualizingStackPanel that all items have uniform display templates (a very common occurrence), which could provide a useful performance optimization hint (similar to the “table-layout:fixed” property that exists in IE/HTML).

4) Scrolling using the keyboard is also considerably slower than I would expect.