On quarta-feira, 6 de julho de 2016 00:56:04 PDT Scott Aron Bloom wrote: > Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt > Quick instead. Qt Quick uses the GPU, QtWidgets do not. > ========== > > That’s a pretty horrible answer... There are MANY of us, who prefer for all > sorts of reasons, to use C++ as our primary development language. > Is there no outlook for QtWidgets to start using the GPU?
No. Long story short: the QPainter model is incompatible with OpenGL. We tried, we failed. So we created a new one that works as OpenGL expects and it's called "Qt Quick 2". Alternative long story short: we've already done that work and the result is Qt Quick 2 and Qt Quick Controls. Long story: let me take us back 8 years. Before Qt 4.5, used the "native" engine for painting on X11 and on Mac, and it had a really horrible GDI engine for Windows, so it had a replacement engine that used its own internal painting mechanism using QImage. Because of that, it was called the "raster" engine. The XRender engine for X11 was much faster than "raster", but it produced subtly different output depnding on the X11 version, the number of bugfixes applied (and X.org developers were then invariably GNOME users, which meant they never tested Qt) and very different from Mac and Windows. The best of both worlds would be to make the raster engine as fast as the native, of course. But how? Well, turns out that the GPU is very good at doing graphics. And we have an API to access the GPU, it's called OpenGL. So Qt 4.5, in addition optimising the raster engine and making the graphics system selectable at runtime, introduced a new, experimental graphics system called "opengl". This was called "Falcon Project". Those of you who have tried the opengl graphics system in Qt 4.5-4.8 know how buggy it was. We never made it work properly, for many reasons, including some that were the same as the native graphics system problems: OpenGL drivers work differently from one another. Most importantly, the imperative painting model that QPainter and, by extension, QWidget use, is incompatible with how GPUs operate. You can do it, but it's not very efficient. Right around that time, the MeeGo project was starting and the Qt developers were comparing notes with the Clutter developers. Clutter was around this time developing a backend called "Clutter on OpenGL" (COGL), which was like the Qt's opengl graphics system, but with one twist: it would defer all painting operations into a journal and then reorder them as necessary to be efficient with the GPU. Qt developers looked at that and decided it was overly complex and didn't go far enough, not to mention that all Clutter developers, being employed by Intel, were optimising only for the Intel GPUs (yeah, I work for Intel now). From what I understand from the developers at this time, the most problematic issue with OpenGL was saving state between frames. With an imperative painting model, the engine cannot know what's going to happen on the next frame, so it cannot know what to cache and what to discard. If you cache too little, you spend time re-uploading resources to the GPU and re-rendering things; if you cache too much, you're wasting resources. So around the time that Qt 4.8 was launching, we kicked off a new project that tried to use OpenGL the way that it was designed to be used, like games do. This project was called "Scene Graph" and is fundamentally different from QPainter that it works in *retained* mode instead of imperative mode. The graph of that Scene Graph *is* the cache: while the graph node is present, its associated GPU resource is kept; when it's removed, the resource is discarded. All the engine needs to know is the order in which the OpenGL resources should be sent to the GPU when rendering the frame. And note that this can be pre- calculated and stored, instead of re-calculated in each frame. This is also the reason why Qt 5.0 came with Qt Quick 1 (based on QGraphicsView, which means QPainter) and Qt Quick 2, which is designed around OpenGL. That in turn is the reason why there was a requirement of OpenGL for Qt Quick 2 and why version 1 was deprecated then. 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
