| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0004407 | ParaView | (No Category) | public | 2007-02-05 17:02 | 2007-02-21 18:17 | ||||
| Reporter | Ken Moreland | ||||||||
| Assigned To | Utkarsh Ayachit | ||||||||
| Priority | high | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | open | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0004407: Reader time overrides saved state time | ||||||||
| Description | I was playing with the ability to save the ParaView state with animation settings. I was loading disk_out_ref, creating an animation, and then saving the state. When I loaded the state, the start and end time got mangled (they were both set to 0). At first I thought that the start and end times were not being saved, but I tried a different animation with sphere source and it worked just fine. I think what is happening is that because disk_out_ref is an exodus file and the exodus reader has time support, ParaView is getting the time from the exodus reader and then overwriting the values that were loaded from the state file. My example is a little artificial, but it is not unreasonable for a user to change the start and end times of an animation to limit the animation to some interesting time slice, which I think will be lost under the current implementation. | ||||||||
| Tags | No tags attached. | ||||||||
| Project | |||||||||
| Topic Name | |||||||||
| Type | |||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0006409) Utkarsh Ayachit (administrator) 2007-02-13 11:27 |
Can we expect the user to lock the start/end times? If they are not locked it implies that they will be changed to fit the timevalues provided by all available readers. As as result the start/end times change to match the values from the reader (disk_out_ref provides just 1 time value 0, hence end/start are getting set to 0). We can make it such that the time locks get turned on when the user edits the start or end time, that way his changes will be maintained. |
|
(0006413) Ken Moreland (manager) 2007-02-13 14:38 |
Utkarsh, There are two separate issues being mixed in your previous response. The first is what to set the time bounds to when loading the state and the second is what to set the time bounds to when loading readers. In that case of loading the state file (which is the case I originally intended to address with this bug), the answer is obvious. The state should come back, as much as possible, exactly like the user had it when it was saved. This includes the start and stop time of the animation. When loading the state file, the start and stop animation time should ALWAYS be set to those stored in the state regardless of the time in any loaded readers. Under most circumstances, the time bounds will have been set by the same readers anyway, so this is a no-op. If the user has changed to the time bounds, there was probably a reason for it and we should restore those bounds. The other more tricky case of when a user just creates a reader that supports time can be a little more tricky. I thought about this for a while, and then decided that for PV 3.0 we should just do the simple thing and always adjust the animation time bounds accordingly. We can change that later if we need to. |
|
(0006443) Utkarsh Ayachit (administrator) 2007-02-15 15:17 |
Should be fixed now. When loading state the start/end times from the state are preserved. Animation start/end times are already adjusted when a new source is added which has timesteps (unless ranges are locked). |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2011-06-16 13:10 | Zack Galbreath | Category | => (No Category) |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |