`multi_view_render` will pop new display window on each frame with latest version of Pygame
Morphlng opened this issue · 6 comments
Description
I'm testing the pre-defined environment 'HomoNcomIndePOIntrxMASS3CTWN3-v0' using code in stop_sign_3c_town03.py.
I found that if using the latest version of Pygame module, the behavior is not what I expected. The display will recreate on each frame rather than re-render. A GIF shows exactly how it perform:
Recreating the problem
- platform: Ubuntu 20.04
- Pygame 2.1.2
Solutions
While downgrading to Pygame 1.9.6 solves the problem, I'm a little curious about why is this happening. So I looked into the implementation of multi_view_render in render.py
macad-gym/src/macad_gym/viz/render.py
Lines 31 to 33 in bf40a53
It seems to me that the display is reinitialized on each call (I'm not familiar with pygame that much, hopefully I'm not wrong), so I changed display into a global variable and call pygame.display.set_mode only once. By doing this, the code runs correctly even with latest version of pygame.
Is this a bug need to be addressed? Or should I ask the Pygame community to reveal the deeper reason?
Hi @Morphlng , Thank you for reporting this with details and a solution proposal!
Yes, the pygame.display.set_mode(...) can be called once to create the PyGame Surface and can be reused in subsequent frame updates to make the rendering smoother.
Please feel free to submit a PR to move the pygame.display.set_mode(...), pygame.init() (and other initialization variables) to the global scope or better convert the render into a Class with an initialization method.
Please feel free to submit a PR to move the
pygame.display.set_mode(...),pygame.init()(and other initialization variables) to the global scope or better convert the render into a Class with an initialization method.
I'm glad to do so!
But first, I need to do some further testing including multi-worker (i.e. Having multiple Env running at the same time, although I don't think you should render during training phase like that).
Another thing is that I've noticed an on-going PR #68 (comment) is almost ready for merging. This introduced some changes in render.py, I'd like to wait and test it alongside.
I tested with PyGame 2.1.2 with the latest commit on the main (master) branch. I am observing the expected behaviour on the PyGame window. Where the entire display window is updated on the flip() call smoothly without jitters. When the window is moved with mouse-drag, the render/main thread is paused.
Could you please test again with the latest commit and report?
Could you please test again with the latest commit and report?
I have tested again with the latest version, yet the problem is still the same. I have recorded more information for this problem.
1. Bug Environment
I'm using a conda environment with Python 3.8.13, related module version can be seen below.
2. Bug scene
A gif just recorded can show that the bug still exists.
I have to remove most of the frames so that the GIF can be updated to GitHub, but still, you can see that the bug still exists.
3. Fix with downgrading Pygame
With pip install pygame==1.9.6, the problem will be resolved.
So, the problem still exists, we may need some other people help us test it out. Anyway, I think refractor to a Class with proper initialization is a better solution and I'll be working on it.