I’ve noticed that most gizmo’s are coded in C but I noticed that a recent patch was coded in Python, see D3804.
Is there a general preference going forward for Python based gizmo’s and tools or is this left to the developer to choose?
This is the first time I have seen the use of the bpy.types.GizmoGroup in a python script. I have been curious to see how this will work for add-ons. It appears that the majority of the Gizmo shapes will be added to the C Code, but Add-on developers will be able to create their own Gizmo Groups with Python.
I am looking forward to some documentation and more examples to be available.
Maybe @ideasman42 has better-defined guidelines for this. But as far as I know we generally write operators in Python if it’s simpler and not much impacted by slower Python performance. So if drawing the gizmo involves looping over all vertices in a potentially high poly mesh for every redraw, maybe it’s better to write in C.
The Python API for gizmo’s is fairly complete, it’s just not as well tested as the C code,
there are templates - see “Gizmo Custom Geometry”.
One area that’s missing is the ability for a gizmo’s poll() function to unlink it’s self when poll fails, this is used in C quiet often as a way to remove the gizmo when switching tools.
Regarding speed - as long as you’re drawing static shapes, the speed from Python will be about the same as from C, since the geometry is sent to the GPU and re-used. If you need different geometry every redraw this is going to be slow from Python.
As Brecht notes, if you’re looping over many vertices when drawing the gizmo, it’s going to be slower from Python.
That’s useful information about the template.
I’m assuming this equally applies to tools too?
Only as much as the tool relies on gizmos, other parts of the tool system rely on operators and keymaps which work well from Python.