On Thu, 3 Apr 2025 09:26:03 GMT, Nikita Gubarkov <ngubar...@openjdk.org> wrote:

>>>I just accepted any pixel-interleaved surface with 4-byte stride and assumed 
>>>that I can blit it directly. 
>> 
>> So you implemented logic similar to [this 
>> one](https://github.com/openjdk/jdk/blob/bd74922157230c866802b4c5269da81e872525aa/src/java.desktop/share/native/libawt/java2d/loops/LoopMacros.h#L847).
>> 
>> I haven’t found yet whether we have logic to fall back to a "generic Java 
>> loop" if the gap is not stored in the array and that memcpy fails. If we’re 
>> missing this, we should either:
>> 
>> - Add the fallback,
>> - Implement another version of the loop that handles the tail, or
>> - Update the current ISOSCALE_BLIT.
>> 
>> A similar approach could be implemented for Vulkan as well.
>
> I get the idea. Actually, my Vulkan blit routines know the component order 
> (needed for swizzling anyway), so instead of copying `scanlineStride` or 
> `width * pixelStride`, I can copy `(width - 1) * pixelStride + maxBandOffset 
> + 1` (I don't like breaking the alignment at the end, but anyway).
> However, supporting the gap at the end of the pixel seems like a lot of 
> burden to me - not all current code seems to consider this possibility and 
> for the future code it's too easy to get wrong.
> 
> Some side thoughts: I think we rely on predefined formats and loops too much. 
> As I already mentioned, `SurfaceDataRasInfo` doesn't have info about its 
> bands and doesn't even have a total size. We rely on specific loops 
> registered for specific surface types, which only works well when we created 
> those surfaces by ourselves. Example:
> I profiled Intellij IDEA to see which blit loops are often used there and 
> noticed that icons are loaded as 4-byte RGBA images. See the issue? That's a 
> `TYPE_CUSTOM` image with some generic `SurfaceType` - it doesn't have native 
> raster ops initialized, so it can only go through a generic software loop! 
> That's how I came to https://github.com/openjdk/jdk/pull/24378. So what I was 
> trying to do with that Vulkan work is to make it more generic - register 
> loops for more generic surface types and dynamically inspect their properties 
> to see whether we can actually do an optimal blit. And given that 99% of the 
> time those are 3/4-bytes per pixel RGBA/ARGB/BGR/etc., it's very easy to 
> generalize, but we don't seem to have enough flexibility for that.

There is no reason to change our current implementation of 
ComponentSampleModel, since a similar raster can be created manually and should 
be properly handled by accelerated pipelines.

    DataBuffer manualBuffer = new DataBufferByte(
        scanlineStride * (SIZE - 1) + pixelStride * SIZE
    );
    WritableRaster manualRaster = Raster.createWritableRaster(sampleModel, 
manualBuffer, null);
    BufferedImage manualImage = new BufferedImage(colorModel, manualRaster, 
isAlphaPremultiplied, null);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2047838110

Reply via email to