feature: Support all Canvas2D APIs by wrapping CanvasRenderer in a Proxy #324
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rive-engineering
pushed a commit
that referenced
this pull request
Aug 16, 2023
Ported over from public wasm repo: #324 We recently exposed `drawImage()` support from our `CanvasRenderer`, which naturally led to seeing if we can support the rest of the Canvas2D context APIs by approaching a similar strategy (simply adding the call to our deferred `drawList`). We may be able to just return a `Proxy` from `makeRenderer()` which would intercept the calls to `CanvasRenderer` and route each API function call either to our `CanvasRenderer` if the API the user wants to call exists on it, OR the `._ctx` (the actual Canvas2D context) from `CanvasRenderer`. This should allow us to support our custom `save()`, `restore()`, `_drawImageMesh()`, etc. calls, while any non-overriden API we've wrapped in `CanvasRenderer` would go straight to the context itself. From a consumer perspective, nothing should change here. They call `const renderer = rive.makeRenderer(canvas-element)` and use `renderer.save()`, `renderer.restore()`, etc. in a render loop as expected. Diffs= 65156867f feature: wrap renderer in a Proxy to expose Canvas2d context (#5491) Co-authored-by: Zachary Plata <[email protected]>
|
closing since this was addressed in v2.2.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We recently exposed
drawImage()support from ourCanvasRenderer, which naturally led to seeing if we can support the rest of the Canvas2D context APIs by approaching a similar strategy (simply adding the call to our deferreddrawList).We may be able to just return a
ProxyfrommakeRenderer()which would intercept the calls toCanvasRendererand route each API function call either to ourCanvasRendererif the API the user wants to call exists on it, OR the._ctx(the actual Canvas2D context) fromCanvasRenderer. This should allow us to support our customsave(),restore(),_drawImageMesh(), etc. calls, while any non-overriden API we've wrapped inCanvasRendererwould go straight to the context itself.From a consumer perspective, nothing should change here. They call
const renderer = rive.makeRenderer(canvas-element)and userenderer.save(),renderer.restore(), etc. in a render loop as expected.