[OpenJDK 2D-Dev] Review Request: (JDK-8048782) OpenJDK: PiscesCache : xmax/ymax rounding up can cause RasterFormatException.

[Jim Graham]

I'm good with it if it fixes the bug in question.  (I didn't review the 
test case as Phil seemed to be looking at that.)

			...jim

On 2/25/15 2:27 AM, prasanta sadhukhan wrote:
> Thanks Jim,Phil for review.
> Updated webrev contains the changes -
> http://cr.openjdk.java.net/~serb/prasanta/8048782/webrev.01/
>
> Regards
> Prasanta
> On 2/21/2015 2:57 AM, Jim Graham wrote:
>> Hi Prasanta,
>>
>> This fixes the symptom without fixing the underlying issue which is
>> that there is poor sharing of information between the objects in the
>> Pisces package.  The cache adds 1 to bboxX1 and bboxY1 for its own
>> internal purposes - and it seems extremely questionable that it should
>> do so as reading through the code it isn't clear that it should - and
>> then another object grabs its bbox data, making assumptions about how
>> those fields are managed, and gets it wrong.  Filtering the answer for
>> "rightness" does not fix the underlying problem of how PTG gets its
>> data.  I'd recommend a solution that brings us closer to having the
>> code make sense, though we should look for a minimal solution since
>> Marlin may patch much of this code when that project gets integrated.
>> Some suggestions:
>>
>> - Add PiscesCache.getBBox() which does the proper "- 1"s
>>
>> - Adjust PiscesCache to not need to add one.  This is probably the
>> best overall solution since it gets rid of "voodoo" code in
>> PiscesCaceh, but it would require a lot more testing.  This could get
>> risky, so the first solution above, though it might add more code, is
>> probably better for now.  Note that in PiscesCache, allocating the
>> rowAARLE array already adds one to the number of rows allocated which
>> seems odd because now we allocate 2 additional rows due to the bbox+1
>> adjustment.  Also, bboxX1 is never even used so adding 1 to it just
>> seems pointless other than to confuse code that reads the values.
>>
>>             ...jim
>>
>> On 2/19/2015 8:39 PM, prasanta sadhukhan wrote:
>>> Hi,
>>>
>>> I would like a review for a solution of this bug.
>>> In OpenJDK9, "java.awt.image.RasterFormatException: (x + width) is
>>> outside raster" is thrown when the bounding box width outgrows original
>>> raster. This is because PiscesRenderingEngine does not take care of
>>> clipping the bounding box correctly.
>>>
>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8048782
>>> webrev: http://cr.openjdk.java.net/~serb/prasanta/8048782/webrev.00
>>>
>>> Regards
>>> Prasanta
>