Repository: pyqtgraph/pyqtgraph

Issue:
GLMeshItem memory leak in drawing of faces
### Short description
When rendering faces, there appears to be a memory leak relating to line 199 and 200 of GLMeshItem.py

### Code to reproduce
This can be reproduced using the GLMeshItem example script. Using top to check memory usage, the amount used by the process slowly increases as updates are called in the scene (triggered by rotating the view, etc.). If there are no changes the memory usage is constant, but otherwise will grow without bound (albeit slowly in the example). Larger meshes with cause faster accumulation.

### Expected behavior
Near-constant memory usage when rendering the faces in the scene.

### Real behavior
Increasing memory usage when rendering faces.

### Tested environment(s)

 * PyQtGraph version: tested on both 0.11.0 and 0.12.1
 * Qt Python binding:  5.15.4
 * Python version: 3.8
 * NumPy version: 1.17.3
 * Operating system: Ubuntu 20.04
 * Installation method: pip

### Additional context
changing astype on faces from np.uint to np.uint32 or np.uintc on line 199 of pyqtgraph/opengl/items/GLMeshItem.py resolves the issue for me, but I don't know if that is the correct solution.



Discussion:
I wasn't able to observe any long running increase in memory usage neither in Windows 10 64-bits nor in Ubuntu 20.04 64-bits.

Regardless, np.uint is 32-bits on Windows 64-bits (LLP64) but is 64-bits on Linux 64-bits (LP64). Which means that on Linux platforms, PyOpenGL would need to further convert it to 32-bits in order to make it usable as GL_UNSIGNED_INT (32-bits).
To see the increase, repainting the scene is required. For GLMeshItem example script, I constantly orbited the camera to force repaints, but the long running increase is quite slow for the example. For my application with large mesh and constant updates, it's much more noticeable. This was on Ubuntu 20.04 64-bits.

Regardless, it sounds like pyqtgraph is expecting glDrawElements to do the appropriate conversion on their end, and this is an issue with PyOpenGl, not pyqtgraph. Is that accurate?

>To see the increase, repainting the scene is required. For GLMeshItem example script, I constantly orbited the camera to force repaints, but the long running increase is quite slow for the example.

Yes, I did rotate the scene continuously. What I observed on Ubuntu 20.04 64-bits was that memory usage increased slightly by a bit and then stabilized. But given that OpenGL runs on different hardware and drivers, it would not be surprising that the effect is appearing on your system but not mine.

>Regardless, it sounds like pyqtgraph is expecting glDrawElements to do the appropriate conversion on their end, and this is an issue with PyOpenGl, not pyqtgraph. Is that accurate?

I _think_ the intent of pyqtgraph was to have created a buffer that could be used directly without further conversion. In this regard, ```np.uint``` would be the wrong choice since it corresponds to a ```c_long```, which is 32-bits on Windows 64-bits but 64-bits on Linux 64-bits.

While the issue may technically lie with PyOpenGL, it is pyqtgraph that is triggering it.
Given that a change to ```np.uint32``` solves your problem (and it would remove an inefficiency on Linux 64-bits), you could make a PR for it.

Resolving patch:
diff --git a/pyqtgraph/opengl/items/GLMeshItem.py b/pyqtgraph/opengl/items/GLMeshItem.py
--- a/pyqtgraph/opengl/items/GLMeshItem.py
+++ b/pyqtgraph/opengl/items/GLMeshItem.py
@@ -196,7 +196,7 @@ def paint(self):
                     if faces is None:
                         glDrawArrays(GL_TRIANGLES, 0, np.product(verts.shape[:-1]))
                     else:
-                        faces = faces.astype(np.uint).flatten()
+                        faces = faces.astype(np.uint32).flatten()
                         glDrawElements(GL_TRIANGLES, faces.shape[0], GL_UNSIGNED_INT, faces)
                 finally:
                     glDisableClientState(GL_NORMAL_ARRAY)


Test patch: