Why wouldn't an image editor need Vulkan? It's gotta render something somehow.
The software you ran on a 25MHz machine was in all likelihood written in assembly, directly interfacing with the hardware of your machine, without even touching your windowing system (if you even had one, maybe you were running DOS). Modern operating systems frown on that sort of thing with extreme prejudice.
How is Vulkan more portable than a software renderer? And if you need hardware acceleration, OpenGL is more portable than Vulkan.
I would have thought SDL is probably a better target for this type of application. However, I'm happy to see developers use what they like and push the envelope how they like.
Just upgraded to Linux kernel 5.3 and beta mesa & vulkan so I can drop in my rx5700xt, which I still need to do.
The advantage that opengl has is a number of software implementations that can be used as a last ditch on unsupported systems. Efforts for software vulkan implementations are taking a long time to appear.
Wasn't SDL supposed to be that? What happened to that?
Vulkan is just an API for talking to graphics hardware. There are a wide variety of applications which can benefit from using it.
As someone who does graphics programming, I would not choose OpenGL for new projects. For one thing it's the future: while I only expect Vulkan to become more well supported as time goes on, the opposite is happening with OpenGL (see the state of support on Apple platforms). Also the Vulkan API itself actually makes it easier to target more platforms. Because the OpenGL api takes on more responsibility over how the graphics pipeline is executed, there is actually a lot more variation in behavior across driver implementations than you have with Vulkan. This was one of the biggest headaches of OpenGL development which Vulkan has largely solved.
So if I had to choose between losing some users who are using old hardware verses the headaches of supporting an OpenGL application across platforms, along with the fact that OpenGL is actually getting less support over time, the choice would be easy for me.
It's a moot point anyway since the developer here is already using a high-level compatibility library.
In about 2005-2007, count of pixels in displays started to grow much faster than CPU power. FullHD monitors entered mainstream market. CPUs stagnated because laptops stopped being expensive toys and started to become desktop replacement.
Nowadays, with 4k or higher rez monitors even in some laptops, pretty much all software actually needs what Vulkan (or D3D, or GL) offers, just to update screen at 60 Hz.
OpenGL is not portable.
Technically it works on Windows, but that’s only true if you’re happy with 11 years old version of the standard, OpenGL 3.0: https://github.com/Const-me/GL3Windows#building-and-running GPUs have changed dramatically over these 11 years, i.e. that version is way too old.
Technically, OpenGL doesn’t work on majority of ARM devices. They use OpenGL ES, not quite the same thing.
Vulkan works on most of these, with the only exception of Windows devices who have Intel GPUs older than Skylake, i.e. older than 2015.
wgpu-rs has backends for Vulkan, Metal, DX12, DX11, and GL (partial). The primary backends are the lower-level graphics APIs that are in active development: Vulkan, Metal, and DX12.