Strange issue with widget failing to repaint for a long time, under certain conditions.
-
I am having a strange issue with a widget failing to repaint for a long time.
I have one non-Qt thread that plays audio and periodically posts a custom event to my GUI thread, based on audio playback position. The GUI thread reacts by generating some visual feedback (e.g., display label on top of a widget) and invoking repaint() on itself. This works great on Mac OSX and it works fine within a unit test application I have that exercises the functionality on Windows (XP & 7), however, the widget does not properly repaint in my real application, on Windows XP/7, until the audio playback finishes.
Proper behaviour observed on OSX and within my unit test:
-> Custom Event
-> QEvent::Paint (12)
-> Custom Event
-> QEvent::Paint (12)
etc.Wrong behaviour observed in my actual application:
-> Custom Event
-> QEvent::UpdateRequest (77)
-> Custom Event
-> QEvent::UpdateRequest (77)
etc.
-> QEvent::Paint (12)I have tried various things to force the repaint to occur, e.g., QCoreApplication::processEvents, but all to no avail. I have also tried eliminating the inter-thread events as a culprit and used a periodic timer to poll the current position from the audio thread and update the widget, also without much luck.
Any ideas on how to further diagnose this would be greatly appreciated!
Thanks,
Alex -
Unfortunately this seems to be systemic behavior. The smallest amount of code I was able to reduce this to is about 20,000 lines :-)
I am really just looking for some pointers to troubleshoot this further. For example, what would cause the UpdateRequest event to be generated instead of Paint?
-
It all depends on what happens in main thread. On windows, paint is called from update, but noit directly. update triggers some flags and when the event loop handles the update request, it initiates a paint event. There is no guarantee that it is done directly.