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

[Josiah Bryan]

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.

Thanks for your input!
-Josiah

-- 

-=-=-=-=-=-=-=-=-=-=-=-=-
Josiah Bryan
Productive Concepts, Inc.
jbryan at pciint.com
(765) 964-6009, ext. 224