On 26.08.2020 11:27, Philip Race wrote:
Can you please add an evaluation to the bug report explaining what you intend 
to do.

Will 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.

After the fix, we will start to support them to some degree. The drawImage spec 
does not have
any exceptions, this method can only report is the pixels were completly pushed 
to the
destination or nor. After the fix we will report "false" for any unsupported 
types of images.
The new behavior will be similar to the ToolkitImage case, when the image is 
not loaded yet.


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 ?

This is a good question I'll double-check that.


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.



--
Best regards, Sergey.

Reply via email to