If I let the waveform view run for a just a few minutes with 2MHz sample rate, the visual update rate of the view drops to about once per second. It’s not only the waveform view that is affected, though, as interacting with the menus is also affected. When I can eventually access the menu, doing View→Manage, and hitting the reset button for Oscilloscope fixes the update rate for some time, but it will eventually slow down like it had before. If I reduce the sample rate, the issue will still occur, but takes longer. I’m not trying to write any logs when this occurs (saw that mentioned as a potential slow down source).
Watching Task Manager while hitting the reset button, I see memory usage for Joulescope drop by 1GB. Doing so successively each time the issue occurs does not bring the memory usage down to any particular base level - there always seems to be some remnant memory usage (ex: first reset went from 2.2GB down to 1.2GB; next reset went from 2.8GB down to 1.4GB).
I don’t know Python, but my assumption is that there are old waveform view-related objects that should have been removed with garbage collection that are sticking around and are still being iterated through as part of a screen update process and hitting that reset button force-kills all of them.
I could not find this topic brought up previously, so I suspect its something specific to my setup, but I’m not sure how.
From the Joulescope About screen:
Version Information:
UI:1.3.6
driver: 1.9.4
JLS: 0.15.0
Python: 3.12.10 (tags/v3.12.10:0cc8128, Apr 8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)]
Platform: Windows-11-10.0.26100-SP0
Processor: Intel64 Family 6 Model 165 Stepping 2, GenuineIntel
The only known Waveform performance issue is #316, but that is for Linux Wayland only. We have had numerous performance issues with Windows computers that have Intel-only graphics, especially for older Intel CPUs.
Do you care about your existing UI configuration? If not, can you clear it. Here is how:
Start the Joulescope UI
Select File → Clear config and exit
Start the Joulescope UI
Then switch over to View → Oscilloscope.
Do you still observe the same behavior?
If so, can you submit an issue report? Select Help → Report Issue. Please include the URL of this post in the issue report. Thanks!
Posted via Report Issue, copying here for resolution tracking for others who run into it:
I've updated to 1.4.1, cleared config, and am still getting the waveform view issue. In fact, as I type in this box, the text output is being lagged while the waveform is trying to update.
OpenGL is set to "autodetect". Earlier today, I did try changing options just to see what happens:
* desktop and ANGLE appear to work the same as "autodetect".
* software had a lower fps and I didn't let it run long enough to know if it exhibits this same lagging issue.
I am not using Intel graphics - it should be showing up as an nVidia card (3000 series?)
I also apologize for my delay in response to the forum post - it wasn't until now that I was back to needing to capture data with the Joulescope.
(I'm assuming a log will be included when I hit Submit, but if it isn't, let me know)
For this issue (and log), I did the following steps:
1. Started Joulescope.
2. Cleared config and exit.
3. Started Joulescope.
4. View->Oscilloscope.
5. Turned on "p" signal view at some point.
5. Let more than 10 minutes go by (at 2MHz sampling), mostly in the background while I did other work.
6. View->Manage.
7. Reset the waveform. OK.
8. Turn on "p" signal again at some point.
9. Let it go for another 10 minutes or so (again, background)).
10. Stopped the capture.
11. Started the capture.
12. Let run for 10 or more minutes (background).
13. Started this issue submission all while experiencing lag in the waveform and this text box entry.
@mliberty suggested the issue might be with the nVidia OpenGL driver and that I try swapping to the software renderer (also to change the waveform Min/Max setting to lines).
I am happy to report that this did resolve my issue, so I agree this does seem to be an issue with nVidia’s OpenGL driver.
For others, the reason to switch to lines is as an FPS improvement. You could keep it as the default fill 2, but the FPS would be degraded (but not laggy as it was for me when using the hardware renderer).
I have a simlar issue with an nvidia graphics card and wayland… the waveform display is performant enough but does have “hiccups” with intermediary black screens.