Map Display jumps due to Qt::QueuedConnection

[MichaelGrupp]

After the recent upgrade from 1.14.20 to 1.14.23, we observed glitches when rendering dynamic maps such as costmaps.

I tracked the problem down to this commit: 93ac44b (PR #1793)

This "hack" seems to cause a delay in map rendering that leads to a broken map display.

With QueuedConnection

Using an unmodified 1.14.23 from the ROS noetic package distro. The costmap is jumping while moving. Note that the costmap frame_id is in a fixed frame.

broken.mp4

Without QueuedConnection

I cloned RViz from source at 1.14.23, removed that Qt::QueuedConnection flag, and built it. Using this patched RViz, the costmap is rendered at the correct spot again without jumping:

patched.mp4

Your environment

• OS Version: e.g. Ubuntu 20.04
• ROS Distro: Noetic
• RViz, Qt, OGRE, OpenGl version as printed by rviz:

[${node} INFO 1715596133.955965167]: rviz version 1.14.23
[${node} INFO 1715596133.956069614]: compiled against Qt version 5.12.8
[${node} INFO 1715596133.956126962]: compiled against OGRE version 1.9.0 (Ghadamon)
[/rviz_1715596402254328779 INFO 1715596402.270469085]: Forcing OpenGl version 0.
[/rviz_1715596402254328779 INFO 1715596402.742861634, 1715596391.783960104]: Stereo is NOT SUPPORTED
[/rviz_1715596402254328779 INFO 1715596402.743000877, 1715596391.783960104]: OpenGL device: AMD RENOIR (DRM 3.44.0, 5.16.15-051615-generic, LLVM 12.0.0)
[/rviz_1715596402254328779 INFO 1715596402.743048266, 1715596391.783960104]: OpenGl version: 4.6 (GLSL 4.6) limited to GLSL 1.4 on Mesa system.

• If source build, which git commit? -
• System locale, i.e. the output of echo "$LANG $LC_NUMERIC": en_US.utf8 (LANG=C rviz doesn't change anything here)
  Before reporting a rendering issue, try running RViz with LANG=C rviz!

[MichaelGrupp]

PR with code changes for my workaround: #1827

@StefanFabian: for your information

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/preparing-for-noetic-sync-2024-05-09/37602/9

[rhaschke]

Thanks for reporting this issue. Could you please provide a bagfile with your map data to experiment with the issue?

[MichaelGrupp]

Thanks for the quick response. Here's a minimal example bag with only an occupancy grid topic /navigation/move_base_flex/local_costmap/costmap (zipped because of GitHub upload constraints).

example_costmap.zip

The effect should be visible when you set the RViz fixed frame to "map" and enable the grid. For reference, here's how a replay of that bag looks like on my computer:

example_bag.mp4

and without the queued connection:

example_bag_patched.mp4

[rhaschke]

Thanks for providing the bag file. I can reproduce the glitches with that file. However, a simple test example (map_test.py) doesn't exhibit the issue. Thus I don't yet understand, where your particular issue comes from.
What version of the map is shown for the fraction of a second?
Could you please experiment with this test map and try to reproduce your issue with it?

[MichaelGrupp]

The issue seems to be visible with the following conditions:

• grid is moved
• content of grid changes

With the queued connection enabled, the previous grid gets first moved to the new position. Then the content gets updated with a short delay. It's not the grid moving to the wrong position, this is easier to see when replaying the videos with slower playback speed.

Here's a modified version of your script that makes it a bit better visible, it uses the RViz logo image from this repository:
magazino@0bc8926

It looks like in the video below in RViz 1.14.23. Also here I'd recommend to reduce playback speed, but it's also visible in normal speed.

screencap-2024-05-14_13.42.46.mp4

With the modified source without queued connection:

screencap-2024-05-14_13.48.22.mp4

[rhaschke]

I filed a PR to fix this issue: #1828. Could you please review?