Difference between revisions of "NewModelViewArchitecture"

From CEGUI Wiki - Crazy Eddie's GUI System (Open Source)
Jump to: navigation, search
(add initial section for workflows)
(→‎Process)
 
(7 intermediate revisions by the same user not shown)
Line 5: Line 5:
  
 
=Proposed architecture=
 
=Proposed architecture=
−
TODO
 
−
- decide on another concepts than row/column
 
  
 
==ModelIndex==
 
==ModelIndex==
 
Identifies uniquely items in the model.
 
Identifies uniquely items in the model.
 +
This acts as a "dumb token" that it's entirely model's task to understand/process it.
  
 
Properties:
 
Properties:
−
* row : size_t
+
* modelData : void *
−
* column : size_t
+
−
* parent : ModelIndex
+
−
* modelData : void * (protected)
+
  
−
Methods:
+
==ItemDataRole==
−
* isValid
+
This is an enum, that contains the types of data the model is requested to provide.
  
−
Since ModelIndex will be '''friend''' with the ViewModel, only the VM will be able to use the model data and thus prevent View(s) to use it by mistake.
+
Enum members:
 +
* Text
 +
* ImageDecoration
 +
* Tooltip
 +
* <etc>
 +
* UserDefined (used as a base for user-defined custom roles)
  
−
==ViewModel==
+
==ItemModel==
−
The model for the view, that provides data like items count to the view. This is implemented by the developers that want to use this new architecture.
+
The model for the view, that provides data like items count to the view.
 +
This is implemented by the developers that want to use this new architecture.
  
 
Structure-related methods:
 
Structure-related methods:
−
* rowCount(modelIndex)
+
* childrenCount(modelIndex)
−
* columnCount(modelIndex)
+
* makeIndex(child, parentModelIndex)
−
* makeIndex(row, column, parentModelIndex)
+
 
* getParentIndex(modelIndex)
 
* getParentIndex(modelIndex)
  
 
Data-provider methods:
 
Data-provider methods:
−
* getString(modelIndex)
+
* getData(modelIndex, role)
−
* getImage(modelIndex)
+
  
 
Events:
 
Events:
−
* Rows/ColumnsAdded - startIndex, count
+
* ChildrenAdded - startIndex, count
−
* Rows/ColumnsRemoved - startIndex, count
+
* ChildrenRemoved - startIndex, count
−
* Rows/ColumnsDataChanged - startIndex, count
+
* ChildrenDataChanged - startIndex, count
  
 
TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?
 
TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?
Line 74: Line 74:
 
=Workflow examples=
 
=Workflow examples=
 
==List rendering==
 
==List rendering==
 +
 +
* Create root model index (parent=0)
 +
* Query the number of children for root
 +
* For each child (value=[0, childrenCount))
 +
** Create child model index (parent=rootModelIndex)
 +
** Query the image to be displayed for child index (Role=Imagedecoration)
 +
** Draw image
 +
** Query the text to be displayed for child index (Role=text)
 +
** Draw text
 +
* Render non-child elements
  
 
==Tree rendering==
 
==Tree rendering==
 +
===Full/first-time rendering===
 +
Triggered first time, or when whole model changes.
 +
 +
Recursive rendering procedure starting with a model index
 +
* > Given a parent model index
 +
* Query the number of children for index
 +
* For each child (value=[0, childrenCount))
 +
** Create child model index (parent=parentModelIndex)
 +
** Query the image to be displayed for child index (Role=imageDecoration)
 +
** Draw image
 +
** Query the text to be displayed for child index (Role=Text)
 +
** Draw text
 +
** Call procedure with child model index.
 +
 +
Actual rendering:
 +
* Call procedure defined above with root model index (parent = 0)
 +
* Render non-row elements
 +
 +
===Item(s) modified/isolated rendering===
 +
Triggered when some parts of the model changed, but not all.
 +
 +
=Performance=
 +
We want to measure how well the new views perform compared to the old ones.
 +
 +
==Tested views/widgets==
 +
The following combinations of related views/widgets will be compared:
 +
* ListWidget, ListView - Listbox, ItemListbox
 +
* TreeView, TreeWidget - Tree
 +
 +
==Process==
 +
Before running the performance tests be sure to be in RELEASE mode.
 +
The process of measuring the performance consists of executing the following steps. After each one, the render step should be called, to simulate a real usage:
 +
 +
For list views/widgets
 +
* Insert 5000 items
 +
* Clear list
 +
* Insert 10000 items
 +
* Delete first 1500 items
 +
* Repeat the following 17 times
 +
** Delete 13 items
 +
* Delete last 1230 items
 +
* Clear list
 +
* Insert 500 items
 +
* Insert 100 items after the 100'th item
 +
* Sort items ascending
 +
* Sort items descending
 +
 +
For the tree views/widgets:
 +
* Insert 100 root items, each with 100 items
 +
* Expand all items
 +
* Clear first 3 root item's children
 +
* Sort

Latest revision as of 18:44, 15 August 2014

Homepage for the WIP Model-View architecture for CEGUI widgets!

Introduction

The new architecture aims to unify the underlying implementation of several widgets so that they will use a common base model provider. This will involve a lot of ABI and API breakage.

Proposed architecture

ModelIndex

Identifies uniquely items in the model. This acts as a "dumb token" that it's entirely model's task to understand/process it.

Properties:

  • modelData : void *

ItemDataRole

This is an enum, that contains the types of data the model is requested to provide.

Enum members:

  • Text
  • ImageDecoration
  • Tooltip
  • <etc>
  • UserDefined (used as a base for user-defined custom roles)

ItemModel

The model for the view, that provides data like items count to the view. This is implemented by the developers that want to use this new architecture.

Structure-related methods:

  • childrenCount(modelIndex)
  • makeIndex(child, parentModelIndex)
  • getParentIndex(modelIndex)

Data-provider methods:

  • getData(modelIndex, role)

Events:

  • ChildrenAdded - startIndex, count
  • ChildrenRemoved - startIndex, count
  • ChildrenDataChanged - startIndex, count

TODO: Should we instead allow for a rectangular notification area? Like: startIndex / endIndex ?

ModelIndex Invalidation

Views might (read: will) store indices for a faster rendering or operations on the view. But these indices might become invalid if:

  • the underlying model instance changes (i.e.: model is set to another instance)
    • Solution: Just invalidate the memorized indices
  • an index from the "middle" is removed
    • Solution1: Create persistent model indices, like Qt does.
      • Con: too much management required, prone to errors.
    • Solution2: Query the model for validity
      • isValid will be moved to the ViewModel
    • Solution3: Other?

Affected widgets

Changed (to the new architecture) widgets

  • ComboBox + ComboDropList -> ComboView
  • Tree -> TreeView
  • ListBox -> ListView

New widgets

  • GridView
  • ListBoxWidget (combines model & view together for simple usage cases)

Removed/deprecated widgets

  • MultiColumnList (replaced by GridView)
  • ItemListbox (duplicated by ListBox)

To decide

  • ItemListBase
    • It's used in other places like: MenuBase and ScrolledItemListBase
    • Remove the other usages as well?

Workflow examples

List rendering

  • Create root model index (parent=0)
  • Query the number of children for root
  • For each child (value=[0, childrenCount))
    • Create child model index (parent=rootModelIndex)
    • Query the image to be displayed for child index (Role=Imagedecoration)
    • Draw image
    • Query the text to be displayed for child index (Role=text)
    • Draw text
  • Render non-child elements

Tree rendering

Full/first-time rendering

Triggered first time, or when whole model changes.

Recursive rendering procedure starting with a model index

  • > Given a parent model index
  • Query the number of children for index
  • For each child (value=[0, childrenCount))
    • Create child model index (parent=parentModelIndex)
    • Query the image to be displayed for child index (Role=imageDecoration)
    • Draw image
    • Query the text to be displayed for child index (Role=Text)
    • Draw text
    • Call procedure with child model index.

Actual rendering:

  • Call procedure defined above with root model index (parent = 0)
  • Render non-row elements

Item(s) modified/isolated rendering

Triggered when some parts of the model changed, but not all.

Performance

We want to measure how well the new views perform compared to the old ones.

Tested views/widgets

The following combinations of related views/widgets will be compared:

  • ListWidget, ListView - Listbox, ItemListbox
  • TreeView, TreeWidget - Tree

Process

Before running the performance tests be sure to be in RELEASE mode. The process of measuring the performance consists of executing the following steps. After each one, the render step should be called, to simulate a real usage:

For list views/widgets

  • Insert 5000 items
  • Clear list
  • Insert 10000 items
  • Delete first 1500 items
  • Repeat the following 17 times
    • Delete 13 items
  • Delete last 1230 items
  • Clear list
  • Insert 500 items
  • Insert 100 items after the 100'th item
  • Sort items ascending
  • Sort items descending

For the tree views/widgets:

  • Insert 100 root items, each with 100 items
  • Expand all items
  • Clear first 3 root item's children
  • Sort
Retrieved from "http://cegui.org/wiki/index.php?title=NewModelViewArchitecture&oldid=5492"