[Qt-interest] QSlider::setValue() causing delays in QTimer event delivery

[Frank Hemer]

On Thursday 18 February 2010 16:07:41 Josiah Bryan wrote:
> Andrew Hodgkinson wrote:
> > On 18/02/2010 13:30, Josiah Bryan wrote:
> >> [...] why the QSlider delays timer delivery when calling setValue(x)
> >
> > This is presumably because Qt applications appear to be based around an
> > internal single threaded event queue, with the pending timer signal
> > appearing in that same queue. The update of the QSlider takes a while so
> > the queue isn't processed as quickly as you need. The queue approach was
> > doubtless chosen to avoid the issue of re-entrancy that would arise from
> > a more interrupt-like approach (c.f. "signals" in the Unix sense).
>
> I'm sure that's the case...but really, why does QSlider *take* so long
> to update the slider position? It's not painting in that slot (that I
> can tell), the core event loop isn't run from within that slot, no
> signals are emitted from within that slot (since I called
> blockSignals())...I'm just curious as to why setValue causes >100ms
> delay in event processing. Anyway, beating a dead horse - the point is
> made. :-) Sorry for the rambling here!
>
> > I hope I'm wrong and QTimer is a special case but there's nothing I can
> > see in the documentation to indicate this. I would imagine the
> > architectural restriction is a particular reason why a secondary thread
> > is explicitly discussed in the QTimer detailed description text.
>
> Agreed. Unfortunately, a secondary thread still has to hit the GUI
> thread eventually to get the image on screen - and if the GUI thread is
> blocked by the slider - well, the image isn't really going to get on
> screen on time.
>
> >> I'd love to be able to pump frames directly to the video card and bypass
> >> the GUI thread all together - but I know of no way in Qt to update the
> >> screen from outside the GUI thread.
> >
> > No, neither do I, sorry; maybe if we're lucky the extra traffic in this
> > thread might attract others with more experience in this area. I'd be
> > interested to hear of possible solutions too as I have worried about such
> > problems in the past.
>
> A thought just occurred to me - is it possible to "blend" two disparate
> OpenGL textures into a third GL texture using some sort of on-GPU code
> (forgive any inaccuracy, but something like pixel-shaders that run on
> the GPU?)
>
> Combine that with some way to just dump a texture to the GPU from a
> secondary, non GUI thread, and the problem is solved. (Not paint or
> update the UI - let the GUI thread actually do the screen manipulation -
> I just want to update a texture in the GPU memory from a secondary thread.)
>
> Does anyone know if it's possible to "back door" a texture onto the GPU
> from a non-GUI thread somehow?
>
> > ...
> > In that sense, even if Phonon didn't stutter during cross-fades, you
> > might find that certain Linux and older Windows distributions wouldn't
> > manage the cross fade properly in the first place. Perhaps the stutter is
> > in fact caused by the video widget attempting to deal with the opacity
> > change / composition requirements by switching over from a hardware
> > graphics plane to a slower software plane renderer internally.
>
> Probably. More testing is needed. The "videos get pimped" Qt blog post
> hints at the fact that a software renderer is used for some operations -
> probably is used when opacity is changing as well.
>
> > Out of interest, if you still have code you can test using Phonon rather
> > than your ffmpeg solution, what happens if you hold the video in a
> > partially cross-faded state but don't change the opacity? Does video play
> > smoothly, but only stutter each time the opacity actually changes?
>
> I'll test that out and get back to you. Yes, code is still in the repo -
> just commented out or otherwise disabled for now - I'll go back and run
> some tests with it today.
>
> > ...
> > If this really is due to the slider update increasing latency within the
> > event queue then a possible, if not ideal solution would be to implement
> > your own slider-like widget or other progress indicator and do everything
> > you can to get it running quickly enough that it completes in less than
> > the ~33ms or so required for 30fps video (on some minimum target hardware
> > performance profile).
>
> I'm crossing my fingers on that one - the last thing I want to do is
> implement a custom slider from scratch! :-) But, I may have to when it's
> all said and done. We'll see.

Hmm - just to eliminate the obvious: Make sure there are no slots connected to 
the QAbstractSliders signals that might cause the delay ...

Frank