On Wed, 21 Oct 2026 00:04:30 GMT, John Hendrikx <[email protected]> wrote:
>> 1. I agree, an optimization can be undertaken in a follow-up. >> 2. Instead of "unspecified", should ie be "not supported"? throw an >> exception? > > For point 2: The problem is that you can't easily detect with 100% certainty > that something is a self draw or not when native buffers are involved. We can > detect it relatively easily for heap buffers, as we can get the `array` of > both and if equal it's a self draw. However, with native buffers (`IntBuffer` > direct), there is no way to know if the source (the image you provide) isn't > a slice of the larger `IntBuffer` that is your target. > > So our options are then: > - Leave self draw unspecified, as we can't detect it with 100% certainty from > Java code; this gives us the most wiggle room to fix this later -- users have > several easy options to avoid it to still get deterministic behavior if they > want to "self draw" > - Pre-emptively copy all direct `IntBuffer` images, just in case they are > overlaps -> this is wasteful as it destroys the performance of the best path > (which is to use native buffers for everything) > - Have native code detect the overlap (before doing any drawing) and either: > - Refuse the operation (Java can then retry with a copy) -> relatively fast > as the initial "try" did no copy > - ~~Have native code solve the problem by altering the draw order (kinda > like how overlapping array copies work, you either copy in forward or > backward direction) -> this may be hard, and would touch the native renderer > code, didn't investigate (out of scope)~~ -> checked, this won't work, > drawing an image with resampling/compositing is too involved to solve it in > that way > - Have native code allocate a temporary buffer and do the copy itself -> > need to deal with OOM in native code, could also be quite involved (out of > scope as well IMHO) > > This, and the fact that I think self draw is a very niche need, is why I > think it is best to leave it unspecified for now. I added one optimized path already that was "easy" to do -- if the image supplied is on the heap, and in INT_ARGB format, we draw it without any copy at all. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1969#discussion_r4332377613
