On Mon, 10 Nov 2025 20:21:31 GMT, Andy Goryachev <[email protected]> wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
>> line 1510:
>>
>>> 1508: public PlatformImage createPlatformImage(int w, int h) {
>>> 1509: IntBuffer buf = IntBuffer.allocate(w * h);
>>> 1510: return com.sun.prism.Image.fromIntArgbPreData(buf, w, h);
>>
>> This seems to be no problem to change (an image heavy application still runs
>> absolutely fine), but it is kind of a global change. If there are issues
>> with this, we could make a specific method for writable images to use so we
>> always get an `int[]` buffer that the software renderer expects.
>>
>> As it is now, the renderer is writing directly into the underlying image
>> storage, without any copies being made (which is nice and efficient).
>
> I am curious why the byte buffer was chosen initially.
> Will `IntBuffer` be better on every platform?
>
> Also, `w * h` might be negative if the product is greater than ~2B, though it
> will result in an `IllegalArgumentException` with a cryptic "capacity
> expected to be negative" message.
I don't see a specific reason for the choice -- possibly because Java2D did it
that way. All pipelines can deal with either format without any issues that I
could see, and should do so without performance penalties:
- D3D -- `INT_ARGB_PRE` is actually native for D3D
- Metal -- directly supports `INT_ARGB_PRE` no conversion needed
- ES2 (OpenGL) -- format can be specified, and both `INT_ARGB_PRE` and
`BYTE_BGRA_PRE` uses the same path, no CPU conversion needed
- Software -- uses `INT_ARGB_PRE` natively, so bonus there
>From a user perspective, you can observe this change via `getPixelFormat` --
>but as we offer no direct access to pixels, there is no need to know. The user
>can also request pixels to be copied, but they have to specify their preferred
>destination format so this will always end up the same regardless.
Overall, this has no downsides for existing code and pipeline, but a huge
upside for the software renderer.
> Also, w * h might be negative if the product is greater than ~2B, though it
> will result in an IllegalArgumentException with a cryptic "capacity expected
> to be negative" message.
That's pre-existing, and with this change it will take a 4x larger image before
that happens.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1969#discussion_r3886836301
