PixelObservationWrapper: suppress render window

[biggzlar]

Is this implemented already? I did not find any documentation about how to suppress the actual rendering when using PixelObservationWrapper on either box2d or mujoco environments.

[pzhokhov]

@biggzlar you mean render(mode='rgb_array' ) such that no extra windows show up on the screen? I don't think we ever engineered for that. Other than the small nuisance of the new windows, what is the harm in the actual rendering?

[biggzlar]

The only issue is that you can't run these in headless environments. Not sure if that is feasible with the current wrapper, but that would be a valuable addition, I believe.

[biggzlar]

Additionally, although these might be corner cases:

• on the machine I use to prototype, rendering an atari environment during training adds about 0.5 seconds to each training step (128 timesteps in single environment). That's about a 25% increase in time spent on every update. For LunarLander it seems to be even more inefficient. I can't compare it directly since there's no way to run the pixel environment without rendering but every iteration takes ~15 seconds as opposed to ~2.5 in atari.

• this is more of a general problem and more related to matplotlib, but I am having trouble plotting and saving graphs after rendering gym environments. Usually python just crashes when I try.

[pzhokhov]

The issue of headless environments - sure you can! use xfvb-run, or xvfb daemon (here's an example of how we use it in the gym to run CI on the environments:
https://github.com/openai/gym/blob/master/bin/docker_entrypoint
and
https://github.com/openai/gym/blob/master/py.Dockerfile#L24

The issue of rendering speed - you are right, the atari to lunar lander comparison is not a very fair one (engine is different, rendering is different etc). Which is not to say LunarLander cannot possibly be optimized to run faster - it probably can; however, to my knowledge rendering and stepping of lunarlander are rarely a bottleneck. Those 15s / iteration - what iteration do you mean?

Matplotlib crashing - that's an interesting one (although I suspect that's indeed pyglet or matplotlib issue)... Could you provide more details? I ran

(gym) peterz-macbook:gym peterz$ python
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot as plt
>>> import gym
>>> env = gym.make('LunarLander-v2')
/Users/peterz/dev/gym/gym/logger.py:30: UserWarning: WARN: Box bound precision lowered by casting to float32
  warnings.warn(colorize('%s: %s'%('WARN', msg % args), 'yellow'))
>>> env.reset()
array([ 0.00685616,  1.4052299 ,  0.6944416 , -0.2529169 , -0.0079378 ,
       -0.15730134,  0.        ,  0.        ], dtype=float32)
>>> img = env.render(mode='rgb_array')
2019-12-21 16:36:03.220 Python[42097:528016535] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to (null)
>>> plt.imshow(img)
<matplotlib.image.AxesImage object at 0x123062080>
>>> plt.show()

and it worked fine (venv python 3.7 , osx 10.14.6, pyglet==1.3.3, matplotlib==3.1.1)