I had another thought here.
If you have some plan where you can identify incoming paths as "probably benefiting from more aggressive clipping logic"
vs others that are classified as "most likely will have little to no clipping" and you want to avoid the overhead of
having the early-rejection
Hi Jim,
I am answering your first message:
Area is overkill for this as it tries to find exact intersection points of
arbitrary geometry. You simply need something that will trace accurately
around the outside of a clip to get from an exit point back to an entry
point. That is a much simpler
Hi Phil
Looks good to me as well.
Tim
On 08/31/17 12:48, Sergey Bylokhov wrote:
+1
On 8/31/17 12:21, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8183351
Webrev: http://cr.openjdk.java.net/~prr/8183351/
This bug caused an internal test system to report a failure of this
To be clear, all that would be needed in cubicTo would be:
if (y0 > bot && y1 > bot && y2 > bot && y3 > bot) { xy0 = xy3; return; }
if (y0 < top && y1 < top && y2 < top && y3 < top) { xy0 = xy3; return; }
if (x0 > rgt && x1 > rgt && x2 > rgt && x3 > rgt) { xy0 = xy3; return; }
if (x0 < lft && x1
+1
On 8/31/17 12:21, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8183351
Webrev: http://cr.openjdk.java.net/~prr/8183351/
This bug caused an internal test system to report a failure of this test
when the userid used to run the tests changed due to lack of this cleanup,
so
Hi Laurent,
Area is overkill for this as it tries to find exact intersection points of arbitrary geometry. You simply need
something that will trace accurately around the outside of a clip to get from an exit point back to an entry point.
That is a much simpler operation.
The performance
Bug: https://bugs.openjdk.java.net/browse/JDK-8183351
Webrev: http://cr.openjdk.java.net/~prr/8183351/
This bug caused an internal test system to report a failure of this test
when the userid used to run the tests changed due to lack of this cleanup,
so I'd like to get this one in soon.
It is a
I have a weird issue with fonts in RHEL (and that means likely means
all derivative, like CentOS and Oracle Linux), although it appears
that the same issue can be replicated on a Fedora 26.
The issue is this one, in case you want to see more details:
Hi All,
Please review a fix for an issue where it a NPE is seen when an attempt
is made to print to Brother HL-2240D series printer.
It seems when RasterPrinterJob#setAttributes() is called with no
PrinterResolution attribute set, it first checks if PrinterResolution
category is supported.
