[OpenJDK 2D-Dev] More incompatibilities

Hiroshi Yamauchi yamauchi at google.com
Tue Mar 3 01:50:22 UTC 2009


Thanks, Jim, for comments.

What you are describing seems right to me. I thought that the problem
was that the 'bounding box' was slightly too short on the right end,
which made the circle drawn like a C shape.

I'll look more into it when I have a chance.

Best,
Hiroshi

On Mon, Mar 2, 2009 at 5:31 PM, Jim Graham <Jim.A.Graham at sun.com> wrote:
> Thank you Hiroshi for investigating that problem and coming up with a
> potential fix.  Unfortunately, the fix you propose does not look right to
> me.
>
> I believe that the minX and maxX parameters to that function are relative to
> the origin of the raster coordinates which means you would add each of them
> to the raster's origin (rasterMinX) to get an absolute min/maxX.  So they
> look correct as written.
>
> If this change fixes the problem, then it is a side effect of moving the
> right edge of the "startRow" call out to the right some more.  That could
> indicate that perhaps maxX was not calculated correctly in the first place
> and so expanding it out "covers up" the problem.
>
> It sounds like it needs more investigation than that simple change...
>
>                        ...jim
>
> Hiroshi Yamauchi wrote:
>>
>> The following patch appears to make ScaleTest pass. Though I don't
>> know exactly what the code does, but it appears to be a copy-and-paste
>> bug to me.
>>
>> Anyway, I'd appreciate it if someone in the Java 2D community can
>> confirm that it's the right fix.
>>
>> Thanks,
>> Hiroshi
>>
>> +++ jdk/src/share/classes/sun/java2d/pisces/Renderer.java
>> 2009-02-27 21:44:44.000000000 -0800
>> @@ -632,7 +632,7 @@
>>         if (cache != null) {
>>             if (maxX >= minX) {
>>                 int x0 = minX + (rasterMinX >> SUBPIXEL_LG_POSITIONS_X);
>> -                int x1 = maxX + (rasterMinX >> SUBPIXEL_LG_POSITIONS_X);
>> +                int x1 = maxX + (rasterMaxX >> SUBPIXEL_LG_POSITIONS_X);
>>
>>                 cache.startRow(y, x0, x1);
>>                 int srcIdx = minX;
>>
>> Hiroshi
>>
>> On Tue, Feb 24, 2009 at 11:40 AM, Hiroshi Yamauchi <yamauchi at google.com>
>> wrote:
>>>
>>> The following change appears to make the ThinLineTest pass. I tried a
>>> couple
>>> of variations of it, with and without antialiasing, with and without
>>> scaling, and with different scaling factors and line widths. The looked
>>> okay. Btw, bear with me as I am not really a Java 2D person and I may not
>>> know what I'm talking about :) But I got the feeling that the 'thin'
>>> logic
>>> (to do with the thin boolean parameter to
>>> PiscesRenderingEngine.strokeTo()
>>> and the logic in SunGraphics2D.validateBasicStroke()) isn't compatible
>>> with
>>> Stroker.computeOffset().
>>>
>>> +++ jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
>>> 2009-02-24 11:17:48.000000000 -0800
>>> @@ -169,7 +169,7 @@
>>>                   LineSink lsink)
>>>     {
>>>         float lw;
>>> -        if (thin) {
>>> +        if (false && thin) {
>>>             if (antialias) {
>>>                 lw = 0.5f;
>>>             } else {
>>>
>>>
>>> On Mon, Feb 23, 2009 at 5:32 PM, Hiroshi Yamauchi <yamauchi at google.com>
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> We found four more 2D rendering OpenJDK incompatibilities (the examples
>>>> are attached):
>>>>
>>>> 1. ScaleTest: A circle is rendered in a 'C' shape.
>>>> 2. ThinLineTest: A line < 1 pixel disappears.
>>>> 3. NotANumberTest: Double.NaN isn't handled gracefully.
>>>> 4. StrokeShapeTest: createStrokedShape() behaves differently.
>>>>
>>>> Some of the examples may be caused by a single bug. I don't have an idea
>>>> what the causes are.
>>>> By any chance, have any of the them already fixed?
>>>>
>>>> Thanks,
>>>> Hiroshi
>>>>
>>>>
>>>
>



More information about the 2d-dev mailing list