On 2/19/2015 8:57 PM, Phil Race wrote:
On 2/19/15 8:50 PM, Mandy Chung wrote:
On 2/19/2015 4:23 PM, Phil Race wrote:
http://cr.openjdk.java.net/~prr/8035302/
I'll let Sherman and others to do the detailed review here. Minor
comment:
FontDescriptor.java
line 56-58: can use try-with-res
On 2/19/15 8:50 PM, Mandy Chung wrote:
On 2/19/2015 4:23 PM, Phil Race wrote:
http://cr.openjdk.java.net/~prr/8035302/
I'll let Sherman and others to do the detailed review here. Minor
comment:
FontDescriptor.java
line 56-58: can use try-with-resource.
Its a ByteArrayInputStream ther
On 2/19/2015 4:23 PM, Phil Race wrote:
http://cr.openjdk.java.net/~prr/8035302/
I'll let Sherman and others to do the detailed review here. Minor comment:
FontDescriptor.java
line 56-58: can use try-with-resource.
line 62: should it throw UncheckedIOException?
With this change, for
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 correct
Sigh .. try this URL http://cr.openjdk.java.net/~prr/8035302/
The other is inaccessible and not right anyway.
-phil.
On 2/19/15 4:23 PM, Phil Race wrote:
http://javaweb.us.oracle.com/~prrace/8035302/
https://bugs.openjdk.java.net/browse/JDK-8035302
With this change, for the benefit of jigsaw
http://javaweb.us.oracle.com/~prrace/8035302/
https://bugs.openjdk.java.net/browse/JDK-8035302
With this change, for the benefit of jigsaw, the Charset support needed
by the font code
now uses just the public APIs. Some "utility" code was copied from
sun.nio - some of
which could perhaps have
On 2/19/2015 8:06 AM, Roman Kennke wrote:
The impact of including it in OpenJDK seems to be fairly small: it is an
implementation of an existing SPI, and there's no need to make it the
*default* right away. It can be included and live side-by-side and
require some runtime flag to get it enabled.
On 19/02/15 17:06, Roman Kennke wrote:
> Am Donnerstag, den 19.02.2015 um 15:25 +0100 schrieb dalibor topic:
>>
>> On 19.02.2015 13:50, Mario Torre wrote:
>>
>>> The code is part of an OpenJDK project, though, it's already the
>>> existing Java rasterizer.
>>
>> It's not part of an OpenJDK Project
Am Donnerstag, den 05.02.2015 um 19:52 +0300 schrieb Sergey Bylokhov:
> Hello, Roman, Phil.
> The fix looks fine except an absent documentation in new class and
> InternalError + 80 chars per line.
I added a class comment. I added a small msg to the internal error
explaining why it happens (what
Am Donnerstag, den 19.02.2015 um 15:25 +0100 schrieb dalibor topic:
>
> On 19.02.2015 13:50, Mario Torre wrote:
>
> > The code is part of an OpenJDK project, though, it's already the
> > existing Java rasterizer.
>
> It's not part of an OpenJDK Project - Project with an upper case 'P'.
> See ht
On Wed, 2015-02-18 at 16:06 -0800, Phil Race wrote:
> There have been brief internal exchanges every now and again for some
> substantial period
> of time (18 months at least) as to whether we should consolidate the
> various JDK client groups
> in openjdk. The client groups are considered to be
On 19.02.2015 15:50, Mario Torre wrote:
Ok, so let it not be a JEP. Let it not be a separate patch set for
review. What other options are there?
Like I said, you start by finding a suitable home for the code in an
OpenJDK Project.
Once you have that, you can begin the process to bring the nece
Am Mittwoch, den 18.02.2015 um 16:06 -0800 schrieb Phil Race:
> There have been brief internal exchanges every now and again for some
> substantial period
> of time (18 months at least) as to whether we should consolidate the
> various JDK client groups
> in openjdk. The client groups are conside
Could you explain bit more? not sure I understand what you wanted me
to do?
In current version of test all swing methods(including JFrame
constructor) are invoked on the main thread,
this can lead to some vague issues. To avoid such issues they should be
wrapped with SwingUtilities.invokeAndW
On 02/19/2015 11:35 AM, dalibor topic wrote:
> On 15.02.2015 13:39, Laurent Bourgès wrote:
>> Mario & andrews,
>>
>> Thanks for your prompt answers.
>>
>> > I agree with Andrew, getting the JEP proposed is the minimum
>> > requirement to get this work unstuck.
>>
>> Ok, so it is the way to go.
>>
Btw, just to clarify one thing that may have been too subtle in the replies.
I'm all for giving this work a proper home with Graphics Rasterizer,
especially if this means it will get proper evaluation, which is what
should happen after all this discussion :)
What I do want to avoid, is to go arou
2015-02-19 15:25 GMT+01:00 dalibor topic :
>
>
> On 19.02.2015 13:50, Mario Torre wrote:
>
>> The code is part of an OpenJDK project, though, it's already the
>> existing Java rasterizer.
>
>
> It's not part of an OpenJDK Project - Project with an upper case 'P'. See
> http://openjdk.java.net/proje
On 19.02.2015 13:50, Mario Torre wrote:
The code is part of an OpenJDK project, though, it's already the
existing Java rasterizer.
It's not part of an OpenJDK Project - Project with an upper case 'P'.
See http://openjdk.java.net/projects/ for details. Considering the
motivation for this di
Hi ALexander.
On 2/19/2015 6:55 PM, Alexander Zvegintsev wrote:
Hello Prasanta,
I have a couple of comments regarding the test:
We should invoke swing methods on EDT [0].
Could you explain bit more? not sure I understand what you wanted me to do?
I think that this test might be improved by s
Hello Prasanta,
I have a couple of comments regarding the test:
We should invoke swing methods on EDT [0].
I think that this test might be improved by showing an instruction
window before test begins. Instruction should explain what is about
to happen, what behavior is correct. Tester will get
Hi,
It seems XRSurfaceData#getRaster and X11SurfaceData#getRaster was not
implemented resulting in failure in CustomCompositeTest.
I tried implementing the same and the test is passing.
Could you please review the webrev?
Bug: https://bugs.openjdk.java.net/browse/JDK-8007026
webrev: http://cr.
2015-02-19 12:35 GMT+01:00 dalibor topic :
> On 15.02.2015 13:39, Laurent Bourgès wrote:
>>
>> Mario & andrews,
>>
>> Thanks for your prompt answers.
>>
>> > I agree with Andrew, getting the JEP proposed is the minimum
>> > requirement to get this work unstuck.
>>
>> Ok, so it is the way to go.
>
On 15.02.2015 13:39, Laurent Bourgès wrote:
Mario & andrews,
Thanks for your prompt answers.
> I agree with Andrew, getting the JEP proposed is the minimum
> requirement to get this work unstuck.
Ok, so it is the way to go.
I don't think that filing JEPs for code that isn't part of an Ope
23 matches
Mail list logo