A popular trend on the web is to use immutable (=readonly, const) data structures and functional programming to represent the model or view-model. See Facebook React, Redux and ELM. If only parts of the view-model are changing (as is usually the case), this approach works very well, and using immutable data can make an application much more robust and faster to develop. Also immutable data gives recording and playback of application states for free, allowing easy debugging and faster reproduction of bugs (see Redux time machine for example)

Often a XAML-based application uses data binding to keep the UI in sync with the view-model. This works fine if a view-model is mutable (using INotifyPropertyChanged), but with an immutable view-model, the root data-context will always refer to different object (because generating a new child means all immutable ancestors must be updated as well), meaning the full visual tree will most likely be reconstructed.

That is, unless the UI engine is more clever and can handle this by doing diffing between the previous view-model (the previous data-context) and the new data-context (Facebook React actually does this on a virtual representation of the browsers DOM, but it can just as well work on an immutable view-model). Since an immutable data-structure is guaranteed to be the same if it has the same reference (aka pointer, address), the diffing of a full visual sub-tree can stop as soon as the data-context is the same. Maybe a custom inheritable property on the UI element hinting it that the data-context refers to an immutable object could even help performance here.

So basically if the UI engine detects that the data-context of the current UI element refers to a different data-context, it should not rebuild its full visual tree, but recursively reuse as much of the visual sub-trees as possible (most descendants in the UI tree will refer to the same data-context, and those sub-trees can be reused).

Of course immutable data means two-way binding cannot work anymore (and that actually is a really good thing for complex applications). Instead, changes triggered by the user bubble up to the root as events that are packaged in a composite "action", that can be decomposed by a "reducer" function again. Or one can use true FRP libraries like Sodium to wire all the dependencies. I will not address this in this question

So finally my question is, how does the Noesis GUI engine updates its visual tree when the data-context refers to a new object? Does it indeed build a completely new visual tree, or is it clever? How does this affect performance in Noesis GUI (i.e. are GPU cached objects flushed)?

Thanks,
Peter Verswyvelen

PS: For WPF and UWP, what I did is to define my immutable view-models using a T4 template, using a custom code generator that automatically generates a mutable version of the view-model, using Sodium FRP cell's as properties. So certainly this solution can also work with Noesis GUI, but it would be so nice if a modern UI framework like Noesis GUI supported these "revolutionary" new UI architectures out of the box )

Hi,

Very interesting topic

Currently NoesisGUI updates the visual representation of an item if you change the associated DataContext. But we can probably try to be smart and don't discard the old visual tree if data templates don't change with the new DataContext. If you don't mind, please start a new ticket in our bugtracker so we can discuss about it and be informed of progress.

About the GPU objects, resources stored in dictionaries (like brushes or geometries) are reused even if visual tree changes. But the elements of the visual tree that render their own geometries (like Borders, Shapes, Images, TextBlocks), as they are regenerated when DataContext changes, their GPU representation is also regenerated.

So right now using a mutable model (with INotifyPropertyChanged) seems a better approach to perform updates if you want to avoid unnecessary visual tree changes.

Thanks for the feedback! Very interesting information.

Yes, a "Facebook react style" update of the visual tree when the datacontext changes is an interesting feature, especially for prototyping.