Visuals not refreshing without mouse movement
-
wrote on 22 Mar 2023, 10:38 last edited by PLL3
Hi everyone, I am once again posting here trying to solve this issue.
Like before, I'm not able to give a minimal reproductible example nor can I share my source code. However I have managed to anonymize our UI and thus can share screenshots (I could've recorded a video but I don't think I can post videos here) :
We start with the mouse on the middle button.
We click to get to the next panel, the QLineInput disappear, the buttons gets disabled during the loading, so far so good.
But once the next panel is loaded (it is empty so there is nothing to show), the disabled buttons should become enabled again.
But as you can see they stay visually disabled until there is a mouse event either leaving the button (middle button screen 3) or entering the button (right button screen 3 or left button screen 4).
This bug is only present when I give too big a radius to the QGraphicsDropShadowEffect I apply to the topmost widget. In the screenshots the radius is set to 30. If I give a value below 12 the bug seems to go away, but then my shadow effect doesn't look good.
This bug doesn't only affect QPushButtons but everything that should visually change doesn't until there is a mouse event associated with the bugged element.
Just like in my previous post I don't know where to go from there.
Any help or hints would be greatly appreciated. -
Hi everyone, I am once again posting here trying to solve this issue.
Like before, I'm not able to give a minimal reproductible example nor can I share my source code. However I have managed to anonymize our UI and thus can share screenshots (I could've recorded a video but I don't think I can post videos here) :
We start with the mouse on the middle button.
We click to get to the next panel, the QLineInput disappear, the buttons gets disabled during the loading, so far so good.
But once the next panel is loaded (it is empty so there is nothing to show), the disabled buttons should become enabled again.
But as you can see they stay visually disabled until there is a mouse event either leaving the button (middle button screen 3) or entering the button (right button screen 3 or left button screen 4).
This bug is only present when I give too big a radius to the QGraphicsDropShadowEffect I apply to the topmost widget. In the screenshots the radius is set to 30. If I give a value below 12 the bug seems to go away, but then my shadow effect doesn't look good.
This bug doesn't only affect QPushButtons but everything that should visually change doesn't until there is a mouse event associated with the bugged element.
Just like in my previous post I don't know where to go from there.
Any help or hints would be greatly appreciated. -
wrote on 23 Mar 2023, 02:03 last edited by Kent-Dorfman
my WAG is that you are stalling the event loop somewhere by doing procedural programming and not purely event driven. I've also seen problems like you describe because of memory leak/access problems with how heap managed GUI elements are handled.
-
wrote on 23 Mar 2023, 11:41 last edited by
@JoeCFD No, we do not support touch screens (if you're wondering why the cursor looks weird, it's because screenshot don't normally capture the cursor so I had to add them back).
I don't believe I'm ever calling update() on any of my buttons, I haven't had an issue so far.
-
my WAG is that you are stalling the event loop somewhere by doing procedural programming and not purely event driven. I've also seen problems like you describe because of memory leak/access problems with how heap managed GUI elements are handled.
wrote on 23 Mar 2023, 11:52 last edited by@Kent-Dorfman There is indeed a fair bit of calculation usually done in this panel, but like I said in my first post, I removed everything from that panel. There is nothing to load, to compute, so I'm not sure how I could stall that event loop you talk about.
I'll look into the memory leak theory.
Still, it somehow has to be related to the QGraphicsDropShadowEffect I apply to my topmost widget, since the bug appears and disappears depending on the blur radius. This is what puzzles me the most.
-
@Kent-Dorfman There is indeed a fair bit of calculation usually done in this panel, but like I said in my first post, I removed everything from that panel. There is nothing to load, to compute, so I'm not sure how I could stall that event loop you talk about.
I'll look into the memory leak theory.
Still, it somehow has to be related to the QGraphicsDropShadowEffect I apply to my topmost widget, since the bug appears and disappears depending on the blur radius. This is what puzzles me the most.
wrote on 23 Mar 2023, 12:00 last edited by@PLL3 said in Visuals not refreshing without mouse movement:
Still, it somehow has to be related to the QGraphicsDropShadowEffect I apply to my topmost widget, since the bug appears and disappears depending on the blur radius. This is what puzzles me the most.
Indeed this appears to be key to your finding. And would not be common for other users.
It seems really "strange" that this would affect behaviour in the way your report. It might be "coincidence", somehow.
I am not understanding what this "topmost widget" is. Your screenshots show a rectangular widget on which all your text and buttons are placed. Is that your "topmost widget"?
If this genuinely depends just on some drop shadow effect, you really should be able to reproduce a tiny, standalone example. If not it makes me wonder about what else in your code might be the cause.
-
@PLL3 said in Visuals not refreshing without mouse movement:
Still, it somehow has to be related to the QGraphicsDropShadowEffect I apply to my topmost widget, since the bug appears and disappears depending on the blur radius. This is what puzzles me the most.
Indeed this appears to be key to your finding. And would not be common for other users.
It seems really "strange" that this would affect behaviour in the way your report. It might be "coincidence", somehow.
I am not understanding what this "topmost widget" is. Your screenshots show a rectangular widget on which all your text and buttons are placed. Is that your "topmost widget"?
If this genuinely depends just on some drop shadow effect, you really should be able to reproduce a tiny, standalone example. If not it makes me wonder about what else in your code might be the cause.
wrote on 23 Mar 2023, 12:53 last edited by@JonB Hi, thanks for the reply !
Have a look at this diagram:
This is a simplified (and anonymized) diagram of my app architecture. The "topmost widget" to which I apply the QGraphicsEffect is "shadowWidget". The "footer" is where the three buttons are. The "panelLayout" is where the actual content of the app would be loaded and "header" is, in effect, replacing the native windows taskbar (I removed it as well on the screen shots).
I'll try one more time to reproduce my bug in QtCreator.
-
@JonB Hi, thanks for the reply !
Have a look at this diagram:
This is a simplified (and anonymized) diagram of my app architecture. The "topmost widget" to which I apply the QGraphicsEffect is "shadowWidget". The "footer" is where the three buttons are. The "panelLayout" is where the actual content of the app would be loaded and "header" is, in effect, replacing the native windows taskbar (I removed it as well on the screen shots).
I'll try one more time to reproduce my bug in QtCreator.
-
@PLL3
I respect what you say about your findings, but when looking at that diagram how would you guess anything on shadowWidget would get to affect something inside footer? Just saying.wrote on 23 Mar 2023, 13:34 last edited by@JonB I'm not guessing, I'm just pointing out things I've noticed.
Evidently there's something about QGraphicsDropShadowEffect that I don't get. I'm not even entirely sure if I'm using it correctly, maybe it's not made for the shadow effect on app windows but rather for visual purposes on some widgets, the doc isn't super useful here tbh.
But from what I understood, correct me if I'm wrong, QGraphicsDropShadowEffect is supposed to propagate to children (or at least it does so in my tests), which prompts me to believe that I'm not supposed to use it for this but I don't know how else to do it.
-
@JonB I'm not guessing, I'm just pointing out things I've noticed.
Evidently there's something about QGraphicsDropShadowEffect that I don't get. I'm not even entirely sure if I'm using it correctly, maybe it's not made for the shadow effect on app windows but rather for visual purposes on some widgets, the doc isn't super useful here tbh.
But from what I understood, correct me if I'm wrong, QGraphicsDropShadowEffect is supposed to propagate to children (or at least it does so in my tests), which prompts me to believe that I'm not supposed to use it for this but I don't know how else to do it.
wrote on 23 Mar 2023, 13:52 last edited by@PLL3 someone else had the same issue?
https://forum.qt.io/topic/121567/not-renewing-trying-to-set-qwebengineview-on-ui/3 -
@PLL3 someone else had the same issue?
https://forum.qt.io/topic/121567/not-renewing-trying-to-set-qwebengineview-on-ui/3wrote on 23 Mar 2023, 14:21 last edited by@JoeCFD Thanks for the link. I've looked at it, it could indeed be the same issue, setBlurRadius() seems to also be the issue and we're both unsing Frameless windows.
But there doesn't seem to be a fi x proposed other than removing the call to setBlurradius() .
-
@JoeCFD Thanks for the link. I've looked at it, it could indeed be the same issue, setBlurRadius() seems to also be the issue and we're both unsing Frameless windows.
But there doesn't seem to be a fi x proposed other than removing the call to setBlurradius() .
wrote on 23 Mar 2023, 14:57 last edited by@PLL3 That could be a Qt bug. You can work around the issue by manually triggering a useless mouse event to update it after it is enabled since you know a mouse event can update it.
Or upgrade your Qt to see if the problem is fixed.
1/12