QOpenGLWidget doesn't immediatelly repaint on repaint()

When immediate repaint is required and repaint() method is called on QOpenGLWidget doesn't repaint if the last repaint happened sooner than is a refrest rate of monitor. This is caused by the code in QWidgetBackingStore::sendUpdateRequest() - the code starting with

 if (updateTime == UpdateNow && w && w>windowHandle() && QWindowPrivate::get(w->windowHandle())->compositing) {

This is however absolutely undocumented and our code relies on repaints to happen immediatelly. At the very least minimum this should be disable-able. Also documentation should be updated accordingly.

To ilustrate problems to which this leads:

In our engine case (our engine is not much optimal) following happens during first cycle of animation:
1) Data for rendering are loaded on separate thread. Then once this is done an immediate repaint is issued to update the viewport and also VBO cached.
2) Then the buffer storage is switched for animation VBO storage (stores VBOs for each frame of animation) and another immediate repaint is issued (to fill those buffers too). However this repaint is not done, resulting in animation buffers not being filled!

This leads to some hard to track bugs where instead the buffers are filled with last loaded data from the first animation cycle when second cycle starts to play from buffers which are not there!

It cannot be simply expected that a request for immediate repaint can be post-poned in any sense since a repaint can have various side-effects causing unpredictable bugs. In the multi-thread application an uninterrupted code flow may be necessary and the application may not get to event loop for some time to just hold the code flow. For all of this reason please at least provide a means to disable it.

Additional notes:
1) Out application shares all contexts: QCoreApplication::setAttribute(Qt::AA_ShareOpenGLContexts);
2) V-Sync is application wide disabled:

format.setSwapInterval(0);
QSurfaceFormat::setDefaultFormat(format);

This is additional reason, application may choose not to wait for any V-sync at all which the backing store is disturbing!

3) This has been observed on Windows 10, but it may not be platform specific