Reset VertexAttribDivisor even if None

[aganders3]

Fixes #2581 - see additional discussion in that issue.

My hypothesis here is that the attr_handle is reused between the text and instanced mesh visuals, but the divisor is not properly (re)set. The single mesh does not interfere because it does not use more than handle 0, which is okay because the divisor is the same for this attribute (a_position).

Here is some debug output from GlirProgram._pre_draw showing the attribute name, handle, and divisor value. You can see the overlapping values from the Text and InstancedMesh visuals.

drawing <Text at 0x1340d6dd0>
a_color 4 None
a_position 1 None
a_texcoord 0 None
a_rotation 2 None
a_pos 3 None

drawing <Mesh at 0x1340e5310>
a_position 0 None

drawing <InstancedMesh at 0x1340e5410>
a_position 0 None
u_base_color 1 1
transform_x 5 1
transform_y 4 1
transform_z 2 1
shift 3 1

cc @brisvag @rzmearns

[djhoese]

I think I understand the idea. Looks good enough to me.

[brisvag]

Basically: OpenGL will reuse stuff like the attribute handle between visuals, and if you don't explicitly set everything you need to the right value, you end up with whatever was set elsewhere before.
LGTM!

[aganders3]

Shoot - the test failure looks legit. I don't know much about osmesa but will take a look today.

[aganders3]

Okay I think it's just a backend support issue, so I think e27e089 will at least fix the tests.

I'm not aware of a standard way of checking for support in glir.py, so I'm open to suggestion here. Should it just raise an exception if any attributes have a divisor and it's not available? If instances > 1 it will raise AttributeError: module 'vispy.gloo.gl' has no attribute 'glDrawArraysInstanced' just after this anyway.

I now understand why if divisor is not None was there to begin with :).

[brisvag]

This looks fine to me, at least it's a lot clearer what went wrong!