-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using a different renderer besides UIKit #5
Comments
Hi Michael, first off thanks for submitting an issue to Epoxy! In terms of supporting an alternate renderer, I would say that Epoxy is most definitely tightly coupled to UIKit for rendering, so something like an alternate renderer would be out of scope for this project as it would dramatically increase the scope of Epoxy beyond being a set of declarative adapters written atop UIKit APIs like We've found UIKit to meet our needs in terms of performance despite rendering occurring on the main thread. Auto Layout has had a number of great performance improvements over the years, and UIKit's ability to hand off most animations to the render server gives us a smooth 60 FPS in most cases. |
You might find https://github.com/TokamakUI/Tokamak interesting, which is a Swift declarative UI framework that supports custom platform-specific renderers. |
To elaborate, I agree that scrolling performance is a fairly solved problem. My concern is more around creating the views for a new screen, especially during startup. This is a case where I think everyone is dropping frames. But I understand not wanting to try a whole new renderer for this as well. |
Given the instantiation cost of UIViews and delays in rendering, both of which must be done on the main thread, it'd be cool to support an alternate renderer. It could be one that's thread-safe, does less work, or both. Perhaps Flutter's Skia would be worth playing with, which I've heard anecdotally can be faster.
The text was updated successfully, but these errors were encountered: