Rendering performance regression since version 24.3.0

[SmallJoker]

Thanks to the recent hotkey fix, I eventually updated Quc-S and noticed that scrolling the circuit area suffers from a very noticeable performance drop.

This issue appears to be caused by more inefficient rendering of many data points. In my case, when working with the sample circuit [1], any interaction inside the circuit area is now delayed by about 200 - 300 ms (during which an entire CPU core is 100% busy). There used to be no such delay in older versions.

Reproduced on:

• Ubuntu 22.04, Polaris series GPU (amdgpu), X11

Last known good: 24.2.1

• On Linux AppImage: the main process is labelled "Qt Client Leader Window". No AppRun process seen.
• On Linux + Win64 (Wine 9.17): the main process is labelled "qucs-s 24.2.1"

First known bad: 24.3.0

• On Linux AppImage: the main process is labelled "AppRun.wrapped". No Qt process seen.
• On Linux + Win64 (Wine 9.17): the main process is labelled "qucs-s 24.3-881d2a4"

Reproduction steps:

1. Open the sample [1]
2. Scroll up and down in the circuit area (mouse wheel or scrollbar, or resize the window)
3. Monitor the CPU usage

I hope you can reproduce this as well. Otherwise I'll try to profile the provided binaries somehow.

[1] sample-circuit.tar.gz

[SmallJoker]

Extracted the AppImages and ran

1. valgrind --tool=callgrind ./qucs-s
2. gprof2dot -s -n 5 -f callgrind callgrind.out.PROCID | dot -Tsvg -o output.svg (<5% is ignored)

For version 24.3.0 (first known bad):

• SVG: output
• If 0x00000000003b0f20 is responsible for updating the canvas, then it's 8 frame updates for this testing period.

For version 24.2.1 (last known good):

• SVG: output_24 2 1
• If 0x00000000002df020 is responsible for updating the canvas, then it's 7 frame updates for this testing period.

Notes:

1. Apparently an update from Qt5 to Qt6 happened during this time.
2. QRasterPaintEngine::stroke is now called WAY more often as compared to 24.2.1, called by QRasterPaintEngine::drawRects. Could the line drawing mechanism have changed for the worse?

[ra3xdh]

I confirm the problem. I have some freezing on my machine but not critical. My configuration is Arch(Manjaro)+Wayland+IntelUHD This is surely not related to Qt6 migration. It seems it has appeared after #723 where plotting engine was redesigned. @wawuwo Could you have a look?

The large datasets always had problems in Qucs. The advise will be to avoid such datasets by setting TRAN duration and step. The MinStep property of TRAN has no effect for SPICE. This may be controlled by some .OPTION.

[ra3xdh]

We are working on the solution. The fix is expected in v25.1.0

[wawuwo]

Hi guys! First of all, I am so sorry for the late reply. Please don't go hard on me.

I believe poor rendering performance of graphs has little to do with #723, but it's mostly due to bad design and inefficient algorithms. For example, all datapoints are being traversed every time a graph is drawn even if only a portion of it is visible at the moment. Another problem is that every datapoint is still rendered even when scale is so small that multiple datapoints are mapped to a single pixel.

I've made a quick patch addressing the latter problem (please take a look at PR #1042), I believe it can help until the proper solution emerges. I tried it on my machine with the sample circuit from the above and the app performed evidently better than without the patch, so I ask you to try it out too :) Hope it will help you.