Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

lights0123
Copy link

@lights0123 lights0123 commented Sep 13, 2020

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
  • masks

I believe this is the only product that hasn't disappeared from the internet that can do this (and have it actually work).

@lights0123
Copy link
Author

lights0123 commented Sep 14, 2020

Things to consider, which I may try to figure out in the future:

  • Size optimization: creating one instance of each sprite (glyph?) in the <defs> section and re<use>ing it, instead of copying the SVG path commands for every single letter. I don't know how much work this requires. Ideally, this could also be used to allow copy-pasting
  • Multi-threading the exporter

render/svg/src/lib.rs Outdated Show resolved Hide resolved
@Herschel
Copy link
Member

Herschel commented Sep 18, 2020

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?

render/svg/src/lib.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@Dinnerbone Dinnerbone left a 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!)

@midgleyc
Copy link
Contributor

midgleyc commented Dec 5, 2020

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.

@lights0123
Copy link
Author

@midgleyc thanks for your work! I've pulled your branch into mine.

@lights0123
Copy link
Author

The three failing nightly builds are because of a new clippy lint, and the web one is probably not my fault.

@Herschel
Copy link
Member

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!

@jhwgh1968
Copy link

It looks like CI on this failed, due to lints fixed in master. Perhaps time for a rebase?

@midgleyc
Copy link
Contributor

midgleyc commented Jan 9, 2021

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 swf_shape_to_svg is the largest one I can see. I think srgb_to_linear was also taken from the canvas renderer, so the request to use ruffle_core::backend::render::srgb_to_linear instead can also apply to that.

@firoball firoball mentioned this pull request May 23, 2022
@micwoj92
Copy link

micwoj92 commented Jul 9, 2022

This branch has conflicts that must be resolved

@mero09-99
Copy link

Any progress on this?
this would be very useful to me,
especially the previously mentioned SVG screenshot key (no rasterization!)
#1168
#7036
mentions this, but I'm unsure

Aaron1011 added a commit to Aaron1011/ruffle that referenced this pull request Jul 23, 2022
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.
@danielhjacobs danielhjacobs added A-rendering Area: Rendering & Graphics T-feature Type: New Feature (that Flash doesn't have) labels Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rendering Area: Rendering & Graphics T-feature Type: New Feature (that Flash doesn't have)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants