ThreadedGUI

From ParaQ Wiki
Revision as of 15:16, 15 November 2005 by Clinton (talk | contribs) (→‎Possible solutions considered)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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.