Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendering performance regression since version 24.3.0 #984

Closed
SmallJoker opened this issue Oct 5, 2024 · 5 comments · Fixed by #1042
Closed

Rendering performance regression since version 24.3.0 #984

SmallJoker opened this issue Oct 5, 2024 · 5 comments · Fixed by #1042
Assignees
Labels
Milestone

Comments

@SmallJoker
Copy link

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
Copy link
Author

SmallJoker commented Oct 5, 2024

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
Copy link
Owner

ra3xdh commented Oct 6, 2024

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 ra3xdh added the bug label Oct 6, 2024
@zergud zergud self-assigned this Oct 11, 2024
@ra3xdh ra3xdh added this to the 24.4.0 milestone Oct 12, 2024
@ra3xdh ra3xdh modified the milestones: 24.4.0, 25.1.0 Oct 28, 2024
@ra3xdh
Copy link
Owner

ra3xdh commented Oct 28, 2024

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

wawuwo added a commit to wawuwo/qucs_s that referenced this issue Nov 3, 2024
@wawuwo
Copy link
Contributor

wawuwo commented Nov 3, 2024

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.

@ra3xdh ra3xdh linked a pull request Nov 4, 2024 that will close this issue
wawuwo added a commit to wawuwo/qucs_s that referenced this issue Nov 4, 2024
@ra3xdh
Copy link
Owner

ra3xdh commented Nov 4, 2024

Fixed by #1042

iwbnwif pushed a commit to iwbnwif/qucs_s that referenced this issue Nov 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants