-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Move JavaFX to a separate library in the Contributions Manager #348
Comments
Created by: dzaima An alternative would be to bundle JavaFX only for the required operating system. Currently a Processing download gives you JavaFX for all of Windows, Mac, and Linux, two thirds of which you won't need. Would complicate cross-platform exporting, but that's already messy because of no included java runtime. |
Created by: benfry Nah, it's still an extra ~200 MB for just the one platform, and it makes cross-platform export a nightmare and at odds with the intent of Processing and the PDE in general. Similarly, we could also drop the webkit portion to chop it in half, but again, it's just more caveats and headaches for the people who want to use that. |
Created by: benfry New repo here: https://github.com/processing/processing4-javafx |
Created by: peter100u Can the flutter framework be used to rewrite processing? As a cross platform, it is a very good scheme |
Created by: dzaima Flutter uses Skia as its rendering backend, which is the actual part that could be used in processing. And there's Skija that binds Skia to Java, usage of which was discussed here. |
Created by: benfry Folks, this is way off topic. Please use https://discourse.processing.org/ for general discussion. This is an issue about moving JavaFX to a separate library. |
Created by: benfry
The size Processing 4 is massive (hundreds of megabytes) compared to Processing 3. The main problem is that the JavaFX library is enormous, so I'm probably gonna have to move it to a separate library that can be installed from the Contributions Manager. Not a great user experience, but better than everyone having to deal with such a massive download.
Unfortunately, it's not an easy decision, because it requires a lot more effort:
import processing.javafx.*
when they use theFX2D
renderer, or to do that automatically behind the scenesprocessing-video
is that much more work for me.Java 17 is also quite a bit larger than Java 8, but we're just stuck with that. There isn't a good way to modularize a development environment—I can't/shouldn't be anticipating what modules people will need/want to use.
The text was updated successfully, but these errors were encountered: