Feedback requested: Proof of concept PR for extending WritableImage with its own "graphics context" to draw higher level primitives directly :)

John Hendrikx john.hendrikx at gmail.com
Mon Nov 10 19:27:19 UTC 2025


On 10/11/2025 18:32, Andy Goryachev wrote:
>
> This is interesting, similar to |BufferedImage.createGraphics()| in AWT.
>
Yeah, I proposed this a few months ago as I noticed that FX basically
has everything needed; it just needs something to tie the pieces
together.  This is why the PR is really not that complicated, but just
translating from user API's to Prism API's for the most part.
>
> Questions:
>
>   * so this will aways be slower than Canvas?
>
Not necessarily.

- If you frequently need to read pixels (with PixelReader) then
WritableImage can be faster, as you avoid the CPU->GPU->CPU memory copy
cycle that you'd get with snapshotting a Canvas. For example, image
scaling may be faster if you need the final resulting pixels again, as
scaling is a relatively simple operation but involves lots of data that
would otherwise need copying multiple times.

- If you primarily do operations on small sizes (say icons, or small
images), or only need infrequent changes

- WritableImage can also be used without any kind of Scene (it is not a
Node)

Where it will definitely be slower:

- Using a large working area (>= 500x500), and drawing over large areas;
at what point the GPU wins depends on what you're doing exactly

- Using gradients/effects over large areas heavily favors GPU's

- Simulating unsupported blend modes (some blend modes are really heavy,
requiring a division per color channel)

- Font rendering heavily favors GPU's I think as GPU's can cache glyphs
in vector form and render them directly at any size

>  *
>     are the results going to be exactly the same, or there will be
>     platform-specific differences in anti-aliasing etc?
>
There will be differences, but for supported features you'd have to know
what to look for to spot the differences.  The limitations are very
similar to the differences between FX's software and accelerated
pipelines, as the same back-end renderer is used. 

For example, the offered blend modes are limited (only SRC_OVER and
ADD).  Even for supported features (like Image scaling) there can be
slight differences (but the same can be said of different GPU pipelines,
and even different GPU's).

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251110/96913fbf/attachment-0001.htm>


More information about the openjfx-dev mailing list