ThreadedGUI: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 11: | Line 11: | ||
2. One thread for GUI and server manager, multiple threads, one for each server.<br> | 2. One thread for GUI and server manager, multiple threads, one for each server.<br> | ||
3. One thread for GUI and multiple threads, one for each server manager.<br> | 3. One thread for GUI and multiple threads, one for each server manager.<br> | ||
4. One thread for GUI, server manager, and all | 4. One thread for GUI, server manager, and all server connections.<br> | ||
5. One thread for GUI and server manager, and all server connections. Add an event loop to the server manager and tie it with the client event loop. Render requests can be posted to a server, and the server manager returns immediately. When a server is done, it notifies the server manager event loop and the image is retrieved and given to the client. Instead of threading and handling serialization between threads, just add serialization with the already existing processes. | |||
==Threading issues and considerations== | ==Threading issues and considerations== | ||
| Line 17: | Line 18: | ||
* Inter-server interactions get complicated by threading. Consider data comparison between two servers. A client side VTK filter can interact with reduced data on multiple servers. | * Inter-server interactions get complicated by threading. Consider data comparison between two servers. A client side VTK filter can interact with reduced data on multiple servers. | ||
* Threads don't play well with MPI. | * Threads don't play well with MPI. | ||
* 3d Widgets | |||
* GUI on separate thread from server manager means extra work to get the render module's image to the gui screen vtkRenderWindow/QVTKWidget issue. | |||
==Proposed Solution== | ==Proposed Solution== | ||
Multithreading the server manager is basically not worth it. | Multithreading the server manager is basically not worth it. | ||
Solution #4 is suggested. The servers should be sending progress events back to the client at all times. The GUI client can use that time to update progress bars, respond to users minimizing, maximizing, repaints, etc... This means interaction with non-busy servers would not be supported. The graphics window during these times could actually paint something that shows the server manager is busy generating an image. | Solution #4 is suggested. The servers should be sending progress events back to the client at all times. The GUI client can use that time to update progress bars, respond to users minimizing, maximizing, repaints, etc... This means interaction with non-busy servers would not be supported. The graphics window during these times could actually paint something that shows the server manager is busy generating an image. | ||
Latest revision as of 14:16, 15 November 2005
Minimum Requirements
While server manager/servers are busy:
- support repainting of GUI to look alive
- support minimizing, restoring, maximizing of GUI
- support exiting of application
Would-be-nice-to-have Requirements
- support interaction with non-busy servers (open another file on another server, view model in graphics window for non-busy server, etc...)
Possible solutions considered
1. One thread for GUI and one thread for server manager.
2. One thread for GUI and server manager, multiple threads, one for each server.
3. One thread for GUI and multiple threads, one for each server manager.
4. One thread for GUI, server manager, and all server connections.
5. One thread for GUI and server manager, and all server connections. Add an event loop to the server manager and tie it with the client event loop. Render requests can be posted to a server, and the server manager returns immediately. When a server is done, it notifies the server manager event loop and the image is retrieved and given to the client. Instead of threading and handling serialization between threads, just add serialization with the already existing processes.
Threading issues and considerations
- Client side OpenGL may not support multiple threads. Which means render module(s) might need to be on GUI thread.
- Inter-server interactions get complicated by threading. Consider data comparison between two servers. A client side VTK filter can interact with reduced data on multiple servers.
- Threads don't play well with MPI.
- 3d Widgets
- GUI on separate thread from server manager means extra work to get the render module's image to the gui screen vtkRenderWindow/QVTKWidget issue.
Proposed Solution
Multithreading the server manager is basically not worth it. Solution #4 is suggested. The servers should be sending progress events back to the client at all times. The GUI client can use that time to update progress bars, respond to users minimizing, maximizing, repaints, etc... This means interaction with non-busy servers would not be supported. The graphics window during these times could actually paint something that shows the server manager is busy generating an image.
