It seems you can access underlying meshes from a detached Painter2D via its DetachedAllocator.meshes. Well, may still need a little reflection there, but at least the MeshWriteDatas are being tracked.
To access the meshes when the Painter2D is attached to MeshGenerationContext, should I just reflect my way to get to UIRStylePainter.m_MeshWriteDataPool? Is there any simpler/public way to access the underlying mesh(es)?
Why do you want to access the mesh?
I need to calculate the bounds of whatever that has been drawn so far (i.e. the lhs1 and lhs2 calculations in Painter2D.SaveToVectorImage()).
Having access to the meshes (for both Painter2D and UIRStylePainter) is also great for debugging, perf tuning, and visualization at runtime.
We purposely chose to not expose any public API yet because we have many planned changes (e.g. custom shaders), and backwards compatibility requirements would slow us down significantly. I wouldn’t recommend to rely on internal APIs through reflection because these tools might break without notice from one version to the next (even from one patch version to the next).
For example, UIRStylePainter has been refactored and doesn’t exist anymore in the current alpha: any reflection on it would break. Also, in 23.2 we’ll most likely jobify the mesh generation, so DetachedAllocator might undergo a significant overhaul. Of course if you stick to a given version of Unity, these downsides might not be a problem.
That being said, did you consider using some sort of wrapper for Painter2D to store the bounds as you use the painter?
Thanks for the heads-up. I appreciate it.
From an end-user perspective, I feel that MeshGenerationContext should be the one to track and provide access to the underlying meshes. Maybe I’ll poke here again when Vector API becomes more mature.
I’ll stick to reflection for now. I did consider the wrapper approach, but it seems to be too much effort for me, especially for maintaining parity with more complex shapes/usages. 