PImage:save doesn't check for png. I see that recent edits are trying to reduce library dependency. I looked into it a bit more though and I'm not sure if there are many super great alternatives to using ImageIO.

Cross-posting from #81: Just a quick update here... It looks like even in JavaFX and JOGL, BufferedImage is still the canonical solution. There might not be a way to avoid using it.

Ah, this is something we need to handle differently in the renderers themselves… i.e. if they're using AWT objects (i.e. Image or BufferedImage) they need to create ImageAWT objects. The refactor was about moving all that AWT cruft out of the main classes so that we have little or no AWT in the main processing.core package.

JOGL and JavaFX also have their own more efficient ways of handling image objects, our use of AWT in those was just a crutch to get things working quickly; this would provide a pathway for others to build out that improved image support.

Thanks @benfry. I'm sorry could you say more about how JavaFX / JOGL would handle this? Maybe just taking JavaFX first... looking around online, it's not clear how to do this in JavaFX without using the AWT Image classes. I may be missing something obvious though.

In the meantime, @benfry opened PR #97 for just AWT.

Also, if you did want that for FX2D, see #98

I'm sorry could you say more about how JavaFX / JOGL would handle this? Maybe just taking JavaFX first... looking around online, it's not clear how to do this in JavaFX without using the AWT Image classes. I may be missing something obvious though.

Nope, not missing anything, sorry for the confusion… For now it's necessary to use PImageAWT. But the idea is that we get the AWT-specific code out of the main classes, and then the usage of AWT is determined independently by individual renderers… i.e. for now, JavaFX and JOGL just need to create PImageAWT objects instead of PImage if they want to do saving or have access to the AWT code.

However, this way, in the future, when someone wants to/has time to excise AWT from JOGL or JavaFX, that can be done as an independent thing. It's also then clearer in the JFX/GL code bases where AWT is being used, rather than introducing a surprise when a user calls save(). Does that make sense?

AWT has some weird performance bottlenecks that are avoided by more modern approaches for JavaFX, JOGL (i.e. NEWT or whatever it's called now), and LWJGL. So in an ideal world, those renderers would never touch/initalize AWT. In the real world, I've not had time to maintain all those renderers independently, so we're still relying on AWT for some things around the edges (like image i/o).

In a similar fashion, loadImage() is part of the renderer/surface level… So a better option for me at the moment might be to move saving images into ShimAWT, but I need to take a closer look… (Don't worry about doing anythign yet—will get back to you)

For now, the band-aid of using new PImageAWT in JavaFX and JOGL to replace new PImage, and on save() rewrapping the PImage as a PImageAWT if it's not one already should do.

Great! Thanks this makes sense @benfry. Just checking, do PRs #97 and #98 go in the right direction for this?

Trying to gather all this in-progress discussion: https://github.com/processing/processing4/wiki/Exorcising-AWT