Created by: 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.

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.

Uh oh!

Uh oh!

Saving to PNG broken in anything but the default renderer #80

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions