Conversation
|
Does not fix #1578. |
This is a split of original commit 446630c, that removes changes unrelated to the ProgressBar.
446630c to
cdb9133
Compare
|
Extracted some unrelated code and moved to #1663. The actual technique used here, I'd need to spend a fair bit of time on to wrap my head around. I suppose that as long as it does not regress for GUI / non-GUI on any of the three OS's, it should be safe to merge, even if it fails to exhaustively solve all issues? It also looks like it may only fix the issue if |
|
Yes, as far as I can tell, there's no regression. And yes, it would only solve issues when using our own ThreadedLoop class - hopefully there won't be any other instances of this going on within MRView... Most of the changes are actually cosmetic, even though the diff looks bigger than it needs to. As mentioned earlier, the bulk of the logic is contained within a87abc3: basically set up condition variable that can be notified in the main thread, whose job is then to update the progressbar or exit if all worker threads have actually completed. |
Took quite a bit of experimentation, but I reckon this may finally fix #256 and #378 (and probably others besides). Commit a87abc3 is the relevant one here. I'll need all MRView users who've reported issues when the progressbar is shown to give this a spin and see whether the issue persists...