On Mon, 10 Nov 2025 13:59:30 GMT, John Hendrikx <[email protected]> wrote:
> This PR adds a `getDrawingContext` method to `WritableImage`, which works > similar to `Canvas::getGraphicsContext` and shares the same signatures. Key > features include: > > - **Shape rendering**: `strokeRect`, `fillRect`, `strokeOval`, `fillOval`, > `strokeArc`, `fillArc`, `strokePolyline`, `fillPolygon`, etc. > - **Stroke and fill attributes**: `lineWidth`, `lineCap`, `lineJoin`, > `miterLimit`, `fillRule`, `stroke` and `fill` paints. > - **Global graphics settings**: `globalAlpha` and `globalBlendMode`. > - **Image drawing**: draw other `Image` instances with scaling and > source/destination rectangles. > > This feature enables direct software rendering to `WritableImage` without > requiring a `Canvas` + snapshot. > > **Additional notes**: > > - The implementation leverages the software `Pisces` renderer. > - This lays the groundwork for future support of text rendering and path > operations. > > **Example usage**: > > > WritableImage img = new WritableImage(400, 400); > DrawingContext ctx = img.getDrawingContext(); > ctx.setFill(Color.RED); > ctx.fillRect(50, 50, 100, 100); > > > See the sample program `RandomShapesDemo` to see a `WritableImage` and > `Canvas` side by side performing the same operations: > > <img width="1249" height="741" alt="image" > src="https://github.com/user-attachments/assets/4a0b9dcc-8f96-4faa-99cf-83c66d2c851e"; > /> > > Newer version: > > <img width="1249" height="741" alt="image" > src="https://github.com/user-attachments/assets/c0502620-3d02-4fbd-8c33-43bd5138b42c"; > /> > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). This is interesting, similar to `BufferedImage.createGraphics()` in AWT. Questions: - so this will **aways** be slower than Canvas? - are the results going to be exactly the same, or there will be platform-specific differences in anti-aliasing etc? Also, perhaps we need to add a condition to suppress `invalidateWidthHeight` and `NodeHelper.geomChanged` only when it's the same image - we do need to handle the actual image change. Created https://bugs.openjdk.org/browse/JDK-8372007 to investigate the re-layout case. The size argument is a good one. One last question: would it make more sense to update the `Canvas` instead to remove the size limitation, instead of creating some parallel way of doing the same thing, possibly introducing subtle and not so subtle differences? Another aspect: let's say we decide to go with two parallel APIs - should we then make sure they mirror each other exactly? If so, would it create another maintenance burden? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1969#issuecomment-3512991966 PR Comment: https://git.openjdk.org/jfx/pull/1969#issuecomment-3542780376 PR Comment: https://git.openjdk.org/jfx/pull/1969#issuecomment-3542862325 PR Comment: https://git.openjdk.org/jfx/pull/1969#issuecomment-5376148335
