Framerate issue when scaling to whole monitor.

[MylesGit]

It seems when cavalier is widowed it runs at 60fps perfectly but when scaling to my ultrawide it goes to ~15 fps.
This is not a hardware bottleneck, AMD Ryzen 5 3600 and Radeon RX 6700XT utilization within 5% at all times.

Running Fedora 37, Gnome, Wayland.
Video Attached
Screencast from 2023-02-05 15-16-27.webm

[MylesGit]

Would like to add that I've found that clicking off the window sometimes fixes it. Not very consistent.

[fsobolev]

Could you please run the app in a terminal and see if there's any output?
If it's installed using flatpak, use this command:

flatpak run io.github.fsobolev.Cavalier

[MylesGit]

No errors in terminal. I have it set to 50 bars and it seems if too many of them are being used while scaled fully the fps drops. This doesn't happen when it's only covering half the screen though even if the amount of bars is the same.

[MylesGit]

Screencast.from.2023-02-05.15-48-14.webm

[fsobolev]

I guess my eyes are not good enought to see significant fps drop 😅, but anyway, since you see it there should be a problem.
Does the issue persist if you change some settings in Cavalier tab in preferences window?

[MylesGit]

I guess my eyes are not good enought to see significant fps drop sweat_smile, but anyway, since you see it there should be a problem. Does the issue persist if you change some settings in Cavalier tab in preferences window?

I think the gnome video recorder caps fps at 30 or something. I'll try recording with OBS.

[fsobolev]

I think the gnome video recorder caps fps at 30 or something. I'll try recording with OBS.

You can also try Kooha, it allows to set FPS in settings.

[MylesGit]

Just put it in a zip because I already recorded it in mkv format and apparently github doesn't allow it.
2023-02-05 16-07-16.zip

[fsobolev]

on this video framerate is constanctly low, even when window is not maximized. Maybe it's the video framerate. Nvm, really, don't bother recording a video, it's not like you have to proof there's a framedrop, if you say it's there then it's there.
I can't unfortunately reproduce it on my main PC with 1360x768 display, I will later try on another machine with 1080p display.
It would still be useful if you can provide this information:

Does the issue persist if you change some settings in Cavalier tab in preferences window?

I have one idea what can fix it, I will later implement it and send you a flatpak package so you can test it.

[gregorni]

I noticed low framerates in bigger windows as well, but I always thought it was because in a bigger window low framerates are simply more noticeable.

I'm planning on working on some minor performance improvements, but I can't promise anything.

[fsobolev]

@gregorni feel free to commit to framerate-issue branch, I will do some things there

[fsobolev]

I noticed low framerates in bigger windows as well, but I always thought it was because in a bigger window low framerates are simply more noticeable.

Well, with window size the drawing area size increase as well, meaning Cairo has to draw more pixels, and maybe it's not fast enough to draw very high resolution picture at 60fps... But maybe something is slowing it down, so there's hope we can fix it or at least improve the situation.

[MylesGit]

It seemed that the visualizer was very cpu bound in my experience. I think fullscreen gpu usage was 12% at most. It didn't look like it was limitied to a certain amount of threads either, usage was across all threads.

[fsobolev]

It seemed that the visualizer was very cpu bound in my experience.

Yes it is, it uses Cairo for drawing, which uses software rendering, so it's mostly using CPU. Btw what is CPU usage when you get framedrops?

[MylesGit]

It seemed that the visualizer was very cpu bound in my experience.

Yes it is, it uses Cairo for drawing, which uses software rendering, so it's mostly using CPU. Btw what is CPU usage when you get framedrops?

First one is fullscreen.

Second one is minimized.

Going from Minimized to Maximized @ 30 second mark.

Frame drops are consistent when having to draw more pixels. Utilization is all over the place, hard to make it out.

[MylesGit]

I've been messing around with the settings and it seems the number of bars make no difference. If it's fullscreen with 6 bars the frame rate will still drop. Gradients and transparency changes make no difference. Sensitivity and changing channels also doesn't make a difference. But, switching from bars to particles seems to get rid of the fps drop at low bar count. Particles at 50 bars has the same fps drops.

[fsobolev]

Well, guess I need to learn some OpenGL and use Gtk.GLArea instead of Cairo. I don't see any other reason except that Cairo just can't handle it.

[MylesGit]

Well, guess I need to learn some OpenGL and use Gtk.GLArea instead of Cairo. I don't see any other reason except that Cairo just can't handle it.

That's probably the case. I appreciate the app nonetheless and will still be using it every day! Thanks for walking through the issue and believing me when you can't even see the FPS drops, lol. Will be keeping an eye on this issue. If you need someone to test a patch I'm right here.

[gregorni]

Unfortunately, I couldn't find anything that was obviously causing performance hits. The only interesting observation I made was that when switching power profile to high, it seems to run a tiny little bit smoother, but I'm not sure of that.

[fsobolev]

The only interesting observation I made was that when switching power profile to high, it seems to run a tiny little bit smoother, but I'm not sure of that.

It wouldn't be a surprise since power profiles control limits of CPU power, and Cavlalier is heavily utilizing CPU.

Unfortunately, I couldn't find anything that was obviously causing performance hits.

Then I guess 2023.02.x milestone will be now locked in accepting new features, we'll implement what was planned, and in the next release we'll need to work on OpenGL rendering (all the Cairo code will be kept and I will add a hidden setting to enable it in case somebody will have better results with it than with OpenGL for some reasons).

[gregorni]

(all the Cairo code will be kept and I will add a hidden setting to enable it in case somebody will have better results with it than with OpenGL for some reasons)

That's a good idea.

[gregorni]

We can take inspiration from Plots, they're using Gtk.GLArea.

[gregorni]

I tried some stuff with GLArea, and it's incredibly complex. Plots doesn't help me very much. I found this other library, tough, ModernGL, which claims to be nicer to work with as well as faster than straight OpenGL. I'll see what I can do with ModernGL.

[fsobolev]

I tried some stuff with GLArea, and it's incredibly complex. Plots doesn't help me very much. I found this other library, tough, ModernGL, which claims to be nicer to work with as well as faster than straight OpenGL. I'll see what I can do with ModernGL.

Thank you for researching what can be used! Sorry I wasn't active last few weeks, hopefully I will be able to spend time on Cavalier soon. I guess it would be much easier to use some 2D drawing library (or even a small game engine) that will allow us to render to GTKGLArea's GL context, but I doubt something like this exists, so ModernGL seems to be probably one of the best options.

[gregorni]

I think it also said somewhere that ModernGL integrates well with cairo, which would be an advantage as we would have to rewrite less of our existing code.

[gregorni]

Kooha-2023-02-24-15-09-12.webm

Got it to render something, not entirely sure know what.

[gregorni]

cavalier/src/drawing_area.py

Line 63 in ed19387

GObject.timeout_add(1000.0 / 60.0, self.redraw)

@MylesGit Can you try to run the app from GNOME Builder, but change line 63 in src/drawing_area.pyto this:

GObject.timeout_add(1000.0 / 120.0, self.redraw) 

[gregorni]

That raises the target FPS to 120, I'm wondering if the drops won't be as visible then anymore.

[MylesGit]

cavalier/src/drawing_area.py

Line 63 in ed19387

GObject.timeout_add(1000.0 / 60.0, self.redraw)

@MylesGit Can you try to run the app from GNOME Builder, but change line 63 in src/drawing_area.pyto this:

GObject.timeout_add(1000.0 / 120.0, self.redraw) 

Will get back to you in ~1 hour with the results.

[fsobolev]

Unexpected activity here 😄 Well, then I have to make an announcement.
I send a joke in Matrix chat on April 1st that Cavalier is going to be rewritten in Rust... And it was a joke only partially. Cavalier currently is in process of being rewritten in C#. It's not finished yet so it's now in private repo, but as soon as it's ready I will make a full announcement and archive this repo.
New Cavalier uses SkiaSharp instead of Cairo for drawing and it gives better performance so I hope framerate issues will be fixed once and for all. I also implemented FPS switcher (30, 60, 90, 120).

[MylesGit]

That raises the target FPS to 120, I'm wondering if the drops won't be as visible then anymore.

Doesn't resolve the issue sadly. );

[gregorni]

@fsobolev I don't know C#, so I must say I'm not sure if I can help you much after the rewrite. That said, I believe switching to a more performant language might help actually reduce the frame drops a fair bit.

[gregorni]

That raises the target FPS to 120, I'm wondering if the drops won't be as visible then anymore.

Doesn't resolve the issue sadly. );

Oh, darn. Well, it was worth a try.

[fsobolev]

I don't know C#, so I must say I'm not sure if I can help you much after the rewrite.

I will for sure port all work that you've done, including translations :)

I believe switching to a more performant language might help actually reduce the frame drops a fair bit.

I didn't have framedrop issue so I can't really test it, but CPU usage is noticeably lower and SkiaSharp renders to GtkGLArea so I hope it will really perform better for everyone.

[gregorni]

I didn't have framedrop issue so I can't really test it, but CPU usage is noticeably lower and SkiaSharp renders to GtkGLArea so I hope it will really perform better for everyone.

That great!