On Tue, Mar 3, 2009 at 7:38 AM, Roman Kennke wrote:
> Hi again,
>
>> 3. NotANumberTest: Double.NaN isn't handled gracefully.
>
> The problem here is that the renderer in OpenJDK is originally written
> for ME and uses fixed point arithmetic. I can't think of a quick fix,
> because shapes are proce
(Roman, thanks again for your work!)
I'd like to have the patches go into OpenJDK with the tests one way or
another though there may still be a need to doublecheck that I'm
covered by SCA.
Thanks,
Hiroshi
On Tue, Mar 3, 2009 at 12:29 PM, Roman Kennke wrote:
> Hi all,
>
>> 1. ScaleTest: A circle
Hi Roman,
First off, thanks for taking a look at the issues. I confirmed that
all the tests that I have pass with your patches applied.
On Tue, Mar 3, 2009 at 2:09 AM, Roman Kennke wrote:
> Hi there,
>
>> I believe that the minX and maxX parameters to that function are
>> relative to the origin
On Tue, Mar 3, 2009 at 1:24 PM, Phil Race wrote:
> Hello Roman,
>
> Roman Kennke wrote:
>>>
>>> The purpose of the tests is to verify that fixes work.
>>> So we don't integrate tests in advance of the fix since
>>> they would fail. Instead they live in the bug report.
>>
>> Ok. Are the testcases o
Hiroshi Yamauchi wrote:
\
So, an email should say "PATCH" somewhere in it? If that's the
convention, it's all fine.
Yes, that was the process, but as of last week its been replaced
by the new process to submit the patch as an attachment into
the openjdk bugzilla database.
http://mail.openjd
Hello Roman,
Roman Kennke wrote:
The purpose of the tests is to verify that fixes work.
So we don't integrate tests in advance of the fix since
they would fail. Instead they live in the bug report.
Ok. Are the testcases of former bug reports of Hiroshi (that have
already been fixed? Dunno abo
Hi Phil,
> >> 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.
> >
> > Two things we should do IMO:
> > 1. Integrate
Roman,
Roman Kennke wrote:
Hi all,
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.
Two things we should do IMO:
1. Integrate
Hi all,
> 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.
Two things we should do IMO:
1. Integrate all the tests, including
Hi Jim,
> I was aware that the code was playing with overflow fire when I ported
> it a while back. I figured the real fix was to eventually switch to
> float instead, as per your last suggestion - at least for the line
> widening code. Any takers?
Yeah I can do this, but it will surely take
Hi Jim,
> I think the shape iterators used in the other pipelines (which should be
> visible as it was code that we wrote, even if it isn't used for Pisces)
> took a more flexible approach, testing each segment for NaN and overflow
> and ignoring individual segments until the shape became finit
I was aware that the code was playing with overflow fire when I ported
it a while back. I figured the real fix was to eventually switch to
float instead, as per your last suggestion - at least for the line
widening code. Any takers?
...jim
Roman Kennke wrote:
Hi the
I think the shape iterators used in the other pipelines (which should be
visible as it was code that we wrote, even if it isn't used for Pisces)
took a more flexible approach, testing each segment for NaN and overflow
and ignoring individual segments until the shape became finite again.
This ha
Hi again,
> 3. NotANumberTest: Double.NaN isn't handled gracefully.
The problem here is that the renderer in OpenJDK is originally written
for ME and uses fixed point arithmetic. I can't think of a quick fix,
because shapes are processed by iterating over them, this means, by the
time we hit the
Sorry, wrong patch. Here it comes.
/Roman
Am Dienstag, den 03.03.2009, 16:17 +0100 schrieb Roman Kennke:
> Hi there,
>
> > 4. StrokeShapeTest: createStrokedShape() behaves differently.
>
> It turns out that there is an arithmetic overflow here. The pisces
> stroker does a stupid thing here. Fir
Hi there,
> 4. StrokeShapeTest: createStrokedShape() behaves differently.
It turns out that there is an arithmetic overflow here. The pisces
stroker does a stupid thing here. First it initializes the
scaledLineWidth like this:
this.scaledLineWidth2 = ((long)transform.m00*lineWidth2);
wh
Hi,
I think we have at least two problems here.
For one, this appears to be a rounding problem. In
SunGraphics2D.validateBasicStroke(), we calculate a widthsquared of
0.24997, and compare it to a MinPenSizeSquared of 0.25, this
triggers the thin logic where it probably should not.
OT
Hi there,
> 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
Hi there,
> 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
19 matches
Mail list logo
