On a footnote, we should consider coming up with naming conventions for
when ranges refer to "first and last pixels touched" vs. when they refer
to "start and end coordinates between pixels (i.e. when the end
coordinate is the number of the first pixel outside the region)".
Personally, in code
This just came through internally for a code review and I looked into it
in more depth. Sorry to take so long to get back to everyone, but I
don't think this is the answer.
I think the problem is in the startRow function. In the "alphaRows ==
0" case it sets the bbox to x1+1, but in the else
Hi Hiroshi,
All the patches are in
https://bugs.openjdk.java.net/
The IDs are: 100030, 100031, 100032, 100035
Jennifer
Hiroshi Yamauchi wrote:
Hi Jennifer,
Do you mind pasting the URL links to the patches in this thread? I'd
like to backport them into our openjdk6 tree.
Thanks,
Hiroshi
On
Hi Jennifer,
Do you mind pasting the URL links to the patches in this thread? I'd
like to backport them into our openjdk6 tree.
Thanks,
Hiroshi
On Mon, Apr 6, 2009 at 12:23 PM, Jennifer Godinez
wrote:
> Hi Roman,
>
> Thanks for submitting the patches. I got all 4 now. I'm working on it but
>
Hi Roman,
Thanks for submitting the patches. I got all 4 now. I'm working on it but Jim needs to review the
changes. He's on vacation now so don't expect to get anything very soon until he gets back. I will
keep you updated.
Jennifer
Roman Kennke wrote:
Hi Jennifer,
Apologies for not
Thanks! I will be looking into these patches and have them reviewed.
Jennifer
Roman Kennke wrote:
Hi Jennifer,
Apologies for not replying to you sooner.
No problem.
As far as I know, Jim made comments on the fix. Have you
looked into these?
Jim commented on the fix for bug #3 that
Hi Jennifer,
> Apologies for not replying to you sooner.
No problem.
> As far as I know, Jim made comments on the fix. Have you
> looked into these?
Jim commented on the fix for bug #3 that I haven't looked at yet. I will
do so tomorrow.
> Whether or not you have, please go ahead and e
FYI, the join miter patch seems to have gone in:
http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9318628e8eee
but probably the other patches didn't. I also would like to see these
patches go into openjdk soon.
Thanks,
Hiroshi
On Thu, Mar 26, 2009 at 7:16 AM, Roman Kennke wrote:
> Hi,
>
> Is it poss
Hi Roman,
Apologies for not replying to you sooner. As far as I know, Jim made comments on the fix. Have you
looked into these? Whether or not you have, please go ahead and enter the patch into Bugzilla so
we can better keep track on them.
Jennifer
Roman Kennke wrote:
Hi,
Is it possibl
Hi,
Is it possible to get an update on these patches or did the whole Java2D
team just disappear? ;-) Should I enter the patches into Bugzilla or
should I simply wait? What's happening with them now?
/Roman
> so what happens now with this patch and the others? Should I enter them
> into Bugzilla
Hi,
so what happens now with this patch and the others? Should I enter them
into Bugzilla, so they don't get lost? Are they already in the process
of beeing integrated?
/Roman
Am Dienstag, den 03.03.2009, 16:17 +0100 schrieb Roman Kennke:
> Hi there,
>
> > 4. StrokeShapeTest: createStrokedShape
This is almost there. A couple of points about the solution, though:
- If you skip the MOVETO then you need to make sure that you later emit
an lsink.moveTo otherwise the lsink object will complain about bad
state. If you look in ProcessPath.c you will see that a "skip" boolean
is set whenev
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
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:3
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
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/ja
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 wh
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
36 matches
Mail list logo
