internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: vispy/vispy

Issue:
Low fps with high-frequency mouse
If mouse frequency is set to 1000Hz (for a specialized gaming mouses), the rendering speed falls dramatically for vispy-widgets that use scene graph.

Moving a 125Hz mouse around: 80-120 fps
Moving a 1000Hz mouse around: 5-20 fps

Code:

``` python
import numpy as np
from vispy import app, scene
from vispy.visuals import MarkersVisual

app.use_app("PyQt4")
canvas = scene.SceneCanvas(show=True)
canvas.measure_fps()

view = canvas.central_widget.add_view()
view.camera = 'panzoom'
view.camera.rect = (0, 0, 800, 800)

Markers = scene.visuals.create_visual_node(MarkersVisual)
vis = Markers()
vis.set_data(np.array([[100, 100, 0], [400, 100, 0], [400, 400, 0], [100, 400, 0]], dtype=np.float32))
view.add(vis)
app.run()
```



Discussion:

Resolving patch:
diff --git a/vispy/app/base.py b/vispy/app/base.py
--- a/vispy/app/base.py
+++ b/vispy/app/base.py
@@ -4,6 +4,7 @@
 
 from ..util import SimpleBunch
 import time
+from timeit import default_timer
 
 
 class BaseApplicationBackend(object):
@@ -60,6 +61,7 @@ def __init__(self, vispy_canvas):
         from .canvas import Canvas  # Avoid circular import
         assert isinstance(vispy_canvas, Canvas)
         self._vispy_canvas = vispy_canvas
+        self._last_time = 0
 
         # We set the _backend attribute of the vispy_canvas to self,
         # because at the end of the __init__ of the CanvasBackend
@@ -186,6 +188,10 @@ def _vispy_mouse_press(self, **kwargs):
         return ev
 
     def _vispy_mouse_move(self, **kwargs):
+        if default_timer() - self._last_time < .01:
+            return
+        self._last_time = default_timer()
+
         # default method for delivering mouse move events to the canvas
         kwargs.update(self._vispy_mouse_data)
 


Test patch:
Repository: vispy/vispy

Issue:
Using wxPython 4.0.0b2 problem
```
Python 3.5.3 (default, Sep  7 2017, 16:23:57) 
[GCC 6.3.0 20170406] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vispy
>>> vispy.use('wx')
>>> print(vispy.sys_info())
Platform: Linux-4.10.0-35-generic-x86_64-with-Ubuntu-17.04-zesty
Python:   3.5.3 (default, Sep  7 2017, 16:23:57)  [GCC 6.3.0 20170406]
NumPy:    1.13.1
Backend:  wx
pyqt4:    None
pyqt5:    None
pyside:   ('PySide', '1.2.2', '4.8.7')
pyglet:   None
glfw:     None
sdl2:     sdl2 0.9.3
wx:       wxPython 4.0.0b2
egl:      None
osmesa:   OSMesa
_test:    None

App info-gathering error:
Traceback (most recent call last):
  File "/home/eldar/src/vispy/vispy/util/config.py", line 432, in sys_info
    canvas = Canvas('Test', (10, 10), show=False, app=app)
  File "/home/eldar/src/vispy/vispy/app/canvas.py", line 205, in __init__
    self.create_native()
  File "/home/eldar/src/vispy/vispy/app/canvas.py", line 222, in create_native
    self._app.backend_module.CanvasBackend(self, **self._backend_kwargs)
  File "/home/eldar/src/vispy/vispy/app/backends/_wx.py", line 227, in __init__
    p.size, style)
TypeError: Frame(): arguments did not match any overloaded call:
  overload 1: too many arguments
  overload 2: argument 4 has unexpected type 'NoneType'
```


Discussion:

Resolving patch:
diff --git a/vispy/app/backends/_wx.py b/vispy/app/backends/_wx.py
--- a/vispy/app/backends/_wx.py
+++ b/vispy/app/backends/_wx.py
@@ -218,13 +218,19 @@ def __init__(self, *args, **kwargs):
         else:
             self._gl_context = p.context.shared.ref._gl_context
 
+        if p.position is None:
+            pos = wx.DefaultPosition
+        else:
+            pos = p.position
+
         if p.parent is None:
             style = (wx.MINIMIZE_BOX | wx.MAXIMIZE_BOX | wx.CLOSE_BOX |
                      wx.SYSTEM_MENU | wx.CAPTION | wx.CLIP_CHILDREN)
             style |= wx.NO_BORDER if not p.decorate else wx.RESIZE_BORDER
             style |= wx.STAY_ON_TOP if p.always_on_top else 0
-            self._frame = wx.Frame(None, wx.ID_ANY, p.title, p.position,
-                                   p.size, style)
+            self._frame = wx.Frame(None, wx.ID_ANY, p.title, pos, p.size,
+                                   style)
+
             if not p.resizable:
                 self._frame.SetSizeHints(p.size[0], p.size[1],
                                          p.size[0], p.size[1])
@@ -245,7 +251,7 @@ def __init__(self, *args, **kwargs):
             self._frame = None
             self._fullscreen = False
         self._init = False
-        GLCanvas.__init__(self, parent, wx.ID_ANY, pos=p.position,
+        GLCanvas.__init__(self, parent, wx.ID_ANY, pos=pos,
                           size=p.size, style=0, name='GLCanvas',
                           attribList=self._gl_attribs)
 


Test patch:
Repository: vispy/vispy

Issue:
wxPython 4 deprecated call
```
Python 3.5.3 (default, Sep  7 2017, 16:23:57) 
[GCC 6.3.0 20170406] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vispy
>>> vispy.use('wx')
>>> print(vispy.sys_info())
Platform: Linux-4.10.0-35-generic-x86_64-with-Ubuntu-17.04-zesty
Python:   3.5.3 (default, Sep  7 2017, 16:23:57)  [GCC 6.3.0 20170406]
NumPy:    1.13.1
Backend:  wx
pyqt4:    None
pyqt5:    None
pyside:   ('PySide', '1.2.2', '4.8.7')
pyglet:   None
glfw:     None
sdl2:     sdl2 0.9.3
wx:       wxPython 4.0.0b2
egl:      None
osmesa:   OSMesa
_test:    None
```
Warning:
```
/home/eldar/src/vispy/vispy/app/backends/_wx.py:131: wxPyDeprecationWarning: Using deprecated class EventLoop. Use GUIEventLoop instead.
  self._event_loop = wx.EventLoop()
```


Discussion:

Resolving patch:
diff --git a/vispy/app/backends/_wx.py b/vispy/app/backends/_wx.py
--- a/vispy/app/backends/_wx.py
+++ b/vispy/app/backends/_wx.py
@@ -128,7 +128,7 @@ class ApplicationBackend(BaseApplicationBackend):
 
     def __init__(self):
         BaseApplicationBackend.__init__(self)
-        self._event_loop = wx.EventLoop()
+        self._event_loop = wx.GUIEventLoop()
         wx.EventLoop.SetActive(self._event_loop)
 
     def _vispy_get_backend_name(self):


Test patch:
Repository: vispy/vispy

Issue:
examples/tutorial/app/simple_wx.py issue
```
Traceback (most recent call last):
  File "simple_wx.py", line 58, in <module>
    frame = TestFrame()
  File "simple_wx.py", line 49, in __init__
    self.canvas = Canvas(app="wx", parent=self, show=True)
  File "simple_wx.py", line 20, in __init__
    app.Canvas.__init__(self, *args, **kwargs)
  File "/home/eldar/src/vispy/vispy/app/canvas.py", line 208, in __init__
    self.set_current()
  File "/home/eldar/src/vispy/vispy/app/canvas.py", line 406, in set_current
    self._backend._vispy_set_current()
  File "/home/eldar/src/vispy/vispy/app/backends/_wx.py", line 302, in _vispy_set_current
    self.SetCurrent(self._gl_context)
wx._core.wxAssertionError: C++ assertion "xid" failed at /home/eldar/src/wx/wxPython_Phoenix/wxPython-4.0.0b2/ext/wxWidgets/src/unix/glx11.cpp(194) in SetCurrent(): window must be shown
```


Discussion:
I assumed with your previous PRs that you had gotten a working Canvas with wx. Did something change?
@davidh-ssec It isn't related bug.

Resolving patch:
diff --git a/examples/tutorial/app/simple_wx.py b/examples/tutorial/app/simple_wx.py
--- a/examples/tutorial/app/simple_wx.py
+++ b/examples/tutorial/app/simple_wx.py
@@ -43,15 +43,20 @@ def __init__(self):
         file_menu = wx.Menu()
         file_menu.Append(wx.ID_EXIT, "&Quit")
         self.Bind(wx.EVT_MENU, self.on_quit, id=wx.ID_EXIT)
+        self.Bind(wx.EVT_SHOW, self.on_show)
         MenuBar.Append(file_menu, "&File")
         self.SetMenuBar(MenuBar)
 
-        self.canvas = Canvas(app="wx", parent=self, show=True)
+        self.canvas = Canvas(app="wx", parent=self)
 
     def on_quit(self, event):
         self.canvas.stop_timer()
         self.Close(True)
 
+    def on_show(self, event):
+        self.canvas.show()
+        event.Skip()
+
 
 if __name__ == '__main__':
     myapp = wx.App(0)


Test patch:
Repository: vispy/vispy

Issue:
Sphere.py rows and cols wrong way round
Hi,

Might be wrong, but it looks like in vispy/visuals/Sphere.py, when passing rows and cols to create_sphere, they are passed back to front. create_sphere expects rows then cols, but SphereVisual passes cols then rows. As they're unnamed, I was producing different meshes than I expected.

Thanks



Discussion:

Resolving patch:
diff --git a/vispy/geometry/generation.py b/vispy/geometry/generation.py
--- a/vispy/geometry/generation.py
+++ b/vispy/geometry/generation.py
@@ -403,7 +403,7 @@ def midpoint(v1, v2):
 
 def _cube(rows, cols, depth, radius):
     # vertices and faces of tessellated cube
-    verts, faces, _ = create_box(1, 1, 1, rows, cols, depth)
+    verts, faces, _ = create_box(1, 1, 1, cols, rows, depth)
     verts = verts['position']
 
     # make each vertex to lie on the sphere
diff --git a/vispy/visuals/sphere.py b/vispy/visuals/sphere.py
--- a/vispy/visuals/sphere.py
+++ b/vispy/visuals/sphere.py
@@ -47,7 +47,7 @@ def __init__(self, radius=1.0, cols=30, rows=30, depth=30, subdivisions=3,
                  method='latitude', vertex_colors=None, face_colors=None,
                  color=(0.5, 0.5, 1, 1), edge_color=None, **kwargs):
 
-        mesh = create_sphere(cols, rows, depth, radius=radius,
+        mesh = create_sphere(rows, cols, depth, radius=radius,
                              subdivisions=subdivisions, method=method)
 
         self._mesh = MeshVisual(vertices=mesh.get_vertices(),


Test patch:
Repository: vispy/vispy

Issue:
Wrong install location for docs
From `setup.py`:
```
setup(
   [...]
    package_data={
        'vispy': [op.join('io', '_data', '*'),
                  op.join('html', 'static', 'js', '*'),
                  op.join('app', 'tests', 'qt-designer.ui'),
                  op.join('..', 'doc', '*'),
                  ],
```
This line `op.join('..', 'doc', '*')` is wrong for a system-wide install. It leads to the documentation being install under `dist-packages` or `site-packages`, which is definitely non-standard. IMO, the best would be to just not install the docs yourself, and let the package build system (conda or Debian) handle it.


Discussion:
Hm I thought I had tested this before committing it and that it was going in the vispy directory. I had added that line to include the `doc` directory in the PyPI tarball for your Debian packaging. What would be the proper way to add the `doc` directory to `setup.py` for your packaging?
As far as I can tell there is no proper way to add a directory *outside* the package directory to be inside the package directory. I would have to move the `doc` submodule (or symlink it) to inside the package. @ghisvail my understanding was that you needed the `doc` directory in PyPI, is that correct?

Edit: The only other way I see for uploading documentation to PyPI is with `upload_sphinx` which puts it on pythonhosted.org.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -109,7 +109,6 @@ def package_tree(pkgroot):
         'vispy': [op.join('io', '_data', '*'),
                   op.join('html', 'static', 'js', '*'),
                   op.join('app', 'tests', 'qt-designer.ui'),
-                  op.join('..', 'doc', '*'),
                   ],
 
         'vispy.glsl': ['*.vert','*.frag', "*.glsl"],


Test patch:
Repository: vispy/vispy

Issue:
Camera API documentation missing
I could not find a list of available cameras in the docs:

http://vispy.org/scene.html?highlight=cameras#module-vispy.scene.cameras



Discussion:

Resolving patch:
diff --git a/vispy/scene/cameras/__init__.py b/vispy/scene/cameras/__init__.py
--- a/vispy/scene/cameras/__init__.py
+++ b/vispy/scene/cameras/__init__.py
@@ -15,6 +15,9 @@
 that a certain part of the scene is mapped to the bounding rectangle of the 
 ViewBox.
 """
+__all__ = ['ArcballCamera', 'BaseCamera', 'FlyCamera', 'MagnifyCamera',
+           'Magnify1DCamera', 'PanZoomCamera', 'TurntableCamera']
+
 from ._base import make_camera  # noqa
 from .base_camera import BaseCamera  # noqa
 from .panzoom import PanZoomCamera  # noqa


Test patch:
Repository: vispy/vispy

Issue:
Alignment wrong computation when aligned on 8 bytes
Hello,

While reviewing code in vispy/glir.py I found this comment that looks erroneous:

```
# we know the alignment is appropriate
# if we can divide the width by the
# alignment cleanly
# valid alignments are 1,2,4 and 8
# put 4 first, since it's the default
alignments = [4, 8, 2, 1]
for alignment in alignments:
    if width % alignment == 0:
        return alignment
```

the issue is that if width is multiple of 8 then the alignment returned will always be 4... since it is always multiple of 4 too.

So either either remove the "8" case for speed or define alignment to [8,4,2,1].

Laurent



Discussion:
Good point. I think this piece of code is originally from PyGLy so @adamlwgriffiths might want to know about this.  Also cc @rougier.

Using 4 rather than 8 is not a problem, only potentially, using 8 when possible could be faster. So should we ditch the 8 or put 8 first? 

Not sur e I've anything to say on that. What is the context for such alignment ?

It's the alignment of elements for texture upload, and similar code is used in taking screenshots.

> Using 4 rather than 8 is not a problem, only potentially, using 8 when possible could be faster. So should we ditch the 8 or put 8 first?

Can't we just have `alignments = [8, 4, 2, 1]`? The performance impact is in the 1 percent range, seemingly insignificant. Anyway `alignments = [4, 8, 2, 1]` doesn't make sense at all. 


Yes let's do 8/4/2/1 and see if anything breaks

Resolving patch:
diff --git a/vispy/gloo/glir.py b/vispy/gloo/glir.py
--- a/vispy/gloo/glir.py
+++ b/vispy/gloo/glir.py
@@ -1041,8 +1041,8 @@ def _get_alignment(self, width):
         # if we can divide the width by the
         # alignment cleanly
         # valid alignments are 1,2,4 and 8
-        # put 4 first, since it's the default
-        alignments = [4, 8, 2, 1]
+        # 4 is the default
+        alignments = [8, 4, 2, 1]
         for alignment in alignments:
             if width % alignment == 0:
                 return alignment


Test patch:
Repository: vispy/vispy

Issue:
GLFW glfw.glfwSetWindowTitle issue
Hello there, 
I am using a library https://github.com/p5py/p5 which is dependent on vispy. When passing a new title as str to glfw.glfwSetWindowTitle only the first letter of the passed string is coming up as the changed title. I was able to find a workaround to this by passing the title by encoding it to utf-8 in
https://github.com/vispy/vispy/blob/0ff2bacef0ec941c039708935a4cbd694ecf02ab/vispy/app/backends/_glfw.py#L327
 like the implementation in
https://github.com/vispy/vispy/blob/0ff2bacef0ec941c039708935a4cbd694ecf02ab/vispy/ext/glfw.py#L483

Now I am confused wether to make a pull request to p5py or vispy about this issue as p5py is accepting title as str. 
Thank You


Discussion:

Resolving patch:
diff --git a/vispy/app/backends/_glfw.py b/vispy/app/backends/_glfw.py
--- a/vispy/app/backends/_glfw.py
+++ b/vispy/app/backends/_glfw.py
@@ -324,7 +324,7 @@ def _vispy_set_title(self, title):
         if self._id is None:
             return
         # Set the window title. Has no effect for widgets
-        glfw.glfwSetWindowTitle(self._id, title)
+        glfw.glfwSetWindowTitle(self._id, title.encode('utf-8'))
 
     def _vispy_set_size(self, w, h):
         if self._id is None:


Test patch:
Repository: vispy/vispy

Issue:
Load STL files into vispy
Hi there, I think  I found a bug in vispy/vispy/io/mesh.py  in col 42:
mesh = load_stl(fname)
when I try to import a  *.stl file by read_mesh(fname), an error occured like this: 
 File "D:\Python3.5\lib\site-packages\vispy\io\mesh.py", line 43, in read_mesh
    mesh = load_stl(fname)
  File "D:\Python3.5\lib\site-packages\vispy\io\stl.py", line 43, in load_stl
    file_pos = file_obj.tell()
AttributeError: 'str' object has no attribute 'tell'
by change col42 into :mesh = trimesh.load(fname), problem soved!



Discussion:

Resolving patch:
diff --git a/vispy/io/mesh.py b/vispy/io/mesh.py
--- a/vispy/io/mesh.py
+++ b/vispy/io/mesh.py
@@ -39,10 +39,11 @@ def read_mesh(fname):
     if fmt in ('.obj'):
         return WavefrontReader.read(fname)
     elif fmt in ('.stl'):
-        mesh = load_stl(fname)
-        vertices = mesh.vertices
-        faces = mesh.faces
-        normals = mesh.face_normals
+        file_obj = open(fname, mode='rb')
+        mesh = load_stl(file_obj)
+        vertices = mesh['vertices']
+        faces = mesh['faces']
+        normals = mesh['face_normals']
         texcoords = None
         return vertices, faces, normals, texcoords
     elif not format:


Test patch:
Repository: vispy/vispy

Issue:
XYZAxisVisuals Override Defaults
It looks like XYZAxisVisual is not overridable in the **init** function for the verts and color arguments?  Passing in `pos=my_custom_verts` results in `TypeError: __init__() got multiple values for keyword argument 'pos'`.

The `**kwds` argument looks like it is being passed through to the Line class, via LineVisual.  Does a method exist to specify the verts, color, and / or connect kwargs?  I am hesitant to submit a PR modifying **kwds since I am not 100% sure how the passing is working.



Discussion:
@jlaura if you're still interested in this, we have started making it so that the kwargs are explicitly specified, so you could make the changes you wanted. If you don't have time let me know and I might be able to do it. (Sorry for the loooong delay.)


Resolving patch:
diff --git a/vispy/visuals/xyz_axis.py b/vispy/visuals/xyz_axis.py
--- a/vispy/visuals/xyz_axis.py
+++ b/vispy/visuals/xyz_axis.py
@@ -10,17 +10,24 @@ class XYZAxisVisual(LineVisual):
     x=red, y=green, z=blue.
     """
     def __init__(self, **kwargs):
-        verts = np.array([[0, 0, 0],
-                          [1, 0, 0],
-                          [0, 0, 0],
-                          [0, 1, 0],
-                          [0, 0, 0],
-                          [0, 0, 1]])
+        pos = np.array([[0, 0, 0],
+                        [1, 0, 0],
+                        [0, 0, 0],
+                        [0, 1, 0],
+                        [0, 0, 0],
+                        [0, 0, 1]])
         color = np.array([[1, 0, 0, 1],
                           [1, 0, 0, 1],
                           [0, 1, 0, 1],
                           [0, 1, 0, 1],
                           [0, 0, 1, 1],
                           [0, 0, 1, 1]])
-        LineVisual.__init__(self, pos=verts, color=color, connect='segments',
-                            method='gl', **kwargs)
+        connect = 'segments'
+        method = 'gl'
+
+        kwargs.setdefault('pos', pos)
+        kwargs.setdefault('color', color)
+        kwargs.setdefault('connect', connect)
+        kwargs.setdefault('method', method)
+
+        LineVisual.__init__(self, **kwargs)


Test patch:
Repository: vispy/vispy

Issue:
setup.py attempts to import numpy before installing it
On master `setup.py` imports numpy on line 46 even though numpy is a dependency of vispy so it is not guaranteed it will be installed yet.

This causes `pip install git+https://github.com/vispy/vispy.git` to fail unless you already have numpy installed.


Discussion:
What is the current best practice for getting around this? I think I use this in other projects. I'll have to look it up later.
@djhoese PEP 518 was suggested for one of my projects. Works good so far. 
> @djhoese PEP 518 was suggested for one of my projects. Works good so far.

Yes. We had been struggling with this forever too in projects.
To use that put a `pyproject.toml` in your project root. Pip will then install the dependencies specified in there in an isolated environment and call the build tool to produce a wheel to install in the environment where pip was called from. 

This has some implications if you produce binary wheels for people to install that should not be ignored.

Edit: Example for the toml file: https://github.com/pymor/pymor/blob/master/pyproject.toml
Agreed `pyproject.toml` should work, see also for example how SciPy does it:

https://github.com/scipy/scipy/blob/master/pyproject.toml
I actually don't think we need to go that far unless we want cython to be installed and rebuild every extension. If this is only about the `numpy` issue I looked at how we do it in pyresample and it looks like I just copied and pasted things poorly in to vispy.

In pyresample we defined this special `build_ext` class:
https://github.com/pytroll/pyresample/blob/master/setup.py#L70-L84

We have that in vispy too:
https://github.com/vispy/vispy/blob/master/setup.py#L113

But then ignore it and manually add the numpy include directories:
https://github.com/vispy/vispy/blob/master/setup.py#L308

I think we could just remove this `include_dirs` and the numpy import at the top of setup.py.
I think if vispy is used as a dependency in a project that installs with PEP 518 mechanics, then vispy itself will be installed with build isolation in that build process. So adding the pyproject.toml would make vispy easier to use in those downstream projects. 
@renefritze You are absolutely right and not doing a pyproject.toml file is just me being stubborn.

I'll see if I can make a pull request today for it. I don't fully know everything about the PEP and anything special we need, but our build process should be simpler than scipy.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -43,7 +43,6 @@
 from setuptools.command.build_ext import build_ext as _build_ext
 from setuptools.command.egg_info import egg_info
 from subprocess import check_call
-import numpy as np
 
 
 try:
@@ -305,7 +304,6 @@ def run(self):
     },
     packages=find_packages(),
     ext_modules=cythonize(extensions),
-    include_dirs=[np.get_include()],
     package_dir={'vispy': 'vispy'},
     data_files=[
         ('share/jupyter/nbextensions/vispy', [


Test patch: