Posterior visual bounds retrieval for the Plato framework

Plato is a MVVM compliant 2D on-canvas graphics framework I've been designing and implementing for developing Windows Store apps.

The major functionalities of the framework have been implemented. But they are yet to go through a more thorough testing and further verification through usage. The library is shared open source on codeplex at https://plato2d.codeplex.com/

The framework is designed to be

• based on Canvas and potentially able to handle any 2D graphics interactions
• providing coarse cropping of views as one of its major purposes.
• fully embracing MVVM pattern (by either using data template or dynamic user control creation) and able to targetting non-MVVM settings (such as Direct2D directly) and making the UI programming easier, maintainable and highly flexible
• loosely coupled using dependency resolver (Trollveggen, another library I created for resolving Windows Store app runtime module dependencies)
• friendly with undo/redo/(animation)recording framework Herodotus
• with minimum modification it can also be ported to WPF which is pretty much an extended version of Windows Store environment

The framework is mainly composed of the following components,

Core Pipeline

The major purpose of the pipeline, which is also that of the whole Plato framework, is to determine which models (data objects) should have their view models and models added to the system and therefore displayed on the screen whereas which shouldn't.

• IModelProvider, which collects visible models from model manager (which can be the same entity that implements this interface) determined by the methods exposed by the Visual department, organises them linearly in display order and feeds them through a collection and a collection change notification event to the renderer
• Renderer, which in case of MVVM pattern is set of view model and model manager and in others could be simply a model drawer/renderer, is tied up with IModelProvider, receives the collection updates from IModelProvider and is responsible for displaying them on the screen as in the best way as it can. In MVVM case, it mainly consists of a view model manager that is directly fed by IModelProvider and organises a view models (may use view model builder to create new view models) collection accordingly and a view manager that is listening on the changes of the view models collection and in turn organises views accordingly on the canvas.

Any model change whether it be

• caused by model data change
• visual perspective change

will fire an event to the entity(entites) that eventually implements IModelProvider to get it to update the visible list as well as pass the event on to for instance the view model to update the appearance of the view accordingly.

Visual

The Visual department is responsible for

- view world conversion (ISightManager)

- hit and rectangular selection management

- various visual object dimension measuring for the Core Pipeline department and others (like FitAll)

- ...

Now the particular problem I was facing and this article is discussing is how to fit into this framework the case where the visual size of the object cannot be deduced from the model side of the pipeline which is a natural assumption of this framework.

A concrete example is how we deal with text elements. The scenario is like below

• In the model part: the Text class that has a TextString property and a few others related to font information all of which can potentially change the size of its visual representation. And since it leaves the visual side to determine the size of the object based on the actual size of the text rendered, it has no way to provide the visual size for either a whether-on-screen check or bounds check for hit/selection.
• The view model part: originally it should comfortably receive updates from the model and interpret them to view update as it normally does. However now it is encumbered with the duty to give feedback to the model and what's worse is it needs to wait for what's wanted from the view before it can do that.

To address this is issue now we need to enrich the Visual department with the functionalities other than the sight management listed above which if no such complexity is involved we can live without.
Before integrating this machanism the frame work is like

                                   o IModelProvider 
      ModelChangedEvent                   |

Model --------------------> ModelManager  ------------ >  ViewModelManager ------> ViewManager

   |                             ^                             |...|      Binding    |...| 
   |                             |                           ViewModel  -----------> View (on Canvas)
   |                             |  -----o ISightManager            (Update dimensions etc)  
   | VisualBounds                |                                
   ---------------------->  VisualTraits  

NOTE the events propagation and processing in this framework (except the View/ViewModel interactions) are entirely synchronous and on-stack. Because as far as this can work this is the most efficient. Ensuring this can work means endless recursive calls are avoided and dependencies are resolved.

The whole framework becomes

                                           o IModelProvider
      ModelChangedEvent (a)                |

Model --------------------> ModelManager  ------------ >  ViewModelManager ------> ViewManager

^  |                             ^                             |...|      Binding    |...|
|  |                             |                           ViewModel <-----------> View  (on Canvas)
|  |  VisualToMeasure            |  -----o ISightManager         |   (Update dimensions etc)
|  |  request                    |                               |
|  ---------------------->  VisualTraits <-----------------------| 
|                                       reset VisualToMeasure(c) |
|                                                                |
------------------------------------------------------------------
 Reinitiate ModelChange for invalid bounds with/without VisualToMeasure(b)

(a) Model initiates VisualToMeasure flagged change event whenever a bounds changing condition happens and bounds become invalid

(b) The view model updates the visual bounds of the model on it; whether or not it should cancel the VisualToMeasure depending on if it's certain that it has got the final results. But it should eventually resets it to give the object the chance to be taken off from the pipeline as appropriate. And it is the only legimitate entity to do so.

(c) One easy and safe way to do so is -

Every time the dimension updater in the view model is invoked normally by either the model update handler or view layout change handler,

• Update the visual bounds of the model (therefore VisualBoundsValid is set to true accordingly)
• Fire a VisualToMeasure flagged model change event
• Reset the VisualToMeasure flag right after on VisualTraits

Implementation-wise, it's been found that one needs to be cautious with tying up the feedback handler with the LayoutUpdated event of the view as it's easy to create suspicious cyclic calls, which would be detected by the system first.

The only apparent defect is that the view and viewmodel will remain in the pipeline until the next time it's interogated, which happens when the view changes. However this happens quite often and is almost a perfectly justifiable time to decide whether the object should be swapped out of the pipeline. (The major unlikely scenario this could become an issue is when a large number of such objects outside the view scope are changing with view scope not changing at all, which is most likely caused by undo/redo operations, in which case the creation and retention of the unnecessary view/view model objects continue until a view change is made)

Reviews and Criticisms

One of the major downsides/limitations of this framework is that to make the visual adjustment feedback work it still has to have strong coupling between visual/view sections and the model management which potentially restricts or complicates the extension of the archecture to a distributed setting. This will be discussed in the follow up article The design of a distributed variant of Plato framework to support collaborated editing