Hi.
SGPro would run significantly faster if the code for loading the data for a sequence, and for loading the events was decoupled from the UI.
Currently, when copying events from one target to another, it’s possible to see this happening visually. As this is the case, it means that the code is closely coupled. The performance of the copy functions are impacted by having to render UI Components - which may not be needed.
Rather than have the UI components created at load time, it would make more sense to only create them when needed, i.e. you select the target to view the events for that target.
When copying the items from one target to another disable the UI updates on the destination target until after the copy process has been completed.
You could load the UI components when the target is selected, and then delete them if the target is changed. the delete could be a quick delete of all objects when the UI is not currently visible on screen. When it is needed, the disabled UI will allow the code to run faster without the need to redraw the screen until the processing has completed.
This will allow SGPro to be easily used to capture large mosaics, or have many different targets present in the same sequence.
You sound like a software engineer so I’m sure you know that you often make mistakes you regret while attempting to get something out quickly or because of bad decisions at the time or other assumptions. This is one of those…
Yes I’d love to address this and many other things but they all have to get prioritized. While refactoring a large piece of this would be awesome to do it also opens us up for a lot of regression and unnecessary risk for a (generally) minor performance improvement.
Yep. I’m a software engineer and yes I know exactly what you mean about the risks of modifying existing code what doesn’t have unit testing to minimise regression risks.
I completely appreciate that this could require a large refactor, in fact if I were looking at this, I’d be wondering initially about seeing if there’s ways of doing it in several small iterations to keep risks down. Sometimes it’s a small change that will give a huge win in terms of performance.
As for it being a minor improvement, that’s open to debate. When setting up sequences of LRGB with a flat panel, and maybe darks and bias frames, one target can generate 16 events, even a 2 frame mosaic will benefit from being able to copy those 16 frames quickly.
I do feel that I have to point out that I do understand that this could be a larger project than it would seem to someone that isn’t a software engineer, so I’m not expecting this to be addressed quickly. Hopefully in time, it’ll be worth it. I’d love to be able to setup SGPro to be able to take a long focal length high resolution mosaic of the orion nebula, or the horsehead and surrounding region.
Not a software engineer but I do code, and work in tech- I agree that one has to be super careful about refactoring such a critical part of the workflow. As someone that typically has 20-30 targets each with both LRGB and NB events as well as flats for every one of 'em because I use a rotator… I wouldn’t cry at a series of incremental releases each with a small part of the overall refactoring work. With large numbers of targets/events it does reduce stability/speed somewhat. Honestly I don’t work in the “PC software” space (I’m in cloud services) so I don’t know what you’re faced with, I would just prefer this was prioritized higher than something like INDI functionality.
What I’m talking about in terms of a refactor is something that could happen completely within the code base. There would be no change to the features, or file formats. The only changes that you’d notice would be:
. a marked increase in the amount of targets and events that you can have in a given sequence.
. faster loading of large sequences
. faster copying of events from one target to another - will really benefit when copying to multiple targets.
The doing a refactor of all this code in one go would be a major job and as Jared pointed out, will be high risk. However, there’s normally scope to make some minor tweaks, to be able to get some major gains - this really depends on how the code is implemented.
I’d love to get my hands on the source code to see what I could come up with but something tells me that’s not likely.
but something tells me that’s not likely.