[Interest] Utilizing the GPU, how to start?

André Pönitz apoenitz at t-online.de
Wed Jul 6 21:04:13 CEST 2016

On Wed, Jul 06, 2016 at 06:10:37PM +0000, J-P Nurmi wrote:
> > On 06 Jul 2016, at 19:41, Uwe Rathmann <Uwe.Rathmann at tigertal.de>
> > wrote:
> > 
> >> On Tue, 05 Jul 2016 23:58:48 -0700, Thiago Macieira wrote:
> >> 
> >> So what you want isn't QWidget with OpenGL support. We've proven it
> >> won't work. What you want is a powerful, Scene Graph-based set of
> >> widgets with native look and feel (that is Qt Quick Controls).
> >> 
> >> You're probably also asking for a C++ API instead of a QML one.
> > 
> > And this is exactly what I'm currently trying to do - creating a set
> > of Quick controls offering full featured C++ and QML APIs.
> > 
> > Our main motivation is the well known instantiation problem of QML,
> > that is totally dominating the overall performance of our user
> > interface. As most of our QML code is application code, having a C++
> > API for the controls is mandatory to significantly limit the amount
> > of QML.
> Interesting choice. I would have done the exact opposite. Application
> logic in C++ and UI declaration in QML. Declaring fluid animated UIs
> in QML is a joy, writing animations in C++ is not so.

Right, but not because C++ is insufficient for the task, but because
it is "impossible" to disantangle the JSON-ish and the JS parts of
Qt Quick and easily re-use the same backend implementation with
a plain C++ interface.

Stuffing a few items into a JSON-style property bag is a no-brainer in
C++. Last time I looked there was even something called 'QtJson' which
pretty much looked like a Qt/C++ JSON implementation.

Intesting enough, stuffing a few properties into a bag and optionally
add an event handler or two is also what a typical Widget use looks
like. So this is clearly possible in C++.

The JavaScript part in Qt Quick is of course uglier to avoid. But we all
know that this absolutely and really does not exist (If it would, Qt
Quick wouldn't be "declarative", right?), and if it accidentally existed
it would not be compulsory to use, and if it acccidentally would be.
recommended best practice would of course be to avoid it, and in case
usage is unavoidable...  oh, well, it does not exist, right?

So where exactly is the *real* problem that there is no C++ interface
to "fluid animated UIs"?


More information about the Interest mailing list