-
Notifications
You must be signed in to change notification settings - Fork 34
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
Investigate if canvas can be ported over to use NAPI #41
Comments
I've looked into this somewhat. The canvas package appears to be a fairly typical use of NAN, and porting to NAPI should be mostly straightforward. I see just two issues to consider:
I'll work more on porting the canvas package to NAPI after the accessor support is implemented, since there's not much point in trying to do it without accessors. |
I completed a first pass of porting the For this purpose I put together a build of NAPI that includes the property accessors and instanceof changes that are in review, since those APIs are heavily used by the canvas code. Following is a list of additional issues I encountered during the porting effort:
So far 65 of 79 canvas unit tests are passing, as well as a majority of the visual tests. The failing tests are mostly due to a few blocks of commented-out in the port dealing with typed arrays. |
This could be made a no-op on other implementations, especially since it's not of existential importance. |
I opened new issues for I think I'll just submit some PRs for I'm closing this issue now since we consider the investigation to be completed. |
Are the async functions in use? No crashes? |
At VM Summit 2 - some concern was raised if the current NAPI design can accommodate porting
canvas
.The text was updated successfully, but these errors were encountered: