Almar Klein
Almar Klein
Yeah, so that part would consists of: * Adding a build for linux-aarch64 on wgpu-native. Can do that on a fork first, and test it, before submitting an actual PR....
Yes, and no. Kvark had already made the necessary updates to wgpu-native. But the arm build was not really a succes.
This can be useful: https://www.python.org/dev/peps/pep-0646/
Also see a relevant discussion in vispy: https://github.com/vispy/vispy/issues/1400
Some ideas (without haven given it much thought): * `MeshMaterial.cap_color` (default transparent). * `Mesh.cap_material` next to `Mesh.material`. * Expose stencil buffer options such that people can implement caps themselves.
We indeed chose to not automatically make arrays contiguous. In part because of the overhead, but also because if you do something like: ```py array = ... buffer = gfx.Buffer(array)...
I've only played with poetry a bit so far. What would switching imply? E.g. what changes for CI?
My only worry is that we'd be forcing poetry on everybody how wants to contribute to pygfx (is it?). It may be simpler, but its another thing to learn for...
We added textrendering using text overlays with Qt, as an example, in #56
With the 3d part you mean e.g. the kerning etc. right? In visvis I used Freetype for step 1 and 3, and it looks like vispy does the same, via...