Has anyone been able to get the progress bar for UXP API 2 to work? I have a function that takes 10+ seconds. However, the progress bar only appears for a fraction of a second at the end of the function. It just flashes on the screen after everything has finished processing.
For testing, I added more commands to slow down the function. However, it still just flashes for a fraction of a second at the very end regardless of how long the function takes to run.
The documentation states that it will automatically appear after 2 seconds. Is there a way to force it to appear right away without a delay? I tried using executionControl.reportProgress to set the progress bar value at the beginning of the function. I was hoping that this would set the value and pop up the progress bar immediately. However, it didn’t work. It still just popped it up briefly at the end.
I assume you’re having one batchPlay call with several descriptors, which takes 10+ seconds? I noticed the same behavior, currently the progress bar only automatically shows up if you have multiple batchPlay calls that take longer than two seconds.
Yes, I have 47 descriptors in one batch play. I just tested by separating them into 47 individual batchPlay. With the individual batchPlay commands the progress bar works but it runs about 30% slower.
So it seems the progress bar only updates between batchPlay commands so if you are just using one batchPlay with many decriptors then it just show briefly at the end. When breaking it out to run individual batchPlay commands then it runs fine.
However, it runs faster when putting multiple descriptors into a single batchPlay command. So it looks like there are 3 options.
Run with all decriptors in one batchPlay and not have the progress bar at all.
Run with one decriptor per batchPlay and update the progress value after each one. This runs perfectly and updates the progress bar as it should. However, it executes slower than running all descriptors in one batchPlay. In my case it is 30% slower but this may vary based on the actual descriptors being used I am guessing.
Separate the batchPlay into several batchPlay but still use multiple descriptors per batchPlay. This should provide most of the speed benefits by running multiple descriptors but by running a few batchPlay instead of just one, the progress bar can be updated a few times. The bar progress stepping won’t be a smooth, just a larger jumps. But the progress bar cancel button would then be available.
What I would really like to know is if the progress bar could be forced to display immediately without a delay. For the times that I know it will be used, it would be nice to just have it pop up immediately. This would make the plugin appear to be more responsive. The delay seems to give the impression that the plugin is lagging, even though it is actually executing. I could see users thinking this anyway.
Any udpates on this? I just tried batch processing. 10 files adding 1000 guides in each… each image takes like 10s and no progress bar all the time… and there are at least 20 000 batchPlay calls
I would realy like to have something reliable so I wouldn’t need to write my own progressbar UI dialogs or something.
