-
Notifications
You must be signed in to change notification settings - Fork 123
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
Reimplement the Canvas transformation functions #724
Conversation
61f7f23
to
8a83c49
Compare
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.
Could you please post your benchmark / measurements for both JVM and native?
The improvement I saw was in the "Color Sparks" benchmark from the Fleet team. It's just a huge amount of small nodes that redraw each frame. I don't think it's particularly important to "prove" the performance improvement in this case because this particular change doesn't really have a chance to make it worse. Plus, it makes sense regardless of performance. |
a9c01ca
to
19c4114
Compare
It does. Native calls might be expensive 1 2
|
19c4114
to
288c143
Compare
@MatkovIvan Indeed, but this PR replaces a call to |
8a83c49
to
1f3f353
Compare
… Skia functions, rather than by concatenating with a transformation matrix.
1f3f353
to
b8562d8
Compare
via the corresponding Skia functions directly, rather than by concatenating with a transformation matrix.
This appears to be significantly faster. Specifically in Compose, the canvas is translated for every node twice (by its position, and then back). Changing the
translate
function to perform a direct call to Skia transform makes drawing simple nodes much faster.