[Development] Late API addition in QScreen for 5.0

[gunnar.sletta at nokia.com]

> > There is some risk involved though; an application with multiple windows
> > each being rendered to with OpenGL in a single thread will end up
> > achieving a max framerate of screen_refresh_rate /
> > number_of_animating_windows, due to swapBuffers blocking. Since it's not
> > a panacea, it might be too dangerous to enable it unconditionally.
> >
> 
> :( I guess the solution is if we can somehow get one render thread per
> window (which Samuel told me on irc is not safe with current design).

It is true that the current implementation does not support this, but it would rather straightforward for someone to add a new window manager to src/quick/items/qquickwindowmanager.cpp that renders all the windows in sequcene in the "main" GL context and then splits out and swaps on one window per thread, then waits for them to join together before continuing. Adding this to the existing renderloop would probably not be a huge task either. Just a little bit slower for systems that can do buffer queueing. 

> > We also need to consider what to do with the threading and buffer
> > queuing capabilities in the platform integration, that make a big
> > difference in the animation quality. I've made this change that adds an
> > environment variable to enforce the threaded renderer, to at least give
> > some degree of control over it without having to recompile Qt:
> > https://codereview.qt-project.org/#change,25271
> >
> 
> This change is indeed very useful. For the raspberry pi, amlogic
> 8726-M, turning on BufferedQueing has made a big difference to
> performance. It would be great to have this somehow be determined
> programmatically. If that's not possible, can we add a
> qmlscene-launcher script to qtdeclarative that basically checks the
> graphics driver and turns on/off these environment variables? (I can
> provide a change, if we agree)

The problem for X11 is that initial show, resizes and shutdown process always ended up crashing somewhere. There is work needed in both the Qt xcb backend, xcb and mesa and probably also the individual GL drivers to enable the threaded renderer safely in general.. Single context, fullscreen setups like you typically would get on the pi and other embedded systems are much less problematic.

As for detecting buffer queueing, support for threaded GL rendering, whether we have blocking swap or not. One option would be to start whitelisting "known good" configurations and drivers. A pain to maintain, but it would at least pick the good code paths for the most commonly used hardware.

Gunnar