3 ms·
I don't know internals of SwiftUI that match but if it still using CoreGraphics then it should be slow. CoreGraphics uses CPU rasterization of primitives and t
by c-smile 4y ago
I don't know internals of SwiftUI that match but if it still using CoreGraphics then it should be slow.
CoreGraphics uses CPU rasterization of primitives and that's the problem on modern displays.
Retina grade displays have ~9 times more pixels on surface than old 96 ppi monitors. So you need 10 times more performant CPUs for rendering - CPU rasterization is O(Npix) complex - as better (resolution) monitor you have as slow your UI.
On the other side games use GPUs (Metal, OpenGL) to render primitives. In that case CPUs just generate lists of primitive definitions in vector forms (polygons, etc.). Rasterization of those primitives is done in parallel by crowd of GPU processors. Therefore, games UI is not tied with monitor resolution directly - same [display] lists are generated by CPU for any monitor resolution. In that respect GPU accelerated UI rendering is O(1) complex.
- dev_tty01 4y agoYou can directly enable the use of Metal with the drawingGroup() API. https://www.hackingwithswift.com/books/ios-swiftui/enabling-high-performance-metal-rendering-with-drawinggroup https://www.hackingwithswift.com/books/ios-swiftui/enabling-... You can also embed a UIViewRepresentable to "manually" embed a metal kit view inside a SwiftUI hierarchy. Basically use SwiftUI to manage most of it, but use metal to handle a bottleneck somewhere. Here is an example: https://developer.apple.com/forums/thread/119112 https://developer.apple.com/forums/thread/119112
- divan 4y agothat sounds reasonable, thank you
- saagarjha 4y agoVery few SwiftUI apps are bottlenecked on CoreGraphics drawing on the CPU.