| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0009055 | ParaView | Bug | public | 2009-05-20 16:37 | 2009-06-09 20:36 | ||||
| Reporter | Ken Moreland | ||||||||
| Assigned To | Utkarsh Ayachit | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | 3.6 | Fixed in Version | 3.6 | ||||||
| Summary | 0009055: Large data inappropriately collected to client in reset camera | ||||||||
| Description | Creating data in client/server mode, the decision to collect data is initially set based on the compositing decision for the previous render. The upshot is that ParaView will push large data to the client when first opened even when it should not. At best this slows things down a lot. At works, it saturates the client with geometry and crashes it. To see the problem in operation, do the following. 1. Run the client in a debugger and attach to a server. 2. Set the compositing threshold to about 3 MB (in Edit->Settings). Verify that you are now not using compositing threshold. 3. Set a breakpoint (on the client) at vtkSMSimpleParallelStrategy::GetMoveMode(). 4. Create a Sphere source. Set the Theta Resolution and Phi Resolution parameters to their maximum and then hit Apply. (This will create ~90MB of data.) 5. After hitting apply you will reach the breakpoint. Observe the compositing flag and stack trace. Notice that although we are creating 90MB of geometry, the compositing mode is still set to off. The problem here is that the GetMoveMode is being called during a pipeline update for a reset camera. Since this is before a StillRender is being called (and probably before the geometry is actually created), the appropriate compositing determination has not been set yet. The compositing flag is based on the previous render when there was no geometry. | ||||||||
| Tags | No tags attached. | ||||||||
| Project | |||||||||
| Topic Name | |||||||||
| Type | |||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0016636) Utkarsh Ayachit (administrator) 2009-06-04 15:46 |
Dont' call UpdateAllRepresentations() explicitly in ResetCamera(), since UpdateAllRepresentations() results in delivering the data to rendering nodes as well. All we want is for the pipeline to be updated until enough information about the bounds can be known. That's already done by vtkSMRepresentationProxy::GetBounds(). So we don't need to call update on representations explicitly here. vtkSMRepresentationProxy has the fancy API to update the pipelines without actually delivering the data anywhere. This gets used when GetBounds() is called. /cvsroot/ParaView3/ParaView3/Servers/ServerManager/vtkSMRenderViewProxy.cxx,v <-- Servers/ServerManager/vtkSMRenderViewProxy.cxx new revision: 1.87; previous revision: 1.86 committed to 3.6 branch as well. /cvsroot/ParaView3/ParaView3/Servers/ServerManager/vtkSMRenderViewProxy.cxx,v <-- Servers/ServerManager/vtkSMRenderViewProxy.cxx new revision: 1.86.2.1; previous revision: 1.86 |
|
(0016681) Alan Scott (manager) 2009-06-09 20:36 |
Internal to ParaView, assuming it is correct. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2009-05-20 16:37 | Ken Moreland | New Issue | |
| 2009-05-20 16:37 | Ken Moreland | Status | backlog => tabled |
| 2009-05-20 16:37 | Ken Moreland | Assigned To | => Utkarsh Ayachit |
| 2009-06-04 15:46 | Utkarsh Ayachit | Note Added: 0016636 | |
| 2009-06-04 15:46 | Utkarsh Ayachit | Status | tabled => @80@ |
| 2009-06-04 15:46 | Utkarsh Ayachit | Fixed in Version | => 3.6 |
| 2009-06-04 15:46 | Utkarsh Ayachit | Resolution | open => fixed |
| 2009-06-09 20:36 | Alan Scott | Note Added: 0016681 | |
| 2009-06-09 20:36 | Alan Scott | Status | @80@ => closed |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |