View Issue Details

IDProjectCategoryView StatusLast Update
0008337ardourbugspublic2020-09-25 09:07
Reporterapoorv569 Assigned Topaul  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionno change required 
PlatformArch LinuxOSGNU/LinuxOS VersionArch Linux
Product Version6.2 
Summary0008337: Hardware acceleration.
DescriptionWhen hardware acceleration is enabled, scrolling through a pretty big project makes it very laggy, disabling it fixes the issue. Either the implementation is not correct or the option description is revered.
TagsNo tags attached.

Activities

paul

2020-07-27 18:19

administrator   ~0024826

It's neither. The problem is that you are running on a version of Linux where using the GPU hardware to render 2D images is slow. Using the GPU ("Hardware Acceleration") is enabled by default. When you disable that option, Ardour stops doing that, and renders the GUI using the CPU. In your case, that speeds things up.

apoorv569

2020-07-27 19:26

reporter   ~0024828

@paul What version of Linux do I need to use Hardware Acceleration?

paul

2020-07-27 20:12

administrator   ~0024830

"version" is probably the wrong term to use.

It's a combination of your video hardware and the video drivers in your kernel. There are no particularly "known bad" combinations from recent years. Going back 10 years, several NVidia devices+drivers were extremely slow to render gradients when used with 2D drawing primitives, but I don't think that's been the case for quite some time now.

apoorv569

2020-07-27 20:56

reporter   ~0024831

@paul is there a minimum requirement? or some hint to check/verify if my hardware is capable or not.

paul

2020-07-27 21:26

administrator   ~0024834

There is no way to determine this without simply trying it. This is not a "at least version N" thing.

You've done the check on your hardware: it is slow when the GPU is used, and fine with the CPU is used.

apoorv569

2020-07-27 23:11

reporter   ~0024835

@paul Is there some way/tool to benchmark my hardware's 2D performance, to make sure its my hardware and not Ardour.

paul

2020-07-28 00:01

administrator   ~0024836

Ardour *is* the benchmark.

We have two entirely codepaths for rendering large parts of the GUI. When you disable H/W acceleration, it uses one of the code paths; when have it is enabled, ardour uses the other.

You've seen the results.

It's sort of meaningless to say "and not Ardour" ... Ardour is just another program that uses various libraries to draw stuff on your screen. We provided that option because we came across several instances of systems where relying on the GPU for drawing made things slow. We discovered that doing drawing a different way got rid of the problem. Hence the option.

(the other code path was also required for macOS, which for entirely different reasons can also be spectacularly slow at rendering certain things in 2D)

apoorv569

2020-07-28 06:08

reporter   ~0024837

@paul Don't mean to be rude but saying its just my bad luck is not a good answer, I want to know what is so complicated about Ardour's hardware acceleration implementation, than other softwares/DAW's, no other DAW, gives me any problem what so ever, even when running with wine.

paul

2020-07-28 15:49

administrator   ~0024840

well, whether you mean to be rude or not ... i can't explain this to you in any more detail unless you're a programmer.

i can say this ... it is not "Ardour's h/w acceleration implementation". we use a library called Cairo for 2D drawing (which has been under consideration as a new language standard for this in the C language, though less so these days). Ardour doesn't do any funny stuff - it just asks Cairo to draw shapes, fill in areas, stroke gradients etc. The version of Cairo that Ardour is linked to on your machine interacts "badly" with the video driver on your machine.

I had a machine a few years ago with an NVidia card, and the same combination would completely screw up gradient drawing.

I know that you are frustrated by this, but there's no extra information I can give you - Cairo drawing using your GPU is slow. That's the story. There's likely no other DAW that uses Cairo that you have used, and there's likely no other software on your system that uses Cairo quite as intensively as we do.

Tremeschin

2020-07-28 21:51

reporter   ~0024842

@apoorv569 Do you compile Ardour with optimizations?

I personally do "python2 waf configure -j 6 -p --optimize --cxx11" and "python2 waf build -j 6 -p" on a sh script that pulls the repo and compiles it.

I remember it was heck lot of slow like you said on a big project, until I added that --optimize flag on the waf then it became butter smooth afterwards.

paul

2020-07-29 00:37

administrator   ~0024843

Those flags will make no difference for this particular issue, since it's the interaction between Cairo and the video driver (and/or the X Window libraries) that is where the problem happens.

Building with optimization is still a good idea for any production version of Ardour.

Tremeschin

2020-07-29 01:16

reporter   ~0024844

Interesting @paul, I remember very clearly when I used Ardour without --optimize flag on a crap laptop before rescuing my main rig from another city the whole UX, UI and DSP loads got so much better after compiling with optimizations, it didn't lag as much ( tho this could've been placebo as you said :p )

Welp, it's worth a shot I guess

paul

2020-07-29 02:58

administrator   ~0024845

Optimization will produce *substantial* improvements in performance, no question (that's why all the ardour.org release builds are optimized).

But it won't do anything about "cairo drawing with this video driver/card is slow".

apoorv569

2020-07-29 08:00

reporter   ~0024846

@paul Thank you for explaining, I have a curious mind, if I don't understand the logic behind something, its not enough for me. Its not the whole story you told me, but at least I understand what is going on.

apoorv569

2020-07-29 08:02

reporter   ~0024847

@Tremeschin I have Ardour downloaded from my Arch repo, but I can try building it with the flags you mentioned.

Tremeschin

2020-07-31 06:30

reporter   ~0024866

@apoorv569 Can you try running Ardour with the environmental var ARDOUR_IMAGE_SURFACE=1 from the shell like so:

$ ARDOUR_IMAGE_SURFACE=1 ardour6

I installed ardour from arch repos just for testing and it was darn slow as you said.

Found out I ran Ardour compiled locally with that flag all along and without it the graphics performance is just plain bad.

x42

2020-07-31 07:18

administrator   ~0024867

@Tremeschin Preferences > Appearance > "Disable Graphics Hardware Acceleration (requires restart)" sets "ARDOUR_IMAGE_SURFACE".

A lot of ATI/ Radeon Cards have poor 2D-graphics performance (they're optimized for 3D), and since the issue became more widespread the config option was added (the environment variable still works for backward compatibility). Either enables software rendering on the CPU, instead of 2d accelerated hardware rendering.

As @paul already mentioned this can also help with poor nvidia hardware -- however the "buggy gradient" option is Prefs > Appearance > "Possibly improve slow graphical performance (requires restart)" is usually more relevant for those.

x42

2020-07-31 07:19

administrator   ~0024868

PS. The "Possibly improve slow graphical performance (requires restart)" preference is likely not available from distro-builds (since that requires patching cairo, which most distros don't do).

apoorv569

2020-07-31 07:39

reporter   ~0024870

@Tresmeschin I tried what said
$ ARDOUR_IMAGE_SURFACE=1 ardour6
it does improve the performance a lot.

@x42 So $ ARDOUR_IMAGE_SURFACE=1 ardour6, and disabling the graphics hardware acceleration is the same thing?

Prefs > Appearance > "Possibly improve slow graphical performance, I don't have this option? I have downloaded from the Arch repos, and my GPU is NVIDIA GTK 1060 3GB.

apoorv569

2020-07-31 07:41

reporter   ~0024871

@Tremeschin I tried what you said

anonymous

2020-09-25 09:07

viewer   ~0025054

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2020-07-27 09:06 apoorv569 New Issue
2020-07-27 18:19 paul Note Added: 0024826
2020-07-27 18:19 paul Assigned To => paul
2020-07-27 18:19 paul Status new => resolved
2020-07-27 18:19 paul Resolution open => no change required
2020-07-27 19:26 apoorv569 Note Added: 0024828
2020-07-27 20:12 paul Note Added: 0024830
2020-07-27 20:56 apoorv569 Note Added: 0024831
2020-07-27 21:26 paul Note Added: 0024834
2020-07-27 23:11 apoorv569 Note Added: 0024835
2020-07-28 00:01 paul Note Added: 0024836
2020-07-28 06:08 apoorv569 Note Added: 0024837
2020-07-28 15:49 paul Note Added: 0024840
2020-07-28 21:51 Tremeschin Note Added: 0024842
2020-07-29 00:37 paul Note Added: 0024843
2020-07-29 01:16 Tremeschin Note Added: 0024844
2020-07-29 02:58 paul Note Added: 0024845
2020-07-29 08:00 apoorv569 Note Added: 0024846
2020-07-29 08:02 apoorv569 Note Added: 0024847
2020-07-31 06:30 Tremeschin Note Added: 0024866
2020-07-31 07:18 x42 Note Added: 0024867
2020-07-31 07:19 x42 Note Added: 0024868
2020-07-31 07:39 apoorv569 Note Added: 0024870
2020-07-31 07:41 apoorv569 Note Added: 0024871
2020-09-25 09:07 anonymous Note Added: 0025054
2020-09-25 09:07 anonymous Status resolved => closed