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

[Andrew Hodgkinson]

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 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.

> 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.

Ironically the best chance you might have of achieving this would be on 
non-compositing window managers such as Windows <= XP or >= Vista without 
Aero. In those cases, typically video is decoded into a secondary 
graphics card plane with the Windows GUI overlaid and a 'hole' cut 
through to show the video decode beneath. That leads to the familiar lag 
when a window playing video is dragged around, with the video moving a 
little while afterwards underneath. Thus, data written into the video 
plane has no danger of interfering with stuff in the overlaid graphics 
plane - but then you can't cross-fade between them so your original goal 
is lost.

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.

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?

> But not necessary to look at all that if you're not interested - my main
> concern is primarily why does QSlider interrupt timer delivery for so
> long.

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).

-- 
Andrew Hodgkinson, Endurance Technology
Land line: 01223 369 408, mobile: 07855 866 780
Registered Office: 5 Marine Drive West, Bognor Regis, W. Sussex, PO21 2QA