killed due to memory leak in OffscreenRenderer

[spookycouch]

Checklist

• I have searched for similar issues.
• For Python issues, I have tested with the latest development wheel.
• I have checked the release documentation and the latest documentation (for main branch).

Describe the issue

I am running an application where the OffscreenRenderer is created in a function, and the function is called multiple times.

The renderer itself is run headless on a CPU.

Using top, I was able to observe that the memory use of the application increases each time a new renderer is created and an image is rendered, and memory does not appear to be freed even when the scope of the function/loop is left. The memory usage steadily grows with each function call until there is no available memory and the python script is killed.

This appears to be the same issue in #5596, and the workaround is to create and run the renderer in a multiprocessing Process such that memory is de-allocated once the process exits.

I was able to reproduce the bug consistently in a for-loop below with the env EGL_PLATFORM="surfaceless":

Steps to reproduce the bug

import open3d as o3d
for _ in range(100):
    cloud = o3d.geometry.TriangleMesh.create_box(0.1,0.1,0.1)
    render = o3d.visualization.rendering.OffscreenRenderer(1000,1000)
    material_record = o3d.visualization.rendering.MaterialRecord()
    render.scene.add_geometry("hi", cloud, material_record)
    rgb = render.render_to_image()
    del cloud
    del render
    del material_record
    del rgb

Error message

[Open3D INFO] EGL headless mode enabled.
FEngine (64 bits) created at 0x7fccd0298f40 (threading is enabled)
EGL(1.5)
OpenGL(4.5)
Killed

Expected behavior

No memory leaks - memory should be freed when the scope of the renderer is exited.

Open3D, Python and System information

- Operating system: Ubuntu 20.04
- Python version: Python 3.8.10
- Open3D version: 0.18.0
- System architecture: x86_64
- Is this a remote workstation?: no
- How did you install Open3D?: pip

Additional information

The suggestion to use a shared renderer in #4480 is not applicable in this case as the function is called on a server (multi-threaded) and renders images of arbitrary width/height