-
-
Notifications
You must be signed in to change notification settings - Fork 828
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
Add SVG renderer backend #1168
base: master
Are you sure you want to change the base?
Add SVG renderer backend #1168
Conversation
Things to consider, which I may try to figure out in the future:
|
Thanks for your work, and welcome! Looks good to me -- it does add some maintenance burden whenever we tweak the RenderBackend, so we'd have to be okay with that; but I think this would be useful to have. We should probably label it as "experimental" until it's more fleshed out (color transforms, at least). It'd be interesting to try using this on web to display an SWF using a SVG DOM element instead of canvas. This also makes me want to add an SVG screenshot hotkey to the desktop app. @Dinnerbone, does this look okay as far as the exporter goes? |
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.
Sorry for the big wait there, busy month!
Exporter part looks good. It'll need to be fixed up with recent changes but that should be trivial. Thanks for this!
(and yes, svg screenshot key is the best idea!)
Hi @Dinnerbone , @lights0123 , I've rebased this onto master at https://github.com/midgleyc/ruffle/tree/svg-exporter : I can't edit this branch, but I hope this might help. I've found this the most accurate SWF -> SVG converter, so thanks for writing it. |
@midgleyc thanks for your work! I've pulled your branch into mine. |
The three failing nightly builds are because of a new clippy lint, and the web one is probably not my fault. |
Thanks for your effort @lights0123 and @midgleyc -- this has been somewhat low priority because it's not a core feature of the player, and I've been anticipating some other renderer changes, but since it's been useful to multiple people I'll try to merge this in the next few days. Thank you! |
It looks like CI on this failed, due to lints fixed in master. Perhaps time for a rebase? |
A lot of code was copied from the canvas renderer when first created, and changes have been made to that since then. It might be nice to extract some of the swf -> svg code to keep it in sync -- most of |
This branch has conflicts that must be resolved |
We currently have 3 render backends: 'canvas', 'webgl', and 'wgpu'. Assuming that we eventually merge the SVG backend proposed in ruffle-rs#1168, we'll have to maintain 4 independent render backends. I believe that we should be able to drop 'canvas' support, and only rely on 'webgl' (and 'wgpu' in the future) for browser support. This PR doesn't actually remove anything yet - we just display a click-through warning: "Using deprecated canvas backend! Please file a bug report" when the canvas backend is enabled. If it turns out that no one ever hits this warning in practice, we could move to disable the 'canvas' feature in the `web` crate by default. If there are still no bug reports, we could remove the backend entirely. caniuse.com shows the following global availability percentages: 'HTML element: canvas': 97.25% (https://caniuse.com/mdn-html_elements_canvas) 'WebGL (version 1)': 98.02% (https://caniuse.com/webgl) 'Canvas (basic support)': 99.51% (https://caniuse.com/canvas) Based on the data, dropping 'canvas' support would essentially only impact users with WebGL support disabled. It's possible that some browsers might do this for certain websites for privacy/security reasons - however, we already require WebAssembly, so I doubt that WebGL would ever be the only blocker for running Ruffle. The biggest potential downside to this is implementing 'BitmapData.draw'. In order to support SWFs that perform rapid 'BitmapData.draw; BitmapData.getPixel' sequences, we're going to need to perform CPU rendering to avoid blocking on copying data back and forth from the GPU. Using the 'canvas' backend for 'BitmapData.draw' would be one way to accomplish this - however, we would still need a separate backend for the desktop. I believe we could use the SVG backend on all platforms for implementing 'BitmapData.draw'. We'd need to add a dependency on an SVG renderer for desktop, and abstract over `web-sys` vs the `svg` crate. However, I think the result will be a large net reduction in code and maintenance burden.
For documents that are originally in SWF format, exporting as a non-vector format can cause quality reduction. This PR adds a backend that creates SVG files, as well as adds it to the exporter CLI. I didn't need these features for my use case, so the following aren't implemented:
color_transform
I believe this is the only product that hasn't disappeared from the internet that can do this (and have it actually work).