-
Notifications
You must be signed in to change notification settings - Fork 481
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
🏎 Background Thread Skia Rendering #254
Conversation
The rendering pipeline is now as follows: - On the main thread the app is notified that the screen will refresh - If any pending redraw requests exists, a draw operation is sent to the JS thread and executed - The draw request performs the drawing operations that are defined in Javascript code. These operations are recorded using the SkPictureRecorder class - The resulting SkPicture is passed to the render thread (separate single responsibility thread) - The GPU backends on Android/iOS will play back the drawing commands in the SkPicture using a canvas connected to the GPU surface in either Metal or OpenGL.
Can be used to optimize the reconciler to be as fast as possible compared to pure JS rendering using a SkiaView. Not sure if this screen will be kept - but it is super convinient for testing. In pure JS / SkiaView mode it renders over 2000 colored rects in 6ms spent in the JS thread and 2ms spent in the GPU/render thread.
To avoid using queues on iOS (they are a bit hard to understand, especially which / what threads they're using etc)
Now we're searching for property get first - since it is most often called. Also added some typing and made sure that we don't copy the prop/func maps.
Fixes memory growth on iOS Simulator since all Metal resources are released after use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. I'm pretty excited about this new feature. Pretty straightforward.
My only question is: could/should the SkPicture be available to be used in makeImageSnapshot
if needed?
Thanks :)
I don't think it is necessary, since when making snapshots we're able to draw directly onto a raster surface (bitmap data), so there is no need to take the route through SkPicture I think. If we find issues with the DisplacementMap that can be solved by using a more centralised route I'm of course all in :) |
I may have detected a regression. Investigating now.
Fixed so that we don't enqueue javascript drawing ops when still rendering.
Nice, will test it now |
This PR implements support for rendering on a separate background thread. The new rendering pipeline is as the following:
In addition this PR also includes a few optimisations found when profiling rendering: