<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Bug: <a class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8177393">https://bugs.openjdk.java.net/browse/JDK-8177393</a>
<br>
Webrev: <a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eprr/8177393/">http://cr.openjdk.java.net/~prr/8177393/</a><br>
<br>
I have updated the bug report with a long evaluation and some
additional<br>
explanation of the proposed fix. I don't intend to duplicate all
that here<br>
so please go read it there. The following is a much briefer summary.<br>
<br>
We are ending up in medialib native code that cannot interpret the
Java 2D child raster<br>
it is handed. The child raster was an attempt to prevent rescaling
of the alpha channel.<br>
<br>
The proposed fix avoids creating that child raster and instead
creates a LookupOp<br>
which has an explicit lookup table for the alpha channel that does
the identity lookup. <br>
<br>
The fix has a couple of other updates.<br>
(1) the "canUseLookupOp()" method now checks that the DataBuffer is<br>
something that the medialib code used by LookupOp can handle.<br>
This would have fixed the bug by itself although at the expense of
always<br>
falling back to slow Java code in RescaleOp. However it is still
needed in<br>
case the application itself supplies a child raster.<br>
<br>
(2) The slow path in RescaleOp turns out to have the same bug that I
think<br>
was seen in some other bug report or fix. It is always re-scaling
alpha as<br>
well as colour components. I fixed that too.<br>
<br>
Since the fix is entirely confined to RescaleOp any consequences -
good or bad - are limited.<br>
<br>
I ran the few regression tests we have that cover RescaleOp and also
checked Java2Ddemo.<br>
<br>
The commented out cases in the new regression test are to be handled
under a different bug ID.<br>
<br>
-phil.<br>
</body>
</html>