
Krita, OpenGL and Qt - todsacerdoti
https://valdyas.org/fading/hacking/krita-hacking/krita-opengl-and-qt/
======
esperent
> So at some point, the engine stopped working on macOS. Mostly because Apple
> doesn’t want people to use OpenGL, so they’re starving their drivers from
> development

As a graphics developer, all I can say is... sigh. Apple has fought against
open standards in graphics. They never overtly move against open standards
(that I'm aware of) instead they use their dominant platform and refuse to or
drag their heels in implementing support for open APIs.

Even though there's a new era of cross platform graphics APIs in Metal,
WebGPU, and Vulkan, the fight has now moved onto formats, as everyone except
Apple work towards open formats like WebP, glTF, basis universal (fortunately
they can't avoid that last one), while Apple announces they'll use USDZ
instead, or not add support for WebP.

~~~
formerly_proven
If you want to implement an OpenFX [1] effect properly you have to write its
core _four_ times:

\- A CUDA implementation, if the host uses CUDA

\- A Metal implementation, for Apple

\- An OpenCL implementation

\- A fallback CPU-based implementation

\- You don't need a DirectCompute implementation, because thankfully no one is
idiotic enough to use it.

\- You don't need a Vulkan implementation, because no one is doing compute on
Vulkan (afaik).

The state of graphics and compute APIs is utter insanity. Especially Apple can
go fuck off and die with their extremely moronic move of introducing OpenCL as
an open standard in '09 and then presenting Metal as their closed API in '14,
moving against OpenCL, OpenGL _and_ Vulkan. nVidia at least has the excuse
they were first to market with CUDA (and it's easier to program), and they
stuck to it.

[1] THE standard for video effects, think "VST, but better and for video".

~~~
zozbot234
> The state of graphics and compute APIs is utter insanity.

It looks like Vulkan is going to be the best-supported common platform for
compute, at least for modern hardware. They need compute in the standard to
support the core graphics use case anyway, so we might as well use that same
support for general-purpose tasks. On Apple platforms, MoltenVk can implement
Vulkan support on top of Metal

~~~
quikoa
Yes, a common GPU compute platform would be great! Even if Apple isn't going
to support it being able to handle all of it in Vulkan would be nice. Maybe
OpenCL can be implemented on top of that.

------
Netcob
This may be a bit of an extreme view, but I don't like frameworks at all. In
general.

They are nice for little "hello world" applications that demonstrate how easy
it is to create and deploy a new project, but it's just like the "programming
language demo snippet" problem - it tells you nothing about what it's like to
use this thing in a big, long-term project.

APIs and libraries on the other hand are usually not a problem. Especially
graphics APIs - if you have a big project that makes heavy use of a graphics
API, it's probably best to create an abstraction layer. That can be a very
tricky task at conception, but it gives you a lot of flexibility later. It's
definitely necessary for dependency inversion.

With frameworks you don't get that benefit. Making a "framework-independent"
application (not library) through abstraction is a bit like trying to kiss
your own butt. You'll probably break yourself while attempting it and it's a
dubious goal in the first place. (I tried it with ASP.NET Core and I still
have back problems)

The worst thing about frameworks is that they force their architectural style
on you. If you want to get anything done it's a bit like working in a very
large company - you have to spend a lot of time learning all of its little
idiosyncracies, politics and issues so you can adjust to them, your work has
to mirror all of their design mistakes and they can basically just decide to
effectively cancel your project at any time for no reason.

~~~
jasode
_> This may be a bit of an extreme view, but I don't like frameworks at all.
In general._

I don't think giving an opinion such as _" I don't like frameworks"_ without
any concrete source code of non-trivial projects is productive discussion. (My
previous comment about "unnamed invisible frameworks" :
[https://news.ycombinator.com/item?id=14172165](https://news.ycombinator.com/item?id=14172165))

 _> They are nice for little "hello world" applications that demonstrate how
easy it is to create and deploy a new project,_

It's the opposite. A good framework that fits the problem domain does a lot of
low-level gruntwork that frees the programmer to focus on higher-level tasks.

It's not libraries OR frameworks. Real-world complex applications can use
both.

~~~
Moru
One of the problems with using a framework for a non-trivial project is that
you get locked into the framework. If the framework decides to change
something in an update that you depend on, it can mean non-trivial rewrites
unless you could expect the development already. Most frameworks tries to be
close to 100% backwards compatible and grow in complexity because of it.
Others change a little at a time. And then some does big breaking changes or
rewrites and calls it version 4.0. That makes it increasingly hard to find
help online.

~~~
dagmx
It really depends how you structure your code. While my Qt apps are very much
coded against Qt, it’s actually pretty easy for me to currently switch them to
other UI frameworks as needed. I’ve done this with some of my bigger tools
going to other frameworks.

If you keep your logic separate from your UI, and interact via method calls,
it’s not very hard to swap out the underlying object. Arguably, it’s the
pattern Qt encourages anyway so that you can flexibly change your UI design in
the future

~~~
alaenix
> While my Qt apps are very much coded against Qt, it’s actually pretty easy
> for me to currently switch them to other UI frameworks as needed.

Are yours apps open-source or do you know some architectured in the same way ?
Curious and interested to dive into a well designed Qt application with logic
and UI separation.

~~~
dagmx
Unfortunately none of my Qt code is open source.

------
war1025
I spent a good chunk of my day today fighting a bug that I imagine is going to
bite us sooner or later at work, but so far seems limited to my machine.

We use Qt5 and QGraphicsScene with QGLWidget to let us also do custom
background painting in OpenGL. We have tried porting to the new QOpenGLWidget
before, but we hit a fun issue: If you add a QWebEngineView to a widget in the
graphics scene, the entire widget disappears for a frame every time the
browser repaints. Which gives you a really great flickering that makes the
software unusable.

It used to only happen on my branch with QOpenGLWidget, but I recently
recompiled using a newer gcc version and now it happens to me with the old
QGLWidget as well.

Qt and OpenGL seem to not get along all that great. There are all sorts of odd
rendering artifacts that pop up and never seem to get fixed. The documentation
for internal Qt code is also not great, which makes trying to parse through it
a real adventure.

Edit: Another fun bug that popped up in the Qt4 to Qt5 transition is that on
Linux if you have our app open and then switch to a different virtual
workspace and back, the app stops repainting until you resize the window.

~~~
ensiferum
Try to QOpenGLwindow. There's a function to wrap it up in a container Qwidget
so it can be embedded like a QWidwget in the UI.

~~~
war1025
Currently there is the QGLWindow that holds a QGraphicsScene, where all of our
windows are QWidgets wrapped by QGraphicsProxyWidget to get them into the
scene.

Are you suggesting that we should do another layer of wrapping the
QWebEngineView in a QOpenGLWindow wrapped in a QWidget that is then wrapped in
a QGraphicsProxyWidget?

I don't understand why that would help, but I guess you never know.

------
pdonis
So if I'm reading this right, there is still no such thing as a standard
graphics API. There's OpenGL, there's Direct3D, there's other hardware-
specific APIs (Metal and Vulkan are mentioned), and now Qt is inventing their
own API to abstract over all these APIs.

How is having a standard API to draw 3D graphics not a solved problem at this
point?

~~~
Jasper_
The game revs ruined it for everyone else ;)

The revisionist history: AAA game developers are used to console APIs. Which
do exactly what you tell them to at the hardware, no sugar coating or drivers
in the way. Having shipped a few games, drivers are indeed a terrible curse.
One vendor's D3D11 drivers are pretty notorious for being incredibly invasive
to your game in the goal of speed, making it difficult to ship content that
was consistent across devices. Another vendor, sick of having to turn their
driver into a rocket engine, found common ground with some game developers,
and made a prototype, Mantle, which showed real-world performance gains on
game content. But it was pretty specific to how their hardware and GPUs
worked. But given that Xbox wanted performance, Microsoft was I intrigued and
worked closely with that vendor to design the next-generation Direct3D API.

Meanwhile, the vendor with the super fancy drivers had a pretty major
chokehold on OpenGL, which is just an absolute terrible mess of a bad API.
It's an API that is so backwards and difficult that nobody likes it from the
driver or the application perspective, but given that this vendor had the best
drivers for it, they didn't want to lose it. But Mantle vendor wanted to shake
things up and submitted Mantle to Khronos, the organization that standardizes
OpenGL, to form the basis for the "gl-next" initiative. Mobile GPU vendors get
invo.ved and turn the design into a mess. The original engineers who designed
Mantle left their parent company over design disagreements to go join Apple,
who also had a vested interest in getting rid of OpenGL but had little desire
to use gl-next. This is Metal.

Ultimately, D3D12 is Microsoft's turf. Nobody likes Vulkan but it's there on
Android and Stadia and Linux and is pretty mediocre there. And Metal is pretty
well-rounded but is the domain of Apple.

3D rendering has always been a mess, but now it's even worse because tiles
exist, data bandwidth is crazy expensive, and game revs need more fidelity and
FPS than ever before. Synchronizing between coprocessors is now the job of the
application.

~~~
ekianjo
> Nobody likes Vulkan but it's there on Android and Stadia and Linux and is
> pretty mediocre there.

Mediocre on Linux? Since when?

~~~
dcow
Didn't Vulkan omit a way to query for active displays so you just have to pick
a random display index when your application starts up?

Other than that I thought Vulkan was pretty decently comparable to Metal. I
don't have any first hand experience with it though.

~~~
josefx
That sounds more as if it would be a window system specific issue? As far as I
know OpenGL didn't have that kind of API either and you had to use X11 and the
glX bindings for that kind of information.

------
kvark
Didn't realize Qt updates were such a disaster...

Interesting to me that they went for "Rendering Hardware Interface" with their
own "cross-compile shaders both at compile and at runtime". I wonder about the
exact scope of this work, and if they considered Vulkan Portability instead.

~~~
Jasper_
Don't take this the wrong way kvark, but is Vulkan Portability really the long
term answer here? Do we want everybody to be writing Vulkan code? It's
unfortunate that due to the mess of tilers, Vulkan got way more complicated
than it likely should have, a lot of stuff wasn't properly thought out (i.e.
pipeline derivatives, framebuffers, push descriptors), and we're even walking
back a lot of the "atomic draw" promises with e.g.
VK_EXT_extended_dynamic_state. Even D3D12 had its allocation APIs pretty badly
neutered, leaving is in this pretty suboptimal place.

I love the promises that Vulkan in theory provides but in practice the gains
haven't been as bold as we thought they would be. Explicit APIs have less lies
than the older ones, but still are pretty far from zero.

~~~
jfkebwjsbx
I have always seen its goal as providing the means to create different user
libraries for different specialized purposes on top of it.

Then you also get implementations of other APIs like Direct3D on top on
Vulkan, which is amazing because you can reuse all your code and tooling and
run everywhere.

------
xenonite
Funny to read that they are stuck with an old Qt version, 5.12 to be specific.
I am on a similar boat, stuck with Qt 5.11 as this ist the last one with
support for macOS 10.11.

And I am stuck on macOS 10.11 because it's the last with proper PDF subpixel
rendering in Preview.app.

However, many Qt developers seem to upgrade to the newest Qt version as soon
as possible. If it's an open source software, I can self-compile it using the
older Qt 5.11, which usually works. But by default, Qt is sadly not providing
platform independency anymore.

~~~
boudewijnrempt
I see no reason to support OSX 10.11 anymore, just like I don't see any reason
to support Windows 7 anymore. We have stay on Qt 5.12 because we haven't got
the time/are too lazy to fix the bugs in later versions of Qt that break
Krita, especially on Windows.

~~~
xenonite
Of course, I understand your decision. I only lament the induced
fragmentation.

~~~
xenonite
(for which Qt is the main driver)

------
atomicUpdate
ANGLE is OpenGL ES 3.1 conformant with the Vulkan backend, which runs on
Windows, Android, and Linux. A Metal backend was also added recently, though
it doesn’t get nearly as much attention as D3D or Vulkan. Seems like fixing
their ANGLE integration would be their best answer.

------
quietbritishjim
(Ask HN:) At this point, if you want to create a cross-platform hardware
accelerated application, is it better to use a game engine like Unity rather
than an application framework like Qt?

At work we have an upcoming GUI project that has lots of classical dialogue
boxes, but also has a main display area that really needs to be hardware
accelerated, and can show 2d and 3d stuff. It needs to be cross platform
including mobile. I'm at a bit of a loss where to start.

~~~
CyberDildonics
I would bet that the easiest thing would be FLTK. You can use system colors
and make an openGL window while having everything else you would expect in a
UI library. Executables with no dependencies start at a few hundred KB and it
is very fast. There is even a single big pdf for documentation and dozens of
examples that show off every widget. FLTK is very underrated these days
because no one is out there marketing it.

GLFW and IMGUI are great libraries, but once you start wanting a program with
various modal and non-modal windows, menus, widget layout, a native look, file
dialogs, fonts, drag and drop, copy and paste, unicode, spreadsheet tables,
physical printing, custom widgets, functions to hide OS specific system stuff
(like stat, directory listing etc.) you might wish you had started with
something made for what you are trying to do.

~~~
dilandau
CyberDildonics has a good point. Tcl/Tk might also be a good choice for the
application widgets, as there are lots of high level language bindings. I use
it exclusively and love it, though fltk is also very solid - just lacking the
bindings.

~~~
CyberDildonics
Bindings for what? I don't know the state of interfacing with various
scripting languages, but there are binding for lots of languages out there.

------
fungos
Google plans to add ANGLE support for Metal backend. Once that backend is done
(and even the Fuchsia support), ANGLE will continue to be an extremely viable
option.

The delay of having a Metal backend may have been the reason they're deciding
to ditch it, but is nonetheless sad.

Another future option will be WebGPU, once this is mainstream what Digia will
do with Qt7? Drop everything again?

Since Digia put their hands on Qt, it is slowly going downhill.

~~~
pjmlp
Digia goes where paying customers are.

~~~
boudewijnrempt
Digia hasn't been involved with Qt for years now. The Qt Company is an
independent company.

~~~
pjmlp
That doesn't change the point of my comment, whoever develops Qt goes where
the paying customers are.

Thanks for the correction, though.

------
zbobet2012
I love Krita. This (the qt breaking things piece) is obnoxious.

------
adamnemecek
I used to write Qt in like 2006 but I've given up. I've been rolling my own
thing in Rust. GPU first, ECS
([https://en.wikipedia.org/wiki/Entity_component_system](https://en.wikipedia.org/wiki/Entity_component_system))
based. It's surprisingly pleasant.

~~~
moonchild
I've also been working on a ui lib. Rather different, though: gpu completely
optional (though well supported); not ecs; c.

I think there's a fundamental complexity that pervades popular ui libs (incl,
qt, gtk, etc.), that doesn't need to be there.

~~~
cellularmitosis
Is this something which you can share with the public? I'd very much like to
see it! I feel like all the modern UI libs are based too heavily on OOP.

~~~
moonchild
Once it's done (tm). And there are other projects higher on the priority
queue.

However, note that I also use OOP. No inheritance (death to gobject!), but the
whole thing is based around interface polymorphism. This actually simplifies
the design significantly. And you can implement an imgui on top of it pretty
easily, if you really like hidden state.

------
srajap06
at some point, the engine stopped working on macOS. Mostly because Apple
doesn’t want people to use OpenGL, so they’re starving their drivers from
development

