They do use cairo for rendering to a CGContext via cairo_quartz_surface_t which has traditionally not been all that great on macOS. Additionally they're dealing with colorspace transforms on more recent macOS along with some bugs in macOS that were causing non-native applications to do considerable damage/redraws.
If/when Inkscape moves to GTK 4, a lot of this will just go away. The new macOS backend (which I wrote) is considerably faster and defaults to using the OpenGL renderer (which I also write a large portion of) but is also considerably faster when using Cairo by removing Quartz/CGContext from the equation and using Pixman directly with IOSurface.
When using OpenGL, however, we have to emulate something like eglSwapBuffersWithDamage() to keep the compositor from over-compositing, but that was done with tessellation just fine.
Maybe if someone comes along to write one or we get a multi-backend shader compiler so it doesn't explode the number of shaders we have to write and optimize.
But honestly, it doesn't matter. Apple just shipped a new OpenGL for M systems and every major browser is using GL more than ever. It's not going anywhere. And even if it did, we have a Vulkan backend that can target MoltenVK as well as Mesa's Zink already supporting at least OpenGL 4.6 which could also be run on MoltenVK with very little overhead.
Mac's generally have a HiDPI screen so they shouldn't be affected by the issue you're parroting.
That said, I already wrote GLyphy integration for GTK 4 and it may land before 4.8. It can significantly improve font rendering quality by drawing the glyphs on the GPU rather than from CPU drawings uploaded into an atlas which is pixel boundary bound.
It's very unclear to me wether hidpi makes the non-subpixel rendering bearable or wether the rendering would still be better if it exploited subpixel antialiasing on 4K, it's just that the perceived difference is smaller and good enough.
I don't know.
