processing / processing4

Processing is a flexible software sketchbook and a language for learning how to code. Since 2001, Processing has promoted software literacy within the visual arts and visual literacy within technology. There are tens of thousands of students, artists, designers, researchers, and hobbyists who use Processing for learning and prototyping.
https://processing.org
Other
18 stars 6 forks source link

Move `loadImage()` into `Surface`, and AWT out of `PImage` #56

Open processing-bot opened 4 years ago

processing-bot commented 4 years ago

Created by: benfry

Several changes necessary to move image handling into Surface so that we're not invoking AWT.

However, if that's done, we need to replace the image loading for JOGL and JavaFX as well, or have those subclass a LameKindaSurfaceAWT which has the AWT code.

There's a constructor, resizer, and some IO options in PImage that all make use of AWT code. These will all be moved to PImageJava2D inside the processing.awt package, but will need replacements for JOGL and JavaFX.

processing-bot commented 4 years ago

Created by: neilcsmith-net

Are you trying to remove all AWT usage or just allow headless (for eg. LWJGL use)? Because large portion of Processing AWT code, such as in PImage, PFont, etc. works fine headless.

processing-bot commented 4 years ago

Created by: benfry

More here: https://github.com/processing/processing4/wiki/Exorcising-AWT

processing-bot commented 4 years ago

Created by: neilcsmith-net

As per @sampottinger comment, LWJGL might be better placed in terms of library integration to allow a complete removal of AWT / java.desktop dependencies for a particular renderer. @benfry interesting page, but surprised to see LWJGL still under discussion - thought that had been dropped? My issue to discuss necessary changes to PApplet to support it were closed.

processing-bot commented 4 years ago

Created by: sampottinger

Yeah I agree with @neilcsmith-net. There's some stuff like image saving where it's headless-OK but where AWT-dependent code has become standard. For example, it looks like even in JavaFX and JOGL, BufferedImage is still the canonical solution. There might not be a way to avoid using it.