Technical Meeting 04/06/2006 1:15PM EDT
Agenda
| Item | People | Description |
|---|---|---|
| 1 | Shead | Debug / error output & widget naming followup. |
| 2 | Geveci | One performance/memory issue we have in paraview is due to the fact that we are creating a lot of widgets. Essentially, we create 1 widget per property. This amounts to thousands of widgets. Is ParaQ doing the same? Or are widgets grabbed from a pool (or something similar)? Is creating thousands of widgets an issue with Qt? The problem comes from the fact that our GUI is dynamic and grows as the user creates more pipeline objects. |
| 3 | Geveci | When does the GUI push values to the server manager? In Accept or everytime a widget changes? How are we going to handle domains? For example, when the user changes the active array, the range of the contour value widget has to be updated. In ParaView, this is done by setting a special value called "unchecked value" on the property and asking it to update all dependent domains. |
Action Items
- Berk Geveci - document unchecked property changes on the Wiki.
Discussion
The group discussed the current ParaView design, where a widget is automatically generated for every property of every proxy, regardless of whether it's ever needed or not. Everyone agreed that this behavior is suboptimal, and that ParaQ should create widgets on an "as-needed" basis in response to user interaction. In response to Berk's questions about when data is pushed to the server, it was agreed that the accept/reset mechanism would form a "command" layer that caches UI input until it is pushed to the server by an "accept" operation. This command layer would also cache old property values, so that they can be restored to widgets by an "undo" (or "reset") operation. The command layer will have to receive events from the server manager and emit corresponding signals so that the UI layer can stay in sync with the server manager contents, even if e.g: the server manager state is modified by a Python script in the midst of a set of un-accepted changes. Berk outlined one scenario where users will not be able to make arbitrary sets of changes before hitting "accept": if a user creates a new source, they will not be able to add filters to the source until it has been accepted, since the output of the source isn't known until it has been updated on the server. It was agreed that in this case (and possibly others), we will have to limit user interaction until they hit accept/reset. A related scenario is when the user has made a change to one property (such as timestep) that causes the domains of downstream properties to change - until the change has been pushed to the server, the UI may display incorrect ranges for downstream properties. The proposed solution was to allow the user "wiggle room" to enter property values outside the current ranges, if necessary. Ken pointed-out that this is already possible during animation and with some 3D widgets, which can be assigned arbitrary values manually, but are constrained (e.g: as to a bounding box) when used interactively. This suggests that it may be necessary to differentiate between "soft" and "hard" constraints on property values, where soft constraints such as the range of values available for a contour filter can be overridden, while hard constraints such as the domain of an opacity property cannot.
