[PaulDavisThe1st]

Vulkan is a drawing API. Like OpenGL, It does absolutely nothing about the big 4 of (G)UI development:

  * text entry
  * file browsing & selection
  * menus
  * list/tree views

Like OpenGL, it also doesn't even provide an event loop or even an event (user input) layer.

[prewett]

It not even a drawing API, even. It's a 3D triangle rendering API. Things like lines, bezier curves, gradients are all do-it-yourself. None of it super-hard, I've done them all, but before you write your UI you have to write all your drawing routines, which probably wasn't what you wanted to be doing. And you get all the fun texture management issues for any gradients and images you want to display. And you probably won't have optimized it like the platform rendering will have.

And then there's text... You've got to load a texture for every glyph of every point size used in the app for every font used in the app. Mind you, the OS already has a cache for this, but you don't have access to it, so that's more memory wasted. Which would be sizeable if every app on your system was using Japanese, or worse, Chinese, and making a copy of all this stuff.

[afiori]

it isn't the main point of your comment... but why is Chinese worse than Japanese? is it about the font itself being different or about Chinese text containing on average more unique characters?

[prewett]

More characters. I believe there are a mandated 2000 characters that learned in school and used by newspapers. I believe 3000 Chinese characters only gets to 97% and 5000 is still 99.44% [0]

[0] https://lingua.mtsu.edu/chinese-computing/statistics/char/li...

[duckfruit]

This is a very good point that I feel gets overlooked way too often. When people talk about the UI feeling sluggish most of the time they are talking about responsiveness.

Like, who cares if your app is rendering at 120 fps if it takes me 3 seconds to focus on a text field? I feel like that’s where most cross platform tooling has their work cut out.

[lavabiopsy]

Hi Paul, not sure if this an appropriate place to mention this but I hope you please consider at some point using OpenGL or Vulkan to at least render the track view in Ardour. I have a large project with around 50 tracks that is extremely slow and laggy to render when zoomed all the way out, it is making the program unusable for me. I could provide a profile to put in a bug report but I'm not sure the best way to go about that. Thanks.

[PaulDavisThe1st]

We use Cairo for all rendering. Cairo has various backend implementations, and when it gets a Vulkan backend and you're using Ardour on a system with Vulkan available, it will be used.

We're not going to write renderers at a lower level than Cairo at any time in the foreseeable future.

Also, most of the issues with slow rendering are caused by your video interface driver and/or bugs in Cairo that we provide a few workarounds for already. Edit > Preferences > Appearance > Graphics Acceleration has two options ... you need to try all 4 possible combinations to exhaust the possibility that we've already solved the issue you are facing :)

[lavabiopsy]

Thanks for the tips, I will try that and try to get some perf, I am currently compiling Ardour 6.9 :)

On a side note, I don't mean to be the bearer of bad news but I think you need a better plan than this, cairo has been in various states of inactivity and deep maintenance mode over the last several years, if anything more backends will be removed, not added. Also, cairo is an immediate mode-style renderer following the PDF imaging model made for print -- it's fundamentally the wrong approach for high performance rendering. You may not see much improvement even if it did have a Vulkan backend.

[PaulDavisThe1st]

VKVG is a vulkan lib with a cairo-based API. Switching to that wouldn't be that hard if we ever establish a need to do so.