SharpCap 4.1.10652.0 interface update very slow

[admin]

Hi,

that's a good question... I got it after running through various mosaic tests and the mosaic tool uses the sequencing engine behind the scenes, so that could be related.

For today's update (presuming I get it done today... still need to go through any new bug reports), I have added a 'Performance' option in the additional logging options. When this is turned on, SharpCap will log some performance related info about every 5 seconds. If we can catch the problem happening with the performance logging turned on then hopefully we will be able to see some change in the performance info in the log at the point that the problem starts. That will let us pinpoint exactly when the problem started (and maybe see other log info nearby that could have been related to the cause). Also it's possible that the performance data change will point to some area of the code that is likely to be the cause.

The performance info that will be logged includes

* Data on the timings of a frame flowing through the program from camera to screen - basically how long it takes to get to each new stage of processing
* Data on how fast frames are being processed and what the typical, minimum and maximum gaps between frames are
* Data on the CPU load level of the PC and also info on whether SharpCap is artificially limiting the rate at which the screen is updated to try to reduce CPU load

cheers,

Robin

[lowenthalm]

The screen view seems to be updated when this occurs, at least I think. The live single frames are, switching between stacked and single frame works immediately, but its possible that the stacked view image that is displayed is several frames back - this isn't obvious without close inspection. The major symptom is that a lot of the histogram and status panels in live-stack seem to take a coffee/tea break. So I fear a pipeline timing log might not detect this behavior in the interface.

[admin]

Hi,

yes, this may only be 'stage 1 or many' of extra diagnostics to try to work out what is going on...

If the histogram and live stacking are failing to update then (broadly speaking) there are two causes

1) There are no updates because they are not receiving or processing new data - the frame flow timings would spot this

2) New data is being calculated, but the display is not being updates. I'm struggling to work out how this could happen for some areas of the application and not others - it should be an all-or-nothing thing. For that reason I'm concentrating on option 1 for now.

cheers,

Robin

[kaymann]

Well I am really sad to report I have joined this crowd... For me it was instantaneous with starting my SC with my ZWO ASI533MC Pro. I was using Beta 4.1.10652. I was taking .SER's of Venus. It was every bit of the GUI that was slow. I restarted my laptop and got no better response so to conserve time I killed beta and went to 4.0 and got back to good GUI response. This morning I downloaded 4.1.10700 and will try to the exact same procedure and see if I run into the same problem... I will update tonight.

[admin]

Hi,

a couple of questions on your setup

1) Do you use remote desktop or were you working directly on the keyboard/mouse/monitor of the PC?
2) What version of 4.0 do you have? By knowing the version I at least have some idea of versions that worked reliably.

cheers,

Robin

[kaymann]

1) I use RDP (Native Windows RDP)
2) SC 4.0.9556 All my versions are 64 bit
3) Zero Delay when no camera is connected for either beta or delta.

Last night was too windy so I hooked everything up and started a capture of the lens cap and noticed only a slight GUI delay with your latest Beta 4.1.10700

Randall

[admin]

Hi Randall,

thanks for the info - I did make a change in 4.1.10523 to always switch to software rendering for remote desktop, which I have undone with 4.1.10700. The switch to software rendering was based on me hitting some issues with remote desktop that looked like they were related to the acceleration option being on, but it's possible that the 'cure' for those was worse than the problem it was curing.

Let's see how 4.1.10700 works for others and if it shows any improvements.

Robin

[lowenthalm]

Happened to me again in the latest version. I have been debugging sequences - so lots of stopping, editing and restarting sequences.

I stacked an entire 72 sub live-stack with the data from close to the end of the PREVIOUS 72 sub live stack stuck in the interface. The stacking, alignment and histogram tab never updated. The Filter (FWHM), Filter (brightness) and Drift graph tabs all update normally.

I grabbed the log, but don't see any obvious pipeline timing debug info, other than the frame capture time (see below). Do I have to turn this on somewhere? Or perhaps the lack of timing debug output is a clue!

....
Debug 03:08:15.114050 #31 Starting ZWO Exposure of 6000ms in bool SharpCap.Cameras.ASI.ASICameraProxy.StartExposure()
Debug 03:08:21.486953 #31 Finished ZWO Exposure of 6000ms, gotFrame = True in bool SharpCap.Cameras.ASI.ASICameraProxy.GetFrameData(int timeout, BufferFrame frame, CancellationToken cancellationToken)
Debug 03:08:21.489494 #31 Starting ZWO Exposure of 6000ms in bool SharpCap.Cameras.ASI.ASICameraProxy.StartExposure()
Debug 03:08:27.841614 #31 Finished ZWO Exposure of 6000ms, gotFrame = True in bool SharpCap.Cameras.ASI.ASICameraProxy.GetFrameData(int timeout, BufferFrame frame, CancellationToken cancellationToken)
....

[admin]

Hi,

yes, the timing is an option that you have to turn on in the 'Logging' page of the SharpCap settings. Not the sort of thing that I want to turn on by default, since it will make the log much larger and may affect performance a bit, so not everyone wants it.

Still the data point that it is still there in 10700 is useful.

cheers,

Robin

[kaymann]

I am happy to report that last night 2023-06-11 & 12 using 4.1.10700 while capturing a comparison super nova photo the interface could have been described as snappy!

Thank you Dr Glover, it was a pleasure to work with!

Randall