So we're like 9 devs at u-he, plus a few external forces. 3 or so are sometimes involved with Linux. I myself have not laid hands on a Linux system since last millennium when I tried to run Linux on a PowerPC Mac.
The original port was done by Abique. The work consisted mostly of adapting a graphics library to our framework, opening files and maintaining a window and some widgets. It's no small feat, maybe about the same complexity as supporting a different plug-in format.
Afaik the main issue with Linux is the different windowing systems and distributions. Also some features that our framework takes for granted are not guaranteed or available in Linux, such as context menus that always work (depend on whatever the host uses), timers in the user thread, such things.
Our stance is that we want to support it, but when it comes to vital business decisions, it must not stall Win and Mac development. Therefore, sometimes when we have hard to resolve bugs on Linux, a Linux version might be delayed.
Zebra 3 and Zebra Legacy
-
- u-he
- Topic Starter
- 30186 posts since 8 Aug, 2002 from Berlin
-
- u-he
- Topic Starter
- 30186 posts since 8 Aug, 2002 from Berlin
-
- KVRAF
- 1592 posts since 19 Aug, 2009
Quite interesting info, thanksUrs wrote: Wed Nov 05, 2025 11:02 pm So we're like 9 devs at u-he, plus a few external forces. 3 or so are sometimes involved with Linux. I myself have not laid hands on a Linux system since last millennium when I tried to run Linux on a PowerPC Mac.
The original port was done by Abique. The work consisted mostly of adapting a graphics library to our framework, opening files and maintaining a window and some widgets. It's no small feat, maybe about the same complexity as supporting a different plug-in format.
Afaik the main issue with Linux is the different windowing systems and distributions. Also some features that our framework takes for granted are not guaranteed or available in Linux, such as context menus that always work (depend on whatever the host uses), timers in the user thread, such things.
Our stance is that we want to support it, but when it comes to vital business decisions, it must not stall Win and Mac development. Therefore, sometimes when we have hard to resolve bugs on Linux, a Linux version might be delayed.
I actually thought that at this time most frameworks are already cross compatible with Linux, I guess I was quite wrong
Anyway, thanks for supporting Linux
-
- KVRian
- 759 posts since 13 Apr, 2017
I've always believed there should be a dedicated multimedia distribution that is optmized for such workloads. Drivers and applications. It would be much easier and realistic to support something like that.Urs wrote: Wed Nov 05, 2025 11:02 pm Afaik the main issue with Linux is the different windowing systems and distributions.
Just imagine a company like RME provides a low latency driver. That would be a pretty good foundation.
-
- u-he
- Topic Starter
- 30186 posts since 8 Aug, 2002 from Berlin
Well, one thing to think about is that we have our own framework. It abstracts a very minimal set of things for the UI and for the platform. On Mac this is native, it uses CoreGraphics and - ever since Boost became a thing - it uses boost::filesystem (it used to use FSRefs... OMG).
On Windows we use a super lean layer that blits a bitmap onto the screen. But in-between we kind of rebuilt CoreGraphics with a framework called AGG (recommended by Michael from reFX back then). However, during the past 10 or so years I have come up with faster algorithms for almost anything it does, so it's almost absolutely replaced by our own stuff. So we do all the bitmap blending, all the path rendering ourselves except for the font rendering.
On Linux we use something called Cairo as an in-between layer. Like AGG it is a pretty dead platform, but on Linux it does everything.
Eventually we will replace both Win and Linux rendering with something hardware accelerated. But these things come and go. We have to take a proper look and make it a thing once we got Z3 out.
On Windows we use a super lean layer that blits a bitmap onto the screen. But in-between we kind of rebuilt CoreGraphics with a framework called AGG (recommended by Michael from reFX back then). However, during the past 10 or so years I have come up with faster algorithms for almost anything it does, so it's almost absolutely replaced by our own stuff. So we do all the bitmap blending, all the path rendering ourselves except for the font rendering.
On Linux we use something called Cairo as an in-between layer. Like AGG it is a pretty dead platform, but on Linux it does everything.
Eventually we will replace both Win and Linux rendering with something hardware accelerated. But these things come and go. We have to take a proper look and make it a thing once we got Z3 out.
-
- KVRAF
- 1592 posts since 19 Aug, 2009
IIRC Bitwig replaced Cairo with Skia a few versions ago. Maybe it is worth a look.Urs wrote: Thu Nov 06, 2025 10:27 pm
On Linux we use something called Cairo as an in-between layer. Like AGG it is a pretty dead platform, but on Linux it does everything.
Eventually we will replace both Win and Linux rendering with something hardware accelerated. But these things come and go. We have to take a proper look and make it a thing once we got Z3 out.
https://skia.org/
-
- u-he
- Topic Starter
- 30186 posts since 8 Aug, 2002 from Berlin
Yeah... as you know, Bitwig and we are close. We know about it, and we also know how hard it was.
Things like Skia are catering for application level. But we are doing plug-ins. It doesn't work the same way, there may be conflicts when multiple plug-ins use the same framework.
For some perspective, we co-sponsored and co-developed a project to do a fully working CLAP example project based on Dear IMGUI, which uses GLFW. It was a nightmare. Those things are not designed to be used in plug-ins where the main process uses this or that, and the plug-in uses something else. We ended up replacing GLFW with direct support for Metal and, hm, was it Vulcan?
We have to be slightly old fashioned in that way, and try to avoid dependencies that may clash with the rest of the hosting environment (host or other plug-ins). On Windows we're probably going to go for trusty old Direct-Something. On Linux we have to see. I think the points is, we'll refactor our stuff to support multiple things on each platform.
Things like Skia are catering for application level. But we are doing plug-ins. It doesn't work the same way, there may be conflicts when multiple plug-ins use the same framework.
For some perspective, we co-sponsored and co-developed a project to do a fully working CLAP example project based on Dear IMGUI, which uses GLFW. It was a nightmare. Those things are not designed to be used in plug-ins where the main process uses this or that, and the plug-in uses something else. We ended up replacing GLFW with direct support for Metal and, hm, was it Vulcan?
We have to be slightly old fashioned in that way, and try to avoid dependencies that may clash with the rest of the hosting environment (host or other plug-ins). On Windows we're probably going to go for trusty old Direct-Something. On Linux we have to see. I think the points is, we'll refactor our stuff to support multiple things on each platform.
-
- KVRian
- 671 posts since 11 Apr, 2006
You might consider Blend2D. I'm using it in a few UI projects, including stuff that runs as plug-ins. It's all CPU side, so no weird problems caused by dealing with GPU contexts if you don't want to. It's easy to build and integrate into a project. It's a lot faster than AGG and Cairo, about the same speed as Skia (or faster?) and a lot easier to build and integrate than Skia.
I was wondering about the story of those in the CLAP examples projects.Urs wrote: Thu Nov 06, 2025 11:14 pm For some perspective, we co-sponsored and co-developed a project to do a fully working CLAP example project based on Dear IMGUI, which uses GLFW. It was a nightmare.
-
- u-he
- Topic Starter
- 30186 posts since 8 Aug, 2002 from Berlin
-
- KVRian
- 671 posts since 11 Apr, 2006
Yeah What I do in one of my projects is use Blend2D to draw rasterized paths/shapes, text, images etc. to textures, then store them on the GPU to repeatedly composite them together for the final drawn image. (Example, draw knobs and buttons in different configurations to array of textures, then display them in the final UI using GPU.) Allows for fast animation, without using a lot of CPU time just to copy pixels each redraw, but you also don't have to go too deep into the specific GPU APIs on each platform in order to get consistent behavior. (Exception is drawing anti-aliased lines for graphs and stuff.)
This one in particular is an unfinished project so don't take it too seriously
I know some others do it this way, too, though. (FL Studio?)
What I do in one of my projects is use Blend2D to draw rasterized paths/shapes, text, images etc. to textures, then store them on the GPU to repeatedly composite them together for the final drawn image. (Example, draw knobs and buttons in different configurations to array of textures, then display them in the final UI using GPU.) Allows for fast animation, without using a lot of CPU time just to copy pixels each redraw, but you also don't have to go too deep into the specific GPU APIs on each platform in order to get consistent behavior. (Exception is drawing anti-aliased lines for graphs and stuff.)This one in particular is an unfinished project so don't take it too seriously
I know some others do it this way, too, though. (FL Studio?)-
- KVRAF
- 2673 posts since 18 Mar, 2006 from The Void
I guess WebGPU (wgpu) is not suitable ? I'm not going to dive into work topics though. I just want Zebra 3 to be as awesome as it seems, and not suffer any GTA6-style delays.
I would love linux-native everything, but that's why I keep a Mac for music. One day, maybe.
I have faith in Urs as history shows the right decisions are made.
I would love linux-native everything, but that's why I keep a Mac for music. One day, maybe.
I have faith in Urs as history shows the right decisions are made.