On Sat, 29 Aug 2026 14:33:24 GMT, John Hendrikx <[email protected]> wrote:
>> 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. I agree that there's no performance penalty with regards to the native texture formats. The only potential performance impact that I can see concerns existing uses of `PixelReader` and `PixelWriter`. However, this goes both ways, and is not in itself an argument either in favor or against any particular pixel format. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1969#discussion_r3944423558
