Am 02.09.18 um 20:01 schrieb Thiago Macieira:
On Sunday, 2 September 2018 06:05:57 PDT Uwe Rathmann wrote:
Thiago argues, that a QPainter based render engine results in performance
bottlenecks. But if it is possible to have significantly better results
with QNanoPainter then there is no conceptual problem and Qt development
could improve the situation by working on the code of the OpenGL paint
engine.
There is a conceptual problem. You're never going to match the performance of
something designed with retained mode and OpenGL in mind if every redraw every
frame from scratch. In an imperative-mode paint engine, every time
paintEvent() happens, the world restarts. Every frame can be completely
different from the previous one. So the code that maps this back to OpenGL has
to do a lot of state management behind the scenes to avoid recreating
everything from scratch.
You can get a lot of things done, but there's a limit. The complexity can
become unmanageable at some point. Either way, there's a ceiling of
performance.
Back in 2010, when Qt developers began talking to Clutter developers due to
the MeeGo project, Clutter developers told us how they accomplished COGL
(Clutter On OpenGL). Clutter had (has?) a huge state-management and caching
engine, trying to reorder your imperative painting events so that the amount
of OpenGL work was reduced, with fewer state transitions. It worked pretty
well and that's what the Qt 4.6 through 4.8 OpenGL Paint Engine tried to do
too. I don't know qnanopainter, but there's a good change it's doing that too.
Clutter achieved pretty good results, but mind you that developers who worked
on it worked for Intel (Openedhand had been acquired recently) and only
optimised for the Intel desktop-class GPU, for which the driver source was
open, allowing the developers to understand what cost more. Nokia developers,
on the other hand, were fighting against the PowerVR mobile-class GPU with the
Imagination closed-source drivers, running on seriously underpowered ARMv6
CPUs. On one particular Nokia device, the glSwapBuffers() call itself was
taking 13 ms, or 78% of the time budget for each frame.
The solution to do CPU work to buffer GPU commands to reorder them and cache
states simply did not get us the performance we needed. By the end of 2010, we
had already noticed this and we had two developers (Gunnar and Kim) working on
figuring out how to write proper code to use the GPU the way the GPU is meant
to be used. This event is what I am calling the end of the OpenGL paint engine
experiment and the birth of the scene graph.
In addition to what Thiago beautifully summarized, there's one other
difference between QNanoPainter and QPainter: The former is a new API
that can limit itself to features that work well with OpenGL, while with
QPainter the range of different features and expected behavior is
bigger. So the GL paint-engine has to do certain things in a certain way
to maintain compatibility with the way QPainter is expected to behave
when it is used on a raster surface. This may come at the expense of
performance.
I'm sure this isn't quite news, but together with Thiago's statements I
think this summarizes that while it may be possible to squeeze out
perhaps a little more with the GL paint engine, it's not necessarily a
good overall investment of time when the scene graph provides a better
opportunity to get closer to the theoretical maximum of performance - by
design.
Simon
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
