Maybe this is me having some subjective feeling, but to me it seems that navigating Picard is now much slower/less responsive during the period that releases are being loaded.
I think I read a while back that responsiveness was going to be improved (something regarding threads I think), maybe that has not yet been implemented?
We had this one change in Picard 2.9 beta 1 that really improved responsiveness of the UI while loading a lot of files. The change was rather small. It moved the rather expensive operation of updating a file’s status (which involves comparing the metadata) away from the main UI thread to a background thread (see PICARD-2609). In general it really makes sense, but unfortunately it caused those inconsistencies with the displayed file status.
There was no easy way to solve this. Fixing this will require a major refactoring. So in order to ship 2.9 we reverted this change and we are back on the pre 2.9 performance.
3 Likes
Thanks for confirming/explaining.
2 Likes
@hiccup Turns out that all portable installs shared the same instance was actually a bug. Instances are only supposed to be shared if the same Picard version and the same config file location are used. For portable installs the config file location is usually separate, so it was supposed to have a separate instance per portable install.
But actually this was broken. This even caused the --stand-alone-instance parameter to have no effect. It’s fixed now, we’ll have the fix shipped with the 2.9.1 release.
3 Likes
I confirm. Often when you click on the scroll bar in the left or right panel of Picard, the text “Not responding” appears in the top bar. The background turns grey.
The problem is in the latest Picard v. 2.9