[OpenJDK 2D-Dev] RFR: 7183828 Invalid Image Variant when using anything other than BufferedImage

[Philip Race]

Can you please add an evaluation to the bug report explaining what you 
intend to do.
The submitter of that bug was clearly hoping that we'd support custom 
Image subclasses
and this fix just changes the behaviour from an IAE (or similar) to 
silently ignoring them.
I'm not sure what benefit there is there. It just means that people will 
be more puzzled
as to what is going on than before.

Also now we have more checks for specific known image types.
VolatileImage is an abstract class and I'm surprised that this is 
something this fix
considers OK for subclasses to extend. Does that really work ?

I think we should have just closed this out as WNF / not an issue.

-phil.

On 7/27/20, 10:14 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk/client.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7183828
> Fix: http://cr.openjdk.java.net/~serb/7183828/webrev.00
>
> Our DrawImage pipe, used as low-level machinery to draw the known type 
> of images, supports only
> three types of images:
>  - ToolkitImage - implemented via ImageRepresentation.drawToBufImage()
>  - VolatileImage/BufferedImage implemented via different types of "loops"
>
> We have a type check for the ToolkitImage image only, otherwise, we 
> assume that the image is
> of type VolatileImage/BufferedImage, so if the user creates its own 
> image and passes it to
> this pipe he will get an exception.
>
> After the fix, such custom images will be ignored by the DrawImage pipe.
>