QCustomPlot Discussion and Comments

New graphics abstraction API coming in Qt 5.14Return to overview

Qt 5.14 will introduce underlying usage of RHI to drive graphics API independent scenegraph renderer as an opt-in feature, source.

"This allows running qualifying Qt Quick applications on top of Vulkan, Metal, or Direct3D 11 instead of OpenGL. The supported platforms are currently Windows 10, Linux with X11 (xcb), macOS with MoltenVK, or Android 7.0+ for Vulkan, macOS for Metal, Windows 10 for D3D."

So this basically an effort to deal with the reality of Apple deprecating OpenGL (not trying to start a thread that discusses if this will ever happen) and Graphics API fragmentation in general.

Should users of qcustomplot expect to automatically 'get this for free' through the implied integration in QtQuick or is the current implementation tied to OpenGL only?

In order to be as independent as possible from the described multitude of hardware platforms and interfaces, QCustomPlot at least tries to use Qt APIs as much as possible, i.e. the QPainter framework with its various backends. However, this is not always possible so there still is some OpenGL-specific boilerplate code in a few of QCustomPlot's methods (not the many draw methods though, this is pure QPainter/QImage-based code).

From my perspective, the dust needs to settle first. Qt has attempted to integrate Vulkan some time ago, but it was still very low-level and basically only took care of the setup and teardown of the Vulkan surface via QVulkanWindow/QVulkanInstance. So switching over to vulkan would essentially mean that QCustomPlot needs to implement a QPainter backend for vulkan. This is better done by the Qt community, rather than in a specific project like QCP (and QRhi is a step in the right direction here!) Once that is done, I will definitely add the necessary boilerplate to run QCustomPlot's QPainter calls through that vulkan (or whatever else) backend, too.

Should it turn out that one of the new hardware interfaces becomes a consistent standard it may be thinkable to abandon QPainter calls and rewrite QCustomPlot's drawing methods in that standard. However I don't see such a interface standard coming up any time soon. For now it looks as the interface zoo has just become bigger by yet another contender.

We will see how it turns out once the situation is more stable. With a library as QCustomPlot that's used in so many critical and large applications, I favor stability and dependability over early adopting of shiny new technology, particularily with such far-reaching changes.

So you prefer to stay on Qt 5.12.x LTS for large Applications and not to trying things out with Qt 5.14.x.

As of Qt 5.14 a big change to the Android community for Qt is coming. They adopted AAB as deployment package. Build once all platfroms and deploy once.

How should I deal with Qt 5.14 to have QCP still working on IOS and Android. Should I then use raster drawing?

Why do you expect there to be issues when switching to Qt 5.14? Backward compatibility of sources should be guaranteed on minor releases, so there shouldn't be any issues with QCP or OpenGL even if they change their package output. And like you said, the alternative graphics backends are optional additions to facilitate early adoption of next-gen stacks, it doesn't mean the rest will get deprecated anytime soon.

So as mentioned, if people like to switch to newer Qt versions to utilize the features there, QCP won't stand in the way. At the same time, if a team decides to stick with something as far back as Qt4.6 for now, QCP2 will also allow them to do that. Lets wait until the dust settles. Qt has demonstrated over the last decade(s) that the next hot thing (like GraphicsView and QtQuick1) is sometimes deprecated faster than the early adopters can release their product. A library shouldn't fall into that trap :)

But please let me know if you have information that indeed Qt5.14 will break something that would make using QCP impossible there. So far I couldn't see it. Yes, Apple deprecated OpenGL in iOS12, but afaik hasn't removed it yet. I trust Qt will have a working backend ready once it's needed by a relevant share of the users. (And don't get me wrong, I believe Deprecating the 25 year old OpenGL is a reasonable step. I'm just a bit surprised the industry has yet again failed to come together and create a compatible common successor.)