The-OpenROAD-Project
Allow GUI Interactivity During Command Execution
@arlpetergadfort What would it take to make the GUI interactive during command execution? I'd love to get this to work.
Some of the complexities off the top of my head.
- Preventing write operations during command execution.
- GUI elements potentially getting deleted.
Let me know if I'm missing something else.
odb doesn't have any locking around modifications so you would have to be very careful to avoid the GUI accessing data while an algorithm is writing it.
I think a small white list of operations we want to support is the most tractable thing to define/implement. Do you have key operations you want to perform?
@arlpetergadfort for your thoughts.
@QuantamHD @maliberty I've tried this a couple of times and had no real luck with it, but I think it would be very useful. I tried to add locks to the callbacks in the GUI, the overhead was not bad, but this made it possible to repaint everything every time (which was crazy slow). But maybe locks are only really needed on deletions (which are rare).
Moving the tcl and GUI into separate threads would be the first step. The nice thing is, the GUI knows that something is happening, so maybe we can use that to keep things safe instead of requiring ODB to assist. Preventing writes from the GUI would be easy, I think the harder thing would be keep track of deletions from ODB incase something is selected in the GUI.
I think the best you can hope for is to see the data as it was before the command was started. Trying to update as it goes will be slow and unstable. Something like the inspector is almost certain to have dangerous corner cases and would have to be disabled. Is it really useful to see a static view of data the is likely to be obsolete once the command finishes?
I think the best you can hope for is to see the data as it was before the command was started. Trying to update as it goes will be slow and unstable. Something like the inspector is almost certain to have dangerous corner cases and would have to be disabled. Is it really useful to see a static view of data the is likely to be obsolete once the command finishes?
I think this depends on the use case, I don't think watching routing / placement, etc is all that useful, but when calling commands that take a while to complete report_checks, report_power, etc... these do not modify the database and therefore should be safe to use the GUI during their execution.
The GUI may query sta while it is running which would not be safe even in this case (eg displaying clock nets, power heat map, etc). Even in that scenario limitations will have to be imposed.
Mostly pan, zoom, layer flipping, heat maps.
I have seen all option except layer flipping. @QuantamHD Can we keep this open or close?
#4540, a closed duplicate, adds more color to the use-cases for a capability.
As a general solution for allowing interactivity during processing is very complicated, could some incremental progress be made for important use-cases?
