Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

progress bar timesteps #146

Open
jasper-hve opened this issue Mar 18, 2024 · 1 comment
Open

progress bar timesteps #146

jasper-hve opened this issue Mar 18, 2024 · 1 comment

Comments

@jasper-hve
Copy link

Progress bar now displays either 50% or 100% for tim calculations. For lengthy calculations it would be nice to see more steps. No idea if this is possible.

@Huite
Copy link
Contributor

Huite commented Apr 14, 2024

Yes, this should be possible. Most of the time is spent when computing heads, although it would be nice to get a more detailed breakdown (solving per element, computing heads, etc.).
The number of values to compute is fully known at the start, so we could return a percentage of the number of values computed. The plugin communicates with the backend via a basic command line interface, so we can essentially just print these percentages.

The (potentially) challenging thing is that we're using a threaded QgsTask to make sure the Tim computation isn't blocking QGIS. This is currently relatively simple: we start a task by sending a start message to the backend. When done, the backend writes a success (or failure) message to stdout.

To get a nice progress bar, we need to continuously write to stdout with the backend and read this in the plugin. Then, we can set progress of the task via: https://qgis.org/pyqgis/master/core/QgsTask.html#qgis.core.QgsTask.setProgress

Ideally, I think we'd break it down into the two tasks that actually end up taking most time:

  • Solving (progress per element)
  • Computing heads: progress per grid point (for ttim total progress: ntimes * ngridpoint)

The ugly thing is that we require significantly more parsing code, especially to determine in which phase we are, and we need to deal with exceptions cleanly. We also need to keep polling stdout continuously (could be as simple as for line in stdout).
At the same time, we're currently suppressing TimML and TTim's output to stdout (it prints stuff). Ideally, I guess, we should move the TTim and TimML printing to use a proper (configurable) logger instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants