On 21/01/16 00:57, Phil Race wrote:
It seems like the expectation was that BASE could be drawn by the old
imaging path.
which would be lower overhead.
The BASE rendering hint check was used in the initial fix 8011059 to
fall down to the main image and had the problem with the SurfaceManager
which has not been set to the main image.
It has been fixed in the 8029339 by falling down into the base
resolution variant of the multi-resolution image.
The new check to the BASE rendering hint in the 8073320 look like an
artifact for me because the base resolution variant should be used for
the image drawing instead of the main image.
I am ok with the fix.
Thanks,
Alexandr.
I think we should ask Alexandr what the intention was here and whether the
code that handles the base image needs to be taught how to extract
data from
a MultiResolutionImage.
-phil.
On 01/20/2016 08:20 AM, Jayathirth D V wrote:
Hi,
__
_Please review the following fix in JDK9:_
Bug : https://bugs.openjdk.java.net/browse/JDK-8147413
Webrev : http://cr.openjdk.java.net/~jdv/8147413/webrev.00/
<http://cr.openjdk.java.net/%7Ejdv/8147413/webrev.00/>
Issue : JCK testcase
api/java_awt/Image/MultiResolutionImage/index.html\#MultiResolutionRenderingHints[test_VALUE_RESOLUTION_VARIANT_BASE]
is failing from b96 JDK9 build.
Root cause : In getManager API of SurfaceManager.java we are trying
to typecast BaseMultiResolutionImage to BufferedImage and it is
causing ClassCastException and in turn IllegalArgumentException seen
in result of test case. It is happening because of change made in
JDK-8073320 <https://bugs.openjdk.java.net/browse/JDK-8073320> in
SunGraphics2D.java. In case of VALUE_RESOLUTION_VARIANT_BASE type we
are not trying to convert MultiResolutionImage to BufferedImage.
Solution : Modify the condition present in drawHiDPIImage API to
convert all MultiResolution
