Re: [OpenJDK 2D-Dev] [9] Review request for 8160124 SunGraphics2D.hitClip() can give wrong result for floating point scale
Ah, this is an issue of what an empty rectangle means.
Filling 1.5,1.5,0,0 produces no output because it has no interior.
But, stroking 1.5,1.5,0,0 can produce output because it is simply a
rectangle that spins in place.
As a result there are really 3 different containment properties for a
rectangle - one that has area, one that has only location/no area, and
one that has neither location nor area. This is discussed in the class
comments for java.awt.Rectangle. isEmpty() indicates whether any area
is covered, but the Rectangle may still accumulate into bounds
calculations (via union operations) and other similar operations will
treat its location as valid even if it encompasses no area.
The issue is what should Rectangle2D.getBounds() return? We decided to
do a min/max on the origin coordinate if the width/height are 0 because
of this "it exists even if it covers no area" issue.
But, clip areas are governed by what pixels would be filled, which is
not reflected in the way that getBounds() works.
What is going wrong in SG2D is that it is using Rectangle2D.getBounds()
to compute the containment of the clip, but that does a min/max on the
area rather than compute which pixels would be hit by a fill operation.
We should replace that calculation with a more accurate computation on
which centers of pixels are included in the Rectangle2D, something like:
Rectangle2D rClip = (Rectangle2D) usrClip;
int x0 = (int) Math.ceil(rClip.getMinX() - 0.5);
int y0 = (int) Math.ceil(rClip.getMinY() - 0.5);
int x1 = (int) Math.ceil(rClip.getMaxX() - 0.5);
int x1 = (int) Math.ceil(rClip.getMaxY() - 0.5);
clipRegion = devClip.getIntersectionXYXY(x0, y0, x1, y1);
Some work and testing should be done to see what happens when any of the
min/max/xy coordinates overflow an integer, but that would be the basic
gist of what we should be doing in that case in validateCompClip()...
...jim
On 07/26/2016 02:50 PM, Sergey Bylokhov wrote:
On 13.07.16 5:42, Jim Graham wrote:
What does the compClip end up being in that case?
BufferedImage bi = new
BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB);
SunGraphics2D graphics = (SunGraphics2D) bi.createGraphics();
graphics.scale(1.5, 1.5);
graphics.setClip(1, 1, 0, 0);
System.out.println("clip = " + graphics.getClip().getBounds2D());
System.out.println("clip.isEmpty = " +
graphics.getClip().getBounds2D().isEmpty());
boolean hit = graphics.hitClip(1, 1, 1, 1);
System.out.println("hit = " + hit);
System.out.println("compClip = " + graphics.getCompClip());
System.out.println("compClip.isEmpty = " +
graphics.getCompClip().isEmpty());
The output:
clip = java.awt.geom.Rectangle2D$Double[x=1.0,y=1.0,w=0.0,h=0.0]
clip.isEmpty = true
hit = true
compClip = Region[[1, 1 => 2, 2]]
compClip.isEmpty = false
So the graphics.getClip() returns empty clip, but compClip is not empty.
It seems this occurs when we intersect usrClip
=[x=1.5,y=1.5,w=0.0,h=0.0] and devClip=Region[[0, 0 => 10, 10]] because
result is clipRegion=Region[[1, 1 => 2, 2]]
The code in question is:
protected void validateCompClip() {
.
clipRegion = devClip.getIntersection(usrClip.getBounds());
.
}
The usrClip.getBounds() method will change [x=1.5,y=1.5,w=0.0,h=0.0] to
[x=1,y=1,w=1,h=1], so the empty Rectangle2D became non-empty.
...jim
On 7/4/16 1:12 AM, Sergey Bylokhov wrote:
On 01.07.16 2:49, Jim Graham wrote:
How is it returning true? If the clip really is empty, then
intersectsQuickCheck() should never return true. Or are you saying
that
an empty clip shape produces a non-empty composite clip region?
This code will test such situation:
BufferedImage bi = new
BufferedImage(10,10,BufferedImage.TYPE_INT_ARGB);
Graphics2D graphics = bi.createGraphics();
graphics.scale(1.5, 1.5);
graphics.setClip(1, 1, 0, 0);
System.out.println("empty = " +
graphics.getClip().getBounds2D().isEmpty());
boolean hit = graphics.hitClip(1, 1, 1, 1);
System.out.println("hit = " + hit);
if "graphics.scale(1.5, 1.5);" will be removed then correct false will
be printed. In both cases the clip will be empty
but hitCLip will return different result in case of scaled SG2D.
...jim
On 06/30/2016 10:02 AM, Sergey Bylokhov wrote:
It looks strange that the empty clip became "non-empty"(at least
hitClip
reports this) when we apply transform to it, no? I guess that at the
beginning of hitClip() we should check that the clip.isEmpty(), and we
should return "false" in this case(I think this is not strictly
related
to this bug)?
On 24.06.16 1:14, Jim Graham wrote:
Think of this method as asking:
I don't want you to waste a lot of time, but tell me if it is silly
for
me to even consider rendering something with these bounds.
And the answer is either "Oh, yeah, it is inconceivable that those
bounds would be rendered", or "Not
Re: [OpenJDK 2D-Dev] RFR: 8162429: Clean up obsolete font preferences for JDS.
Looks good. Jennifer On 7/22/2016 1:02 PM, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8162429 http://cr.openjdk.java.net/~prr/8162429/ Clean up some now obsolete font code. -phil.
Re: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure
Not that strange considering it was just pushed a few hours ago.
I'll have to merge these before pushing my fix ..
-phil.
On 07/26/2016 08:10 AM, Prasanta Sadhukhan wrote:
Looks good.
But strangely, I do not see this function in this file when Phil sent
for review for his disable warning fix ;-)
Regards
Prasanta
On 7/26/2016 8:20 PM, Vadim Pakhnushev wrote:
Hi all,
Please review the build failure fix for:
https://bugs.openjdk.java.net/browse/JDK-8162545
diff -r c0cf6ec85273
src/java.desktop/share/native/libjavajpeg/imageioJPEG.c
--- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul
26 15:55:22 2016 +0300
+++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul
26 17:49:12 2016 +0300
@@ -2634,7 +2634,7 @@
RELEASE_ARRAYS(env, data, NULL);
}
-static void freeArray(void** arr, jint size) {
+static void freeArray(UINT8** arr, jint size) {
int i;
if (arr != NULL) {
for (i = 0; i < size; i++) {
Thanks,
Vadim
Re: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure
I checked that this fix passes JPRT with Phil's fix as well.
Vadim
On 26.07.2016 18:10, Prasanta Sadhukhan wrote:
Looks good.
But strangely, I do not see this function in this file when Phil sent
for review for his disable warning fix ;-)
Regards
Prasanta
On 7/26/2016 8:20 PM, Vadim Pakhnushev wrote:
Hi all,
Please review the build failure fix for:
https://bugs.openjdk.java.net/browse/JDK-8162545
diff -r c0cf6ec85273
src/java.desktop/share/native/libjavajpeg/imageioJPEG.c
--- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul
26 15:55:22 2016 +0300
+++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul
26 17:49:12 2016 +0300
@@ -2634,7 +2634,7 @@
RELEASE_ARRAYS(env, data, NULL);
}
-static void freeArray(void** arr, jint size) {
+static void freeArray(UINT8** arr, jint size) {
int i;
if (arr != NULL) {
for (i = 0; i < size; i++) {
Thanks,
Vadim
Re: [OpenJDK 2D-Dev] RFR: 8162545: Mac build failure
Looks good.
But strangely, I do not see this function in this file when Phil sent
for review for his disable warning fix ;-)
Regards
Prasanta
On 7/26/2016 8:20 PM, Vadim Pakhnushev wrote:
Hi all,
Please review the build failure fix for:
https://bugs.openjdk.java.net/browse/JDK-8162545
diff -r c0cf6ec85273
src/java.desktop/share/native/libjavajpeg/imageioJPEG.c
--- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul
26 15:55:22 2016 +0300
+++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul
26 17:49:12 2016 +0300
@@ -2634,7 +2634,7 @@
RELEASE_ARRAYS(env, data, NULL);
}
-static void freeArray(void** arr, jint size) {
+static void freeArray(UINT8** arr, jint size) {
int i;
if (arr != NULL) {
for (i = 0; i < size; i++) {
Thanks,
Vadim
[OpenJDK 2D-Dev] RFR: 8162545: Mac build failure
Hi all,
Please review the build failure fix for:
https://bugs.openjdk.java.net/browse/JDK-8162545
diff -r c0cf6ec85273 src/java.desktop/share/native/libjavajpeg/imageioJPEG.c
--- a/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul 26
15:55:22 2016 +0300
+++ b/src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Tue Jul 26
17:49:12 2016 +0300
@@ -2634,7 +2634,7 @@
RELEASE_ARRAYS(env, data, NULL);
}
-static void freeArray(void** arr, jint size) {
+static void freeArray(UINT8** arr, jint size) {
int i;
if (arr != NULL) {
for (i = 0; i < size; i++) {
Thanks,
Vadim
Re: [OpenJDK 2D-Dev] RFR: 8074827: Resolve disabled warnings for libjavajpeg
+1 On 26.07.16 9:03, Prasanta Sadhukhan wrote: Looks good. Regards Prasanta On 7/26/2016 11:10 AM, Philip Race wrote: https://bugs.openjdk.java.net/browse/JDK-8074827 http://cr.openjdk.java.net/~prr/8074827/ Passes JPRT. gcc clobbered is left since that seems to be a gcc bug fixed in a later gcc -phil. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8162488: JDK should be updated to use LittleCMS 2.8
On 7/25/16, 10:51 PM, Prasanta Sadhukhan wrote: Just curious, cmscgats.c#why snprintf(Buffer, 1023,...) is used for a buffer of 1024 bytes. snprintf says, The generated string has a length of at most n-1, leaving space for the additional terminating null character so if we specify 1023, then 1022 bytes will be copied and 1023th byte will be terminating null character. Not sure. A harmless abundance of caution ? .. cmsgamma.c copyright year is not modified. SEP. cmslut.c., cmsmtrx.c, has 2 extra lines at the end I noticed a few. I intend to leave them unless jcheck objects. Minimum differences from upstream .. -phil. but I understand we take this lib as it is from open source so probably ok and if that is the case, +1 fro me. Regards Prasanta On 7/26/2016 2:14 AM, Phil Race wrote: The alpha support does not affect JDK .. you need to set a flag to enable it - else the new code just returns - and we do not set this (new) flag. Something to investigate maybe, but no immediate or necessary impact that I see. -phil. On 07/25/2016 01:42 PM, Sergey Bylokhov wrote: On 25.07.16 22:41, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8162488 Webrev : http://cr.openjdk.java.net/~prr/8162488 LCMS 2.8 has been released. JDK should keep up to date. I have verified via JPRT that the updated version builds cleanly on all platforms. Also ran Java2Demo and graphics/imaging/color regression tests to verify no new problems there. This should be backported to JDK 8u once it has been integrated to 9. Looks fine. The alpha support is the main new feature. Is it affects the jdk functionality? If yes then should we provide some test to check, if not then should we use this feature somehow?
Re: [OpenJDK 2D-Dev] RFR: 8074827: Resolve disabled warnings for libjavajpeg
Looks good. Regards Prasanta On 7/26/2016 11:10 AM, Philip Race wrote: https://bugs.openjdk.java.net/browse/JDK-8074827 http://cr.openjdk.java.net/~prr/8074827/ Passes JPRT. gcc clobbered is left since that seems to be a gcc bug fixed in a later gcc -phil.
