Commentary on View architecture for Custom Views: Difference between revisions
DaveDemarle (talk | contribs) (starting a page about views/representations and strategies so that we can figure out how to improve them) |
DaveDemarle (talk | contribs) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
ParaView 3's view/representation and strategy architecture is a great improvement over ParaView 2's render module architecture. But there is room for improvement, especially regarding the creation of custom views. The following describes what the weaknesses of the current architecture are and how some existing custom views are implemented. The purpose of this page is to tabulating this information so that our next design may be even stronger. | ParaView 3's view/representation and strategy architecture is a great improvement over ParaView 2's render module architecture. But there is room for improvement, especially regarding the creation of custom views. The following describes what the weaknesses of the current architecture are and how some existing custom views are implemented. The purpose of this page is to tabulating this information so that our next design may be even stronger. | ||
== Weaknesses == | |||
architecture complex, three independent class hierarchies (proxy definition, proxy, vtk) | |||
architecture not well documented | |||
hard to augment what is there without entirely replacing | |||
parallel rendering, many cases many classes, hard to reuse code | |||
configuration independence hard to replicate | |||
== Example Custom Views == | |||
Manta: | |||
change to XML parsing to do targetted replacement of parent proxy's subproxies/properties from | |||
override attribute | |||
client side classes (GLRenderer) different from server (MantaRenderer) | |||
hacked IceT out to do composite and not use GL | |||
Static Streaming Applications Views: | |||
replacing behavior high up the ViewProxy class hierarchy without breaking them | |||
contained real view is controlled by parent view | |||
written before xml override, so it used shared properties and dynamic swap at instantaion time | |||
Others?: | |||
Latest revision as of 18:54, 23 April 2010
ParaView 3's view/representation and strategy architecture is a great improvement over ParaView 2's render module architecture. But there is room for improvement, especially regarding the creation of custom views. The following describes what the weaknesses of the current architecture are and how some existing custom views are implemented. The purpose of this page is to tabulating this information so that our next design may be even stronger.
Weaknesses
architecture complex, three independent class hierarchies (proxy definition, proxy, vtk)
architecture not well documented
hard to augment what is there without entirely replacing
parallel rendering, many cases many classes, hard to reuse code
configuration independence hard to replicate
Example Custom Views
Manta:
change to XML parsing to do targetted replacement of parent proxy's subproxies/properties from override attribute
client side classes (GLRenderer) different from server (MantaRenderer)
hacked IceT out to do composite and not use GL
Static Streaming Applications Views:
replacing behavior high up the ViewProxy class hierarchy without breaking them
contained real view is controlled by parent view
written before xml override, so it used shared properties and dynamic swap at instantaion time
Others?:
