When capturing images, previously once the capture was complete, images were written
to disk, then read back, then displayed in the fits viewer (if enabled), and finally the
next image could be captured. This delayed the next capture by a few seconds.
With this change, the FITS data is displayed using (a copy of) the INDI blob
sent to indiccd, a memory buffer, and the FITS data is written to disk on a separate thread,
which does not block the next capture nor the display of the indi data.
This was only implemented for FITS data. This change also involved some refactoring
in the affected files.
Details
Details
- Reviewers
mutlaqja - Commits
- R321:c72edccbcdd4: Write FITS file on separate thread
Diff Detail
Diff Detail
- Repository
- R321 KStars
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Nice work Hy!
What's the effect on this when capturing from a large sensor? Do we allocable double the memory? Some of these images are many 32MB..etc.
Comment Actions
I tested this with my ASI1600, where the .fits files are 32.8Mb. Works fine.
In fact, it's likely that the larger the file, the more the speedup--as I guess the disk-write would take longer.
The only place where there would be extra memory used is where I do the memcpy in indiccd.cpp:1470.
I wasn't sure I needed to do that, but I didn't think I could rely on the blob memory staying put, so I conservatively
ran the memcpy, and created that buffer that I keep around. That memcpy takes less than 100ms on my RPi4 with Release build.
Comment Actions
memcpy is safer indeed since you cannot guarantee the blob in multi-threaded situations unless you used mutexes.