MantisBT
Mantis Bug Tracker Workflow

View Revisions: Issue #30598 All Revisions ] Back to Issue ]
Summary 0030598: Visualization - redesign Prs3d_Drawer as aspects map
Revision 2019-03-25 14:26 by kgv
Description Current Prs3d_Drawer design provides a list of fixed properties of different types:
- Boolean flags
- Real parameters
- Prs3d_ShadingAspect
- Prs3d_TextAspect
- Prs3d_IsoAspect
- Prs3d_LineAspect
- Prs3d_PlaneAspect
- Prs3d_ArrowAspect
- Prs3d_DatumAspect
- Prs3d_DimensionAspect

All these properties can be either defined within Prs3d_Drawer instance ("own" aspects), or retrieved from Link aspect.

In addition, most properties are dynamically initialized and stored as Prs3d_Drawer instance fields when fetched and actually undefined (property is not "own" nor defined within Link).
This is an obsolete approach which should be avoided - instead it is proposed creating a global Prs3d_Drawer instance to preserve current behavior or to throw exception in this case.

The new Prs3d_Drawer design should define a map of properties so that it is preferable to define common base class for all properties. The key type of this map is to be determined - it might be string or integer number with enumeration defining UPPER value for values reserved by OCCT, so that applications can define own properties.

The rationale for map of aspects instead of a fixed list is that even existing Prs3d_Drawer definition includes too many properties, while most of properties have effect only within sub-set of AIS classes. It is also impossible defining more presentation properties through common mechanism of Prs3d_Drawer without its extension, so that custom presentations have to define such properties as class fields.

To avoid massive API changes, existing getter/setters have to be preserved.

MeshVS_Drawer is one of candidates for possible usage of new Prs3d_Drawer API.
Revision 2019-03-21 19:40 by kgv
Description Current Prs3d_Drawer design provides a list of fixed properties of different types:
- Boolean flags
- Real parameters
- Prs3d_ShadingAspect
- Prs3d_TextAspect
- Prs3d_IsoAspect
- Prs3d_LineAspect
- Prs3d_PlaneAspect
- Prs3d_ArrowAspect
- Prs3d_DatumAspect
- Prs3d_DimensionAspect

All these properties can be either defined within Prs3d_Drawer instance ("own" aspects), or retrieved from Link aspect.

In addition, most properties are dynamically initialized and stored as Prs3d_Drawer instance fields when fetched and actually undefined (property is not "own" nor defined within Link).
This is an obsolete approach which should be avoided - instead it is proposed creating a global Prs3d_Drawer instance to preserve current behavior or to throw exception in this case.

The new Prs3d_Drawer design should define a map of properties so that it is preferable to define common base class for all properties. The key type of this map is to be determined - it might be string or integer number with enumeration defining UPPER value for values reserved by OCCT, so that applications can define own properties.

The rationale for map of aspects instead of a fixed list is that even existing Prs3d_Drawer definition includes too many properties, while most of properties have effect only within sub-set of AIS classes. It is also impossible defining more presentation properties through common mechanism of Prs3d_Drawer without its extension, so that custom presentations have to define such properties as class fields.

To avoid massive API changes, existing getter/setters have to be preserved.


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker