Re: [OpenJDK 2D-Dev] [12] RFR JDK-8212040: Compilation error due to wrong usage of NSPrintJobDispositionValue in mac10.12

[Jayathirth D V]

Hi Prasanta,

 

Changes are fine.

 

Thanks,

Jay

 

From: Prasanta Sadhukhan 
Sent: Thursday, October 11, 2018 1:40 PM
To: 2d-dev
Subject: [OpenJDK 2D-Dev] [12] RFR JDK-8212040: Compilation error due to wrong 
usage of NSPrintJobDispositionValue in mac10.12

 

Hi All,

Please review a build issue fix for usage of NSPrintJobDispositionValue in 
HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8211055"JDK-8211055: 
Provide print to a file (PDF) feature even when printer was not connected
It seems that NSPrintJobDispositionValue is added in 10.13 sdk 
[https://developer.apple.com/documentation/appkit/nsprintjobdispositionvalue?language=objc]
so using it in 10.12 or lower cause build issue.

Fix is to check for disposition value directly instead of storing in variable.
mach5 build is successful.

Bug:https://bugs.openjdk.java.net/browse/JDK-8212040
webrev: http://cr.openjdk.java.net/~psadhukhan/8212040/webrev/

Regards
Prasanta

Re: [OpenJDK 2D-Dev] [12] RFR JDK-8212040: Compilation error due to wrong usage of NSPrintJobDispositionValue in mac10.12

[Prasanta Sadhukhan]

Ping? Since this fix addresses build failure which will affect 
production, I guess this needs to go in asap.


Regards
Prasanta
On 11-Oct-18 1:39 PM, Prasanta Sadhukhan wrote:

Hi All,

Please review a build issue fix for usage of 
NSPrintJobDispositionValue in JDK-8211055 
: Provide print to a 
file (PDF) feature even when printer was not connected
It seems that NSPrintJobDispositionValue is added in 10.13 sdk 
[https://developer.apple.com/documentation/appkit/nsprintjobdispositionvalue?language=objc]

so using it in 10.12 or lower cause build issue.

Fix is to check for disposition value directly instead of storing in 
variable.

mach5 build is successful.

Bug:https://bugs.openjdk.java.net/browse/JDK-8212040
webrev: http://cr.openjdk.java.net/~psadhukhan/8212040/webrev/

Regards
Prasanta

Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

[Bill York]

Thanks Sergey.

On 10/11/18, 5:43 PM, "Sergey Bylokhov"  wrote:

Hi, Bill.

The similar bug was reported recently:
https://bugs.openjdk.java.net/browse/JDK-8211992

The root cause is how we use CoreGraphics display ID. This identifier can 
become non-valid at any time therefore methods, which is using this id should 
be ready to it.

And this bug found a few places which does not take care about the rule 
above.

I am working on the fix for jdk12.

On 10/10/2018 08:45, Bill York wrote:
> 2d-dev folks,
> 
> I work on a product called MATLAB and we have about 60 reports from 
customers on Mac related to a crash in CGraphicsDevice.m
> 
> Please let  me know if this is the right way to report a crash and 
discuss getting it resolved.
> 
> Here are the details:
> 
> CGraphicsDevice.m is a native file in support of Java drawing and gets 
called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode
> 
> While I can’t reproduce the problem, it looks like the display pointer is 
becoming invalid for a time when the user’s laptop opens or closes.
> 
> Looking at this source code:
> 
> 
http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
> 
> I see a direct call to CFStringCompare without a check for a NULL 
CFStringRef.
> 
>   * (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo)
> 
> I believe if this code returned 0, the crash would not occur though there 
may be some other cleanup in the surrounding call frames.
> 
> Bill
> 


-- 
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

[Peter Hull]

This has been given a Java bug number now: JDK-8212124
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8212124

I have been following the discussion here and I have a couple of
workarounds to try, which is great.

But, is there any more information you need from me? I'm always happy to help.

Thanks,
Pete

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

[Philip Race]

If there are no comments in the source, then there is no documentation :-(
Reverse engineering/studying the code is what we'd have to do if that were
the approach to be taken here.

-phil.

On 10/12/18, 2:18 AM, Laurent Bourgès wrote:

Phil,
I looked at the hostpot in 
src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c 
(75% cpu time) and its sort algorithm looks like an insertion sort ...
If you could give me some explanations (or documentation), I could try 
optimizing this method.


Do you know if it uses an Active Edge Table (AET) or it traverses all 
segments every time ?

i.e. segmentTable contains only ACTIVE segments or all ?

Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

[Bill York]

Excellent. That looks like the same bug. Note that it also affects JDK8.

Bill

On 10/11/18, 5:43 PM, "Sergey Bylokhov"  wrote:

Hi, Bill.

The similar bug was reported recently:
https://bugs.openjdk.java.net/browse/JDK-8211992

The root cause is how we use CoreGraphics display ID. This identifier can 
become non-valid at any time therefore methods, which is using this id should 
be ready to it.

And this bug found a few places which does not take care about the rule 
above.

I am working on the fix for jdk12.

On 10/10/2018 08:45, Bill York wrote:
> 2d-dev folks,
> 
> I work on a product called MATLAB and we have about 60 reports from 
customers on Mac related to a crash in CGraphicsDevice.m
> 
> Please let  me know if this is the right way to report a crash and 
discuss getting it resolved.
> 
> Here are the details:
> 
> CGraphicsDevice.m is a native file in support of Java drawing and gets 
called from Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode
> 
> While I can’t reproduce the problem, it looks like the display pointer is 
becoming invalid for a time when the user’s laptop opens or closes.
> 
> Looking at this source code:
> 
> 
http://cr.openjdk.java.net/~serb/8000629/webrev.08/src/macosx/native/sun/awt/CGraphicsDevice.m.html
> 
> I see a direct call to CFStringCompare without a check for a NULL 
CFStringRef.
> 
>   * (CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo)
> 
> I believe if this code returned 0, the crash would not occur though there 
may be some other cleanup in the surrounding call frames.
> 
> Bill
> 


-- 
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] Speed of drawPolyline on JDK11

[Laurent Bourgès]

Phil,
I looked at the hostpot in
src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c (75%
cpu time) and its sort algorithm looks like an insertion sort ...
If you could give me some explanations (or documentation), I could try
optimizing this method.

Do you know if it uses an Active Edge Table (AET) or it traverses all
segments every time ?
i.e. segmentTable contains only ACTIVE segments or all ?

static jboolean
ShapeSINextSpan(void *state, jint spanbox[])
{
pathData *pd = (pathData *)state;
int lo, cur, new, hi;
int num = pd->numSegments;
jint x0, x1, y0, err;
jint loy;
int ret = JNI_FALSE;
segmentData **segmentTable;
segmentData *seg;

if (pd->state != STATE_SPAN_STARTED) {
if (!initSegmentTable(pd)) {
/* REMIND: - throw exception? */
pd->lowSegment = num;
return JNI_FALSE;
}
}

lo = pd->lowSegment;
cur = pd->curSegment;
hi = pd->hiSegment;
num = pd->numSegments;
loy = pd->loy;
segmentTable = pd->segmentTable;

while (lo < num) {
if (cur < hi) {
seg = segmentTable[cur];
x0 = seg->curx;
if (x0 >= pd->hix) {
cur = hi;
continue;
}
if (x0 < pd->lox) {
x0 = pd->lox;
}

if (pd->evenodd) {
cur += 2;
if (cur <= hi) {
x1 = segmentTable[cur - 1]->curx;
} else {
x1 = pd->hix;
}
} else {
int wind = seg->windDir;
cur++;

while (JNI_TRUE) {
if (cur >= hi) {
x1 = pd->hix;
break;
}
seg = segmentTable[cur++];
wind += seg->windDir;
if (wind == 0) {
x1 = seg->curx;
break;
}
}
}

if (x1 > pd->hix) {
x1 = pd->hix;
}
if (x1 <= x0) {
continue;
}
spanbox[0] = x0;
spanbox[1] = loy;
spanbox[2] = x1;
spanbox[3] = loy + 1;
ret = JNI_TRUE;
break;
}

if (++loy >= pd->hiy) {
lo = cur = hi = num;
break;
}

/* Go through active segments and toss which end "above" loy */
cur = new = hi;
while (--cur >= lo) {
seg = segmentTable[cur];
if (seg->lasty > loy) {
segmentTable[--new] = seg;
}
}

lo = new;
if (lo == hi && lo < num) {
/* The current list of segments is empty so we need to
 * jump to the beginning of the next set of segments.
 * Since the segments are not clipped to the output
 * area we need to make sure we don't jump "backwards"
 */
seg = segmentTable[lo];
if (loy < seg->cury) {
loy = seg->cury;
}
}

/* Go through new segments and accept any which start "above" loy */
while (hi < num && segmentTable[hi]->cury <= loy) {
hi++;
}

/* Update and sort the active segments by x0 */
for (cur = lo; cur < hi; cur++) {
seg = segmentTable[cur];

/* First update the x0, y0 of the segment */
x0 = seg->curx;
y0 = seg->cury;
err = seg->error;
if (++y0 == loy) {
x0 += seg->bumpx;
err += seg->bumperr;
x0 -= (err >> 31);
err &= ERRSTEP_MAX;
} else {
jlong steps = loy;
steps -= y0 - 1;
y0 = loy;
x0 += (jint) (steps * seg->bumpx);
steps = err + (steps * seg->bumperr);
x0 += (jint) (steps >> 31);
err = ((jint) steps) & ERRSTEP_MAX;
}
seg->curx = x0;
seg->cury = y0;
seg->error = err;








*/* Then make sure the segment is sorted by x0 */
for (new = cur; new > lo; new--) {segmentData *seg2 =
segmentTable[new - 1];if (seg2->curx <= x0)
{break;}
segmentTable[new] = seg2;}*
segmentTable[new] = seg;
}
cur = lo;
}

pd->lowSegment = lo;
pd->hiSegment = hi;
pd->curSegment = cur;
pd->loy = loy;
return ret;
}

Cheers,
Laurent

Le ven. 12 oct. 2018 à 07:04, Laurent Bourgès  a
écrit :

> Phil,
>
> It reminds me I have rewritten in Marlin renderer the crossing sort at
> every scanline.
> Pisces was using a trivial insertion sort but it became very slow when the
> crossing count is