SharpCap 4.1.10652.0 interface update very slow

[lowenthalm]

I have observed a lot of lagging in the interface updating in that last few Sharpcap 4.1 betas. It seems to be getting worse when I switched from SharpCapInstall-4.1.10609.0 to the latest update.

Live Stacking frame count lags very far behind the actual count (in the main live stack panel and in the status tab). Sometimes it doesn't update for dozens of stacked 6 second frames. The image viewer interface seems to always update. FWHM and brightness panels seem to update with every frame however. Drift tab mostly does, I think.

I also noticed that the focuser in and out buttons (in the main camera control panel) seems to also sometimes get stuck in a disabled (dimmed) state after clicking on them to move the focus a bit. If I wait for a bit, the buttons eventually re-enable so I can click on them again. This might be a totally different problem. This is using the CPWI ASCOM focuser drivers.

I am using Parallels on a Mac, but I suspect this is unrelated. Never seen a problem like this before in SharpCap, and it seems be growing worse from beta release to release. I will double check tonight to see if I see this in v4.0 and also see if I can repeat the behavior in 4.1. It may have been growing worse over the course of the evening last night (I don't think I noticed it the first hour or two), so maybe there is a memory leak or other internal resource management issue causing some things to slow down to a crawl as session progresses.

[admin]

Hi,

one thing worth checking is the status of the 'use hardware acceleration' option in the first page of the settings. Under some circumstances, SharpCap will turn that off if there is a crash that looks to have been caused by the hardware acceleration. That may have happened, so maybe turning it back on would help.

Another thing I have noticed recently (and not had time to fully investigate yet) is a similar sort of lagging when using remote desktop and applying a strong stretch to an otherwise dark image. The strong stretch produces a very noisy image for display, and that will not compress well (at least that's my theory), leading to slow updates over remote desktop.

cheers,

Robin

[lowenthalm]

Image rendering to screen is unaffected. Just a few of the control panels. I couldn't reproduce in SharpCap 4.0 or 4.1 last night. Also ran 4.1 for several hours and did not see a recurrence.

If it happens again, I will investigate to see if hardware acceleration has been turned off next time. Is this the "Use Graphics Card acceleration to improve display performance" in the general settings tab? Are you thinking this has been temporarily turned off until Sharpcap is quit and then restarted and that I should see this checkbox unchecked? I am presuming that just quitting and restarting Sharpcap clears the problem, since that is effectively what I did. I just didn't start SharpCap again until the next evening!

[admin]

Hi,

ideally you should have the checkbox for graphics card acceleration ticked, as it moves a fair bit of the work of the display onto the GPU rather than the CPU. However, some graphics card drivers (particularly if they have never been updated) have bugs that cause freezes and crashes when the acceleration is turned on. If SharpCap detects a freeze or crash that is being caused by this then it automatically turns the option off. What should happen then is that the next time you start SharpCap (and all other times afterwards) it will open without acceleration, which avoids repeated crashes/freezes. On the other hand, a single glitch of a similar type (even if very rare) can trigger this mechanism leading to acceleration being turned off.

cheers,

Robin

[lowenthalm]

OK. When I checked, there was no change in the state of this checkbox. Didn't have any issues last night during a 6 hour run. Previously I had seen the live-stacking count lagging by a few frames for periods and assumed it was an issue by debugging code and not an actual problem so didn't report it. I have had only this one occurrence when live stacking started lagging by several dozen of frames (this happened for the entire last half of a several hour session).

If I see a really bad case of interface occur again, I will try to diagnose it further.

[lowenthalm]

It happened again after a few hours of operations while running live stacking in a sequence.

The following panels did not update properly - in fact, they actually did't clear the old data when a live stack auto-saved and then reset for a another stack! It took would usually update to the new live-stack status a couple of dozen frames in.

The live-stack panels that WERE NOT updated (all exhibiting the same amount of lag) were:
live stacking main panel (frames, rejected, total exposure)
Status tab
Histogram (it actually showed data from the previous stack after a live-stack clear!)
I am unsure if Alignment and Stacking tab were being updated - forgot those had frame by frame data.

The following tabs WERE updated properly after each captured frame during this anomaly:
Filter (FWHM)
Filter (Brightness)
Drift graph
Screen view (which update properly when the View popup menu was used to switch between the single frame view and stack view.)
That status bar at the bottom of the screen also showed the correct current number stacked and ignored frames, so I could compare this to the other controls displays that weren't being updated.

After the sequence was completed, I manually ran live-stacking and saw that all this same behavior continued.

Memory showed 4 of 275 frames used, so no memory issues and disk space was >120gb. The graphics card acceleration was still enabled in settings.

I have attached the portion of the log after 2a. I noticed this behavior had started sometime by sometime between 2:30a and 3:00a. I stopped imaging around 3:20. The behavior persisted until the end of the session.

[admin]

Hi,

thanks for keeping looking at this. I encountered something similar last night myself where images from the camera were obviously being delayed by several seconds (I was imaging the moon and the changes I was making to gain/exposure were taking several seconds to appear). Everything else seemed responsive as far as I could tell. Closing and re-opening SharpCap cleared my issue.

Based on what I saw and your description, my suspicion is that there is somehow a bottleneck happening in the frame processing flow which goes from camera, through any active tools like live stacking and then to the screen, although that doesn't quite fit with how you had parts of the live stacking UI updating and parts not.

There is no 'smoking gun' in the log you uploaded - at least at a first run through. I am thinking that I may have to add new logging that will track the progress of each frame through the program, so that it is possible to add info to the log if the frame is delayed by more than (say) 1s before it makes it to the screen. It's also possible that the issue could be to do with CPU load rising for some reason to the level that means that SharpCap can no longer keep up with the work needed. Again I can start logging some of this info.

Ideally the changes above will get us to the point that when it does happen there will be some info in the log that relates directly to the problem *and* that might help narrow down the range of possible causes.

Unfortunately this may take some time to track down, but we should get there!

cheers,

Robin

[DrBobAZ]

The following panels did not update properly - in fact, they actually did't clear the old data when a live stack auto-saved and then reset for a another stack! It took would usually update to the new live-stack status a couple of dozen frames in.

The live-stack panels that WERE NOT updated (all exhibiting the same amount of lag) were:
live stacking main panel (frames, rejected, total exposure)
Status tab
Histogram (it actually showed data from the previous stack after a live-stack clear!)
I am unsure if Alignment and Stacking tab were being updated - forgot those had frame by frame data.

The following tabs WERE updated properly after each captured frame during this anomaly:
Filter (FWHM)
Filter (Brightness)
Drift graph
Screen view (which update properly when the View popup menu was used to switch between the single frame view and stack view.)
That status bar at the bottom of the screen also showed the correct current number stacked and ignored frames, so I could compare this to the other controls displays that weren't being updated.

After the sequence was completed, I manually ran live-stacking and saw that all this same behavior continued.

Memory showed 4 of 275 frames used, so no memory issues and disk space was >120gb. The graphics card acceleration was still enabled in settings.

My experience is identical to yours. And it only occurs after being in the session for an hour or so, I am not using a dedicated graphics card, its all on motherboard.

Bob

[admin]

Hi folks,

thanks for this. If anyone happens to find a way to make the slowdown appear 'on demand' then please let me know. If I have a series of steps that I can use to make it happen then it makes understanding and fixing the issue much faster.

In the absence of a set of 'make it happen' steps, any info on what you were doing when the problem happened is still welcome - sometimes you collect enough of that sort of info and a pattern appears.

cheers,

Robin

[lowenthalm]

I am running all my live stacking in sequencer programs. There are times when I cancel the sequence as I don't want run as many loops in the sequence as I planned. It might be possible that a cancelling a sequence leaves something in a bad state that causes the slow-down. Has anyone seen this interface slow down problem without ever running a sequence?