Commit Graph

1 Commits

Author SHA1 Message Date
Ariel Abreu
55bafce1f1
Initial support for Metal layers and drawables
In its current state, I consider this code to be experimental and
unstable. The biggest problem is that there's currently a HUGE memory
leak somewhere (over 2GiB in under 5 seconds at 60fps). I'm committing
what I have now since I don't feel like debugging that right now and it
*does* technically work as-is.

The current approach is not great for performance: first, we render to a Metal/Vulkan
texture in the desired format then blit that to an RGBA Metal/Vulkan
texture shared with
OpenGL. Then, we copy *that* to another OpenGL texture in CAMetalLayer
to use as the content for the layer (we can't keep the drawable's OpenGL
texture, since that has to be recycled). Finally, this is rendered to a
subwindow by CARenderer/CALayerContext. We cannot get rid of the last copy
since we must render to the subwindow somehow and it's the easiest
way to play nice with sublayers. I also don't think we can get rid of the
first copy since OpenGL doesn't support some of Metal/Vulkan's texture
formats; plus, we can't share optimally tiled images between Vulkan and
OpenGL with some vendors' drivers (e.g. AMD).
We *could* get rid of the second copy if we were able to accurately
determine when the content is finally presented; then we could simply
keep the drawable in-use, render it to the subwindow when asked to, and
release it once we know the render is complete.
2023-04-06 10:04:49 -04:00