Widget not repainting

DalePennington

We have an application that handles reporting system Alerts. It has 2 visible windows based on QWidget :

Log Window : Contains a QTextEdit that we add alert text to the top of. May not be visible.
Alert Window : Temporarily displays latest alert, then hides after 5 seconds (QTimer triggering a hide).

When both windows are visible, the Alert Window obscures a part of the top of the Log Window.

When an alert comes in, the processing turns the alert to text and inserts it in the Text Edit, then passes it to the Alert Window, which displays it and starts its 5 second to hide timer.

The issue we are seeing is that some times, the Log Window does not appear to be painting. A new alert shows up in the Alert Window, but not the Log WIndow, and when the Alert Window goes away, the part overlapping the Log Window is not redrawn. Also, it does not respond in any other way, as if it is frozen, or not repainting. But is a hide then show is issued for the Log Window, it starts behaving normally.

As noted above we suspect the issue is with the Log Window for some reason not repainting like it normally should. So the question is : Is there anything in Qt that might be preventing this ? And is there a way to determine if that condition is in effect ?

Thanks,
Dale Pennington

JonB

@DalePennington
The initial answer is that you really ought take your Log & Alter windows code and try to reproduce in a standalone application.

It sounds like you have a window update problem.

Two quick initial questions:

Do you have any "blocking" loops, which could prevent the Qt event loop from being hit? When these logs/alerts are being performed, is your "backend" busy doing something?
Do you have any threading in your code?

Maybe show your dispatching, timeout and hiding code, in case there is something there.

DalePennington

Techically they are a seperate application is a suite of application we have.

On the blocking, I cannot find any (other than some controlled mutexes, and other behavior shows they are not blocking), and the fact the Alert window is still showing updates when the Log Window does not seems to indicate the GUI thread is still running strong.

We do have 2 other threads. Both take incoming communications and pass them to the Qt thread. This is done by calling a function to place the incoming data in a queue (protected by mutexes), then emitting a signal to have the GUI thread put the data out of the queue and update the windows.

Dale

SGaist

Hi,

How do you show your alert window ?

DalePennington

The Alert Window is never actually hidden (per show/hide). Instead, it gets resized from 1 (the "hidden" mode) to 67. So when they want to user to see it they do

this->resize(856,67);
this->raise;

and when they want to not show it

this->resize(856,1);

The Log Window uses show and hide.

Dale

SGaist

On which OS are you seeing this behaviour ?

DalePennington

We are running on RHEL 8.4, using QT 5.12.5

SGaist

Would it be possible to use a more recent version of Qt ? 5.12 is more than outdated.

DalePennington

We tried using the 5.15.5 (libraries, not recompiling the apps), and saw the same behavior.

SGaist

Can you reproduce that with a minimal application ?

DalePennington

At this point, no. Part of it appears to be interaction between multiple apps and a custom Window Manager (all Qt based).
The next thing we are thinking of trying is downloaded the latest Qt5.15 source, and adding debug to track outgoing/incoming XCB events/activities relating to sizeing, mapping and exposing and see if that gives us a clue to what is going on.

Dale