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

[Laurent Bourgès]

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 large.
I adopted a special merge sort as crossings are mostly ordered: big win.

What sort algo is in action in drawPolyLine ?

Cheers,
Laurent

Le ven. 12 oct. 2018 à 01:15, Phil Race  a écrit :

>
> In my previous email I was asking only about the "older" system,
> precisely because as you confirm below, I wanted to know that
> it was operating on an unscaled graphics.
>
> It is being triggered by the scale. If you add :
> graphics.scale(1.25, 1.25)
> in your application and run on 8 you'll see the window size is
> not changed but the contents are and the test now runs slowly
> like the JDK 9+ case.
>
> I think most primitives (text, images, fills, gradients, untransformed
> rectangle drawing) will be only slightly slower. The same if
> you were drawing anti-aliased lines - they are going to be slow already
> by comparison.
>
> A few similar primitives (drawArc, drawOval, drawPolygon ..) may be
> similarly
> affected but drawPolyLine even has dedicated loops for single pixel wide
> lines
> so may be the most affected when these loops can't be used.
>
> So this is a kind of worse case difference. Untransformed, aliased lines
> are super fast.
> Once you do anything like add anti-aliasing or a transform, they get
> slower.
>
> Note: hidpi does not mean that acceleration is "turned off", rather that
> some operations can no longer be sent to the accelerated pipeline, either
> it doesn't support that mode, or we haven't implemented the necessary code
> to invoke it for that mode.
>
> In Peter's case on Intel there will be no acceleration, since we do not
> enable D3D
> on Intel graphics cards. But on my system the time is identical whether
> I use D3D or not.
>
> But there is something else going on here too.
> Peter's test use 2^16 line segments.
>
> On my windows system at 1.25 scale, this takes 55 seconds to run.
> But 2^15 line segments completes in 10 seconds.
> So 2 x the no. of lines takes approx 5 times as long to run ..
>
> I have a modified version of Peter's program which breaks the polyline
> array
> into subarrays which get passed to multiple calls to drawPolyline.
> It misses joining the last point in ARR[N] to the first point in
> ARR[N+1] but
> I think that should not make much difference but if someone wants to use
> that in a real app they'll need to handle it.
>
> What I see is that using the smaller arrays makes a big difference.
>
> So instead of 60 seconds to draw one 65,536 element polyline, to
> draw 64 polylines of 1,024 elements takes just 1.1 seconds.
> Still not 0.05 but better.
>  From what I can see it is being turned into a huge GeneralPath and
> rendered as a Shape. Multiple smaller shapes perform better.
> Perhaps we can add a loop that is specific to polygons that will handle
> this better, but that isn't likely to be jumped on .. and obviously
> it will never be *as* fast as narrow lines.
>
> -phil.
>
>
>
> On 10/11/2018 04:26 AM, Peter Hull wrote:
> > Hi Laurent,
> > Thanks for the detailed explanation. I quickly checked on the older
> > Windows system and the Java 11 window was the same size as the Java 8
> > one, implying no scaling was going on (I guess just because it has a
> > lower resolution monitor) - so that confirms your hypothesis.
> >
> > If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
> > matter if the window is a bit small. However I believe some higher end
> > systems have much higher scaling factors (2x, 3x?). Is there a general
> > way to specify a 1px line regardless of scaling, because in my case I
> > don't mind too much if it's a 'hair-line'?
> >
> > By the way, my actual application doesn't have 65000 lines but it
> > draws 3 graphs with about 3000 points, which makes it noticeably slow
> > when resizing the Window. I suppose I should look into cutting down
> > the number of points somehow...
> >
> > Pete
>
>

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

[Philip Race]

And something else to try .. which I haven't tried, since I now believe
the problem isn't the drawing performance of a wide line, is to see
what happens if you do go that path - ie try 3,000 individual drawline 
calls.

It depends how much overhead matters whether it is better than (say)
breaking it into 100 calls with 30 points to drawPolyline ..

-phil.

On 10/11/18, 4:15 PM, Phil Race wrote:



By the way, my actual application doesn't have 65000 lines but it
draws 3 graphs with about 3000 points, which makes it noticeably slow
when resizing the Window. I suppose I should look into cutting down
the number of points somehow...

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

[Phil Race]

In my previous email I was asking only about the "older" system,
precisely because as you confirm below, I wanted to know that
it was operating on an unscaled graphics.

It is being triggered by the scale. If you add :
graphics.scale(1.25, 1.25)
in your application and run on 8 you'll see the window size is
not changed but the contents are and the test now runs slowly
like the JDK 9+ case.

I think most primitives (text, images, fills, gradients, untransformed
rectangle drawing) will be only slightly slower. The same if
you were drawing anti-aliased lines - they are going to be slow already 
by comparison.


A few similar primitives (drawArc, drawOval, drawPolygon ..) may be 
similarly
affected but drawPolyLine even has dedicated loops for single pixel wide 
lines

so may be the most affected when these loops can't be used.

So this is a kind of worse case difference. Untransformed, aliased lines 
are super fast.

Once you do anything like add anti-aliasing or a transform, they get slower.

Note: hidpi does not mean that acceleration is "turned off", rather that
some operations can no longer be sent to the accelerated pipeline, either
it doesn't support that mode, or we haven't implemented the necessary code
to invoke it for that mode.

In Peter's case on Intel there will be no acceleration, since we do not 
enable D3D
on Intel graphics cards. But on my system the time is identical whether 
I use D3D or not.


But there is something else going on here too.
Peter's test use 2^16 line segments.

On my windows system at 1.25 scale, this takes 55 seconds to run.
But 2^15 line segments completes in 10 seconds.
So 2 x the no. of lines takes approx 5 times as long to run ..

I have a modified version of Peter's program which breaks the polyline array
into subarrays which get passed to multiple calls to drawPolyline.
It misses joining the last point in ARR[N] to the first point in 
ARR[N+1] but

I think that should not make much difference but if someone wants to use
that in a real app they'll need to handle it.

What I see is that using the smaller arrays makes a big difference.

So instead of 60 seconds to draw one 65,536 element polyline, to
draw 64 polylines of 1,024 elements takes just 1.1 seconds.
Still not 0.05 but better.
From what I can see it is being turned into a huge GeneralPath and
rendered as a Shape. Multiple smaller shapes perform better.
Perhaps we can add a loop that is specific to polygons that will handle
this better, but that isn't likely to be jumped on .. and obviously
it will never be *as* fast as narrow lines.

-phil.



On 10/11/2018 04:26 AM, Peter Hull wrote:

Hi Laurent,
Thanks for the detailed explanation. I quickly checked on the older
Windows system and the Java 11 window was the same size as the Java 8
one, implying no scaling was going on (I guess just because it has a
lower resolution monitor) - so that confirms your hypothesis.

If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
matter if the window is a bit small. However I believe some higher end
systems have much higher scaling factors (2x, 3x?). Is there a general
way to specify a 1px line regardless of scaling, because in my case I
don't mind too much if it's a 'hair-line'?

By the way, my actual application doesn't have 65000 lines but it
draws 3 graphs with about 3000 points, which makes it noticeably slow
when resizing the Window. I suppose I should look into cutting down
the number of points somehow...

Pete

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

[Sergey Bylokhov]

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] Setting the FreeType LCD filter

[Phil Race]

Very well done analysis of the options and very thorough testing of the 
effects

on the different libraries/platforms.


> There are some alternatives to setting the filter:
>   • Bundle the FreeType library by default

Although the build makes this easy to set as an option, we decided we 
prefer to
use the platform library on Linux - and Solaris for that matter - in our 
releases.


So setting this option is going to be needed for some years to come, until
even a Linux current release like Ubuntu 18.04 is obsolete.

We can't re-use the OpenJavaFX bug ID, and surprisingly I can't find an open
bug on this for 2D. So I've submitted 
https://bugs.openjdk.java.net/browse/JDK-8212071


And I've attached John's images to the bug report and pasted his email 
in there.




-phil.


On 10/11/2018 10:56 AM, John Neffenger wrote:

On 10/10/2018 11:15 AM, Laurent Bourgès wrote:

It looks awesome & promising.


Thank you, Laurent, for looking into it so quickly!

PS: It is better to send plain text (long) email than sending 
external links (github).


Thanks for the tip. Right, Web pages and repositories can be deleted, 
so here it is, for the record ...


The symptoms of the problem are the same as in the link below, but 
they appear in AWT and Swing applications instead of JavaFX applications.


  JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
  https://bugs.openjdk.java.net/browse/JDK-8188810

The description of the problem on the Java side follows.

Synopsis: Reduce color fringes in FreeType subpixel rendering

The text in Java applications often has severe color fringes when 
using OpenJDK on Ubuntu and other Debian-based distributions because 
the JDK fails to set the LCD filter. Adding two lines of code to the 
file freetypeScaler.c fixed the problem in my tests, without any 
regression errors for other Linux distributions. The patch is attached 
to this message as the file freetypeScaler.diff.


There are some alternatives to setting the filter:

  • Bundle the FreeType library by default and always use the new 
Harmony subpixel rendering technique. This option removes the 
uncertainty in the library at the expense of an additional 4.6 
megabytes to the installed size — an increase of less than one 
percent. OpenJDK 12 even includes the latest FreeType 2.9.1, a newer 
version than the one found on most systems.


  • Wait another year and see what changes are made to FreeType, if 
any, when the ClearType patents expire. This option, though, doesn’t 
solve the problem that users of Ubuntu and other Debian-based 
distributions have now.


The problem originates in decisions made by the developers of 
FreeType, Debian, Fedora, and OpenJDK concerning the Microsoft 
ClearType patents [1].


  • In 2007, FreeType 2.3.0 added a compiler configuration macro to 
the file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If 
defined, the FreeType library includes patented ClearType techniques 
in its subpixel rendering.


    But there’s a catch. When the ClearType methods are enabled, the 
subpixel rendering is not filtered, which results in severe color 
fringes. Clients of the FreeType library must make an explicit call to 
the function FT_Library_SetLcdFilter to apply color filtering. The 
filter was disabled by default, explained one of its authors, “to 
avoid major surprises to existing clients, including libXft and Cairo 
which already perform some wacky color filtering on top of FreeType.”


  • In 2009, Debian created a patch to FreeType 2.3.9, named 
enable-subpixel-rendering.patch, that defines the macro and enables 
ClearType-style rendering. The change log states, “This is considered 
no more or less evil than the bytecode interpreter which we also 
enable.” Ubuntu, based on Debian, applies the patch as well. Fedora 
created the same patch in 2007, named freetype-2.3.0-enable-spr.patch, 
but does not apply the patch by default.


  • In 2017, FreeType 2.8.1 included a new subpixel rendering 
technique, called Harmony, that is nearly identical in output to the 
ClearType technique but uses a different algorithm, avoiding the 
patents. FreeType now uses Harmony subpixel rendering when the 
ClearType methods are disabled, with no need for clients to set the 
LCD filter. (This would have been a good time for Debian to remove its 
subpixel rendering patch.) The latest Fedora Workstation 28 runs 
FreeType 2.8.0, which does not include Harmony.


  • In 2019, the Microsoft ClearType patents expire.

So now we have two variants of the FreeType library: one that requires 
a function call to set the LCD filter in Ubuntu and other 
distributions based on Debian, and another that doesn’t require the 
function call in Red Hat Enterprise Linux, Oracle Linux, and other 
distributions based on Fedora.


To demonstrate the problem, I built four versions of the JDK from the 
latest OpenJDK sources. I built a version that uses the system 
FreeType library and another that uses the bundled FreeType library. 

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

[Bill York]

Hey Phil,

As an update on this discussion, I pulled the latest OpenJDK 8 and got it to 
build on an OSX 10.75 Mac we have here.

To verify that an early return of 0 from getBPPFromModeString works without 
crashing, I forced getBPPFromModeString to return 0 every 5th call and then, 
while our app is running, I changed the display configuraton.

Through use of PRINTF, I verified that getBPPFromModeString got called and did 
an early return.

At first glance, it appears that a check for NULL with an early return of 0 
could prevent the crash we are seeing.

While I can’t force the conditions that demonstrate the customer reported bug, 
it appears that this fix will help.

Bill

From: Bill York 
Date: Thursday, October 11, 2018 at 7:00 AM
To: Phil Race 
Cc: "2d-dev@openjdk.java.net" <2d-dev@openjdk.java.net>, Bill York 

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

Thanks Phil,

All the 61 reports I mentioned below have the same stack. In the same 30 days 
we also received:


  *   120 reports about https://bugs.openjdk.java.net/browse/JDK-8146329 or 
https://bugs.openjdk.java.net/browse/JDK-8133783
 *   I can’t tell the difference between those two bug reports
 *   Note this is fixed in the JetBrains OpenJDK here: 
https://bintray.com/jetbrains/intellij-jdk/download_file?file_path=jbsdk8u152b1136.5_osx_x64.tar.gz

Bill

From: Phil Race 
Date: Wednesday, October 10, 2018 at 4:34 PM
To: Bill York 
Cc: "2d-dev@openjdk.java.net" <2d-dev@openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

Hi,

I expect it would be a good & safe thing to do, to check for NULL.
But I don't know if all of these reports you have are down to that.
Did you get stack traces for all of them ?
We also have open bugs like
https://bugs.openjdk.java.net/browse/JDK-8146329
https://bugs.openjdk.java.net/browse/JDK-8133783
which look different.

-phil.
On 10/10/2018 10:56 AM, Bill York wrote:
Thanks for the response Phil, here’s what I know.

Reports show:

  *   Mac OS – many versions 10.10 through 17.7
  *   Java - 8 u144-b01 (48 reports), 8 u152-b16 (12 reports) 8 
u152-release-1136-b5 – JetBrains (1 report)

Comments say:

  *   Screen change event.  I am using the jetbrains JRE, as you can see in the 
stack trace.
  *   I am on a mac and product crashes very often when I put my computer to 
sleep.
  *   Woke up computer after connecting to two external monitors.

I’ve annotated the function names with links to code I found on the OpenJDK 
site and the Apple site.

As an experiment, I created a simple X-Code project to examine how 
CFSTringCompare behaves when passed NULL. It does throw an EXC_BAD_ACCESS as is 
shown in the below stack trace. My example code is at the end of this message.

Stack trace shows:

[  7] 0x601c5848   
+
[  8] 0x7fff3cc4e678 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920
 
CFStringCompare+0024
[  9] 0x0001351a80f7 java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119031 
getBPPFromModeString+0032
 (see line 32)
[ 10] 0x0001351a819f java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119199 
createJavaDisplayMode+0053
 (see line 130)
[ 11] 0x0001351a841e java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119838 
Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode+0031
 (see line 267)

Example code:


#import 



static int getBPPFromModeString(CFStringRef mode)

{

if ((CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo)) {

// This is a strange mode, where we using 10 bits per RGB component and 
pack it into 32 bits

// Java is not ready to work with this mode but we have to specify it 
as supported

return 30;

}

else if (CFStringCompare(mode, CFSTR(IO32BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

return 32;

}

else if (CFStringCompare(mode, CFSTR(IO16BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

return 16;

}

else if (CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

return 8;

}



return 0;

}



int main(int argc, const char * argv[]) {

@autoreleasepool {

// insert code here...

CFStringRef mode;

getBPPFromModeString(mode);

NSLog(@"Hello, World!");

}

return 0;

}


From: Philip 

Re: [OpenJDK 2D-Dev] Setting the FreeType LCD filter

[John Neffenger]

On 10/11/2018 11:41 AM, Laurent Bourgès wrote:

Maybe just send text and your diff only and keep images as link on github.


Right again. Here's just the text, no attachments, formatted in plain 
text as best I can. Thank you again for your help, Laurent.


The symptoms of the problem are the same as in the link below, but they 
appear in AWT and Swing applications instead of JavaFX applications.


JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
https://bugs.openjdk.java.net/browse/JDK-8188810

The description of the problem on the Java side follows.

Synopsis: Reduce color fringes in FreeType subpixel rendering

The text in Java applications often has severe color fringes when using 
OpenJDK on Ubuntu and other Debian-based distributions because the JDK 
fails to set the LCD filter. Adding two lines of code to the file 
freetypeScaler.c fixed the problem in my tests, without any regression 
errors for other Linux distributions. The patch is included at the very 
end of this message.


There are some alternatives to setting the filter:

  • Bundle the FreeType library by default and always use the new 
Harmony subpixel rendering technique. This option removes the 
uncertainty in the library at the expense of an additional 4.6 megabytes 
to the installed size — an increase of less than one percent. OpenJDK 12 
even includes the latest FreeType 2.9.1, a newer version than the one 
found on most systems.


  • Wait another year and see what changes are made to FreeType, if 
any, when the ClearType patents expire. This option, though, doesn’t 
solve the problem that users of Ubuntu and other Debian-based 
distributions have now.


The problem originates in decisions made by the developers of FreeType, 
Debian, Fedora, and OpenJDK concerning the Microsoft ClearType patents [1].


  • In 2007, FreeType 2.3.0 added a compiler configuration macro to the 
file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If defined, 
the FreeType library includes patented ClearType techniques in its 
subpixel rendering.


But there’s a catch. When the ClearType methods are enabled, the 
subpixel rendering is not filtered, which results in severe color 
fringes. Clients of the FreeType library must make an explicit call to 
the function FT_Library_SetLcdFilter to apply color filtering. The 
filter was disabled by default, explained one of its authors, “to avoid 
major surprises to existing clients, including libXft and Cairo which 
already perform some wacky color filtering on top of FreeType.”


  • In 2009, Debian created a patch to FreeType 2.3.9, named 
enable-subpixel-rendering.patch, that defines the macro and enables 
ClearType-style rendering. The change log states, “This is considered no 
more or less evil than the bytecode interpreter which we also enable.” 
Ubuntu, based on Debian, applies the patch as well. Fedora created the 
same patch in 2007, named freetype-2.3.0-enable-spr.patch, but does not 
apply the patch by default.


  • In 2017, FreeType 2.8.1 included a new subpixel rendering 
technique, called Harmony, that is nearly identical in output to the 
ClearType technique but uses a different algorithm, avoiding the 
patents. FreeType now uses Harmony subpixel rendering when the ClearType 
methods are disabled, with no need for clients to set the LCD filter. 
(This would have been a good time for Debian to remove its subpixel 
rendering patch.) The latest Fedora Workstation 28 runs FreeType 2.8.0, 
which does not include Harmony.


  • In 2019, the Microsoft ClearType patents expire.

So now we have two variants of the FreeType library: one that requires a 
function call to set the LCD filter in Ubuntu and other distributions 
based on Debian, and another that doesn’t require the function call in 
Red Hat Enterprise Linux, Oracle Linux, and other distributions based on 
Fedora.


To demonstrate the problem, I built four versions of the JDK from the 
latest OpenJDK sources. I built a version that uses the system FreeType 
library and another that uses the bundled FreeType library. Then I 
changed the OpenJDK code to set the default LCD filter and built the two 
versions again. The four builds were named:


  jdk-12-system-lcdnone
  jdk-12-system-lcddefault
  jdk-12-bundled-lcdnone
  jdk-12-bundled-lcddefault

The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS, which has 
the Debian patch applied (ClearType methods enabled), while the bundled 
library is FreeType 2.9.1 in OpenJDK 12, which uses the library default 
(ClearType methods disabled). I wrote a simple Java Swing application 
called FontDemo [2] that displays two text areas with the Adobe Source 
Code Pro font [3] in TTF and OTF formats (the latest non-variable download).


The results are shown in the two images below:

fontdemo.png
https://raw.githubusercontent.com/jgneff/openjdk-freetype/master/files/fontdemo.png

fontdemo-detail.png

Re: [OpenJDK 2D-Dev] Setting the FreeType LCD filter

[Laurent Bourgès]

John,

Sorry but attachments are rejected if larger than 100 kb, then your email
is being moderated.

You should put resources online, preferably on openjdk.java.net.

Maybe just send text and your diff only and keep images as link on github.

Laurent

Le jeu. 11 oct. 2018 à 19:56, John Neffenger  a écrit :

> On 10/10/2018 11:15 AM, Laurent Bourgès wrote:
> > It looks awesome & promising.
>
> Thank you, Laurent, for looking into it so quickly!
>
> > PS: It is better to send plain text (long) email than sending external
> > links (github).
>
> Thanks for the tip. Right, Web pages and repositories can be deleted, so
> here it is, for the record ...
>
> The symptoms of the problem are the same as in the link below, but they
> appear in AWT and Swing applications instead of JavaFX applications.
>
>JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
>https://bugs.openjdk.java.net/browse/JDK-8188810
>
> The description of the problem on the Java side follows.
>
> Synopsis: Reduce color fringes in FreeType subpixel rendering
>
> The text in Java applications often has severe color fringes when using
> OpenJDK on Ubuntu and other Debian-based distributions because the JDK
> fails to set the LCD filter. Adding two lines of code to the file
> freetypeScaler.c fixed the problem in my tests, without any regression
> errors for other Linux distributions. The patch is attached to this
> message as the file freetypeScaler.diff.
>
> There are some alternatives to setting the filter:
>
>• Bundle the FreeType library by default and always use the new
> Harmony subpixel rendering technique. This option removes the
> uncertainty in the library at the expense of an additional 4.6 megabytes
> to the installed size — an increase of less than one percent. OpenJDK 12
> even includes the latest FreeType 2.9.1, a newer version than the one
> found on most systems.
>
>• Wait another year and see what changes are made to FreeType, if
> any, when the ClearType patents expire. This option, though, doesn’t
> solve the problem that users of Ubuntu and other Debian-based
> distributions have now.
>
> The problem originates in decisions made by the developers of FreeType,
> Debian, Fedora, and OpenJDK concerning the Microsoft ClearType patents [1].
>
>• In 2007, FreeType 2.3.0 added a compiler configuration macro to the
> file ftoption.h named FT_CONFIG_OPTION_SUBPIXEL_RENDERING. If defined,
> the FreeType library includes patented ClearType techniques in its
> subpixel rendering.
>
>  But there’s a catch. When the ClearType methods are enabled, the
> subpixel rendering is not filtered, which results in severe color
> fringes. Clients of the FreeType library must make an explicit call to
> the function FT_Library_SetLcdFilter to apply color filtering. The
> filter was disabled by default, explained one of its authors, “to avoid
> major surprises to existing clients, including libXft and Cairo which
> already perform some wacky color filtering on top of FreeType.”
>
>• In 2009, Debian created a patch to FreeType 2.3.9, named
> enable-subpixel-rendering.patch, that defines the macro and enables
> ClearType-style rendering. The change log states, “This is considered no
> more or less evil than the bytecode interpreter which we also enable.”
> Ubuntu, based on Debian, applies the patch as well. Fedora created the
> same patch in 2007, named freetype-2.3.0-enable-spr.patch, but does not
> apply the patch by default.
>
>• In 2017, FreeType 2.8.1 included a new subpixel rendering
> technique, called Harmony, that is nearly identical in output to the
> ClearType technique but uses a different algorithm, avoiding the
> patents. FreeType now uses Harmony subpixel rendering when the ClearType
> methods are disabled, with no need for clients to set the LCD filter.
> (This would have been a good time for Debian to remove its subpixel
> rendering patch.) The latest Fedora Workstation 28 runs FreeType 2.8.0,
> which does not include Harmony.
>
>• In 2019, the Microsoft ClearType patents expire.
>
> So now we have two variants of the FreeType library: one that requires a
> function call to set the LCD filter in Ubuntu and other distributions
> based on Debian, and another that doesn’t require the function call in
> Red Hat Enterprise Linux, Oracle Linux, and other distributions based on
> Fedora.
>
> To demonstrate the problem, I built four versions of the JDK from the
> latest OpenJDK sources. I built a version that uses the system FreeType
> library and another that uses the bundled FreeType library. Then I
> changed the OpenJDK code to set the default LCD filter and built the two
> versions again. The four builds were named:
>
>jdk-12-system-lcdnone
>jdk-12-system-lcddefault
>jdk-12-bundled-lcdnone
>jdk-12-bundled-lcddefault
>
> The system library is FreeType 2.8.1 in Ubuntu 18.04.1 LTS, which has
> the Debian patch applied (ClearType methods enabled), while the bundled
> library is FreeType 

Re: [OpenJDK 2D-Dev] RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound

[Krishna Addepalli]

Hi Kim,

An alternative way to fix it would be to declare the loop variable itself as 
unsigned, since the channels can never be negative, but that would require you 
to cast to int in two places.
Also, when casting, it is better to use static_cast, rather than C 
style casting.

Thanks,
Krishna

-Original Message-
From: Brian Burkhalter 
Sent: Wednesday, October 10, 2018 4:53 AM
To: Kim Barrett ; 2d-dev <2d-dev@openjdk.java.net>
Cc: Java Core Libs 
Subject: Re: [OpenJDK 2D-Dev] RFR: 8211962: Implicit narrowing in MacOSX 
java.desktop jsound

Looping in 2d-dev.

> On Oct 9, 2018, at 4:17 PM, Kim Barrett  wrote:
> 
> [I'm not sure whether core-libs is the right list for java.desktop 
> changes.]
> 
> Please review this trivial fix of a build failure on MacOSX when 
> compiling with C++11/14 enabled. An int value is being used in an 
> initializer where an unsigned int is needed, which is not permitted 
> since C++11.  The solution taken is to cast the value in the 
> initializer.  A "better" solution would be to change the type of the 
> value, but that has substantial fannout because there are many places 
> in our code where signed ints were used instead of the unsigned ints 
> used by the underlying MacOSX framework.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8211962
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8211962/open.00/
> 
> Testing:
> mach5 tier1 on MacOSX (really just verifying it builds).
> 
> 

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

[Laurent Bourgès]

Hi,

One last thing about Marlin renderer:
it is available since OpenJDK9 and you can tune its subpixels to let say
1x1 ie 1 pixel: -Dsun.java2d.renderer.subPixel_log2_X=0
-Dsun.java2d.renderer.subPixel_log2_Y=0

I ran again the 'slow' test on linux ~ 0.5s:
- 4x faster than Marlin AA defaults
- 6.5x faster than AWT C code (HiDPI)
- still 16x slower than accelerated pipeline (xrender)

OpenJDK Runtime Environment 18.9 (build 11+28)
JAVA_OPTS: -DuseAA=true -Dsun.java2d.uiScale=2.5
-Dsun.java2d.renderer.subPixel_log2_X=0
-Dsun.java2d.renderer.subPixel_log2_Y=0
Java: 11 11+28
oct. 11, 2018 2:36:12 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,747s
oct. 11, 2018 2:36:12 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,553s
oct. 11, 2018 2:36:13 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,559s
oct. 11, 2018 2:36:13 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,55s

Of course, you should enable antialiasing:

 @Override
 protected void paintComponent(Graphics g) {
 super.paintComponent(g);
 Graphics2D graphics = (Graphics2D) g;
+   if (USE_AA) {
+
graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
RenderingHints.VALUE_ANTIALIAS_ON);
+   }

PS: In OpenJFX, noAA rendering is using a specific Marlin renderer instance
(1x1 sampling) so it could be applied to Java2D noAA too.

Cheers,
Laurent

Le jeu. 11 oct. 2018 à 13:27, Peter Hull  a écrit :

> Hi Laurent,
> Thanks for the detailed explanation. I quickly checked on the older
> Windows system and the Java 11 window was the same size as the Java 8
> one, implying no scaling was going on (I guess just because it has a
> lower resolution monitor) - so that confirms your hypothesis.
>
> If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
> matter if the window is a bit small. However I believe some higher end
> systems have much higher scaling factors (2x, 3x?). Is there a general
> way to specify a 1px line regardless of scaling, because in my case I
> don't mind too much if it's a 'hair-line'?
>
> By the way, my actual application doesn't have 65000 lines but it
> draws 3 graphs with about 3000 points, which makes it noticeably slow
> when resizing the Window. I suppose I should look into cutting down
> the number of points somehow...
>
> Pete
>


-- 
-- 
Laurent Bourgès

Re: [OpenJDK 2D-Dev] Setting the FreeType LCD filter

[Laurent Bourgès]

Hi John & Phil,

I propose the following patch against jdk/client (openjdk12):
diff -r ac510fd737eb
src/java.desktop/share/native/libfontmanager/freetypeScaler.c
--- a/src/java.desktop/share/native/libfontmanager/freetypeScaler.c Thu
Oct 11 14:19:36 2018 +0530
+++ b/src/java.desktop/share/native/libfontmanager/freetypeScaler.c Thu
Oct 11 13:47:04 2018 +0200
@@ -38,6 +38,7 @@
 #include FT_SIZES_H
 #include FT_OUTLINE_H
 #include FT_SYNTHESIS_H
+#include FT_LCD_FILTER_H

 #include "fontscaler.h"

@@ -316,6 +317,8 @@
 free(scalerInfo);
 return 0;
 }
+/* enable LCD filter */
+FT_Library_SetLcdFilter(scalerInfo->library, FT_LCD_FILTER_DEFAULT);

 return ptr_to_jlong(scalerInfo);
 }

I tested it against OpenJDK11 and it fixed the problem of color fringes on
my ubuntu 18.4 (see screenshot):
http://cr.openjdk.java.net/~lbourges/png/freetype_lcd_filter_jdk11_vs_jdk12.png


Hope it helps,
Laurent

Le jeu. 11 oct. 2018 à 08:02, Laurent Bourgès  a
écrit :

> Hi john,
>
> I can sponsor you, preparing an official webrev in openjdk 12, as phil
> asked for.
>
> Laurent
>
> Le lun. 8 oct. 2018 à 22:24, John Neffenger  a écrit :
>
>> Now that we fixed a font problem in JavaFX [1], let's fix the same
>> problem in Java. I would like your feedback on the Request for
>> Enhancement described below:
>>
>> OpenJDK FreeType Font Fix
>> https://github.com/jgneff/openjdk-freetype
>>
>> Thank you,
>> John
>>
>> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>>
>

-- 
-- 
Laurent Bourgès

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

[Peter Hull]

Hi Laurent,
Thanks for the detailed explanation. I quickly checked on the older
Windows system and the Java 11 window was the same size as the Java 8
one, implying no scaling was going on (I guess just because it has a
lower resolution monitor) - so that confirms your hypothesis.

If I use -Dsun.java2d.uiScale=1.0 that's OK for my laptop, it doesn't
matter if the window is a bit small. However I believe some higher end
systems have much higher scaling factors (2x, 3x?). Is there a general
way to specify a 1px line regardless of scaling, because in my case I
don't mind too much if it's a 'hair-line'?

By the way, my actual application doesn't have 65000 lines but it
draws 3 graphs with about 3000 points, which makes it noticeably slow
when resizing the Window. I suppose I should look into cutting down
the number of points somehow...

Pete

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

[Laurent Bourgès]

Hi Peter,

I confirm that HiDPI support is causing your problem.

On linux (xrender), I added -Dsun.java2d.uiScale=2.5 and the performance
becomes poor ~ 3.3s vs 0.03s !

java -Dsun.java2d.uiScale=2.5 -DuseAA=false -jar dist/PolylineTest.jar
Java: 11 11+28
oct. 11, 2018 1:02:00 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 3,781s
oct. 11, 2018 1:02:03 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 3,003s
oct. 11, 2018 1:02:06 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 3,318s*

java -jar dist/PolylineTest.jar
Java: 11 11+28
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,073s
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 0,037s
oct. 11, 2018 12:50:33 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 0,029s*


I enabled antialiasing hint to use Marlin renderer and performance is
slightly better ~1.9s vs 3.3s.
Java: 11 11+28
oct. 11, 2018 1:01:27 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 2,304s
oct. 11, 2018 1:01:29 PM polylinetest.Canvas paintComponent
INFO: Paint Time: 1,911s
oct. 11, 2018 1:01:31 PM polylinetest.Canvas paintComponent
*INFO: Paint Time: 1,881s*

Moreover, your polyline is very complicated (65K segments) so AWT (c code)
may have troubles in contrary to the Marlin renderer (pure java - AA
optimized code), that is faster and performs AA computations (8 times more
sampling).

I performed quick profiling using linux perf:
perf record -g java -Dsun.java2d.uiScale=2.5 -jar dist/PolylineTest.jar

Samples: 58K of event 'cycles:ppp', Event count (approx.): 48668354960,
DSO: libawt.so
  Children  Self  Command
Symbol  ◆


*+   74,35% 0,00%  AWT-EventQueue-  [.]
Java_sun_java2d_pipe_ShapeSpanIterator_nextSpan ▒+
74,35%74,10%  AWT-EventQueue-  [.]
ShapeSINextSpan ▒+
10,00% 0,05%  AWT-EventQueue-  [.]
Java_sun_java2d_pipe_ShapeSpanIterator_lineTo   ▒*
 0,22% 0,22%  AWT-EventQueue-  [.]
sortSegmentsByLeadingY  ▒
 0,14% 0,14%  AWT-EventQueue-  [.]
appendSegment   ▒
 0,08% 0,00%  java [.]
Java_sun_java2d_loops_GraphicsPrimitiveMgr_initIDs  ▒
 0,04% 0,04%  AWT-EventQueue-  [.]
subdivideLine.isra.0▒
 0,03% 0,00%  java [.]
AWT_OnLoad  ▒
 0,03% 0,00%  java [.]
AWTIsHeadless   ▒
 0,02% 0,02%  AWT-EventQueue-  [.]
GetSpanData ▒
 0,02% 0,00%  java [.]
Java_sun_java2d_SurfaceData_initIDs ▒
 0,01% 0,00%  AWT-EventQueue-  [.]
initSegmentTable▒
 0,01% 0,00%  java [.]
Java_sun_java2d_loops_GraphicsPrimitiveMgr_registerNativeLoops  ▒
 0,01% 0,01%  AWT-EventQueue-  [.] free@plt
▒
 0,00% 0,00%  java [.]
RegisterPrimitives  ▒
 0,00% 0,00%  Java2D Disposer  [.]
SurfaceData_DisposeOps  ▒
 0,00% 0,00%  AWT-EventQueue-  [.] memcpy@plt
▒
 0,00% 0,00%  AWT-EventQueue-  [.] calloc@plt
▒
 0,00% 0,00%  java [.]
InitSimpleTypes.constprop.0 ▒
 0,00% 0,00%  java [.]
MapAccelFunction▒
 0,00% 0,00%  java [.]
Java_sun_java2d_pipe_SpanClipRenderer_initIDs   ▒

I suspect that HiDPI implies software rendering instead of accelerated
rendering (xrender drawline, AFAIR).

However, I am not sure such performance issue can be fixed any time soon.
Workaround: use -Dsun.java2d.uiScale=1.0

Regards,
Laurent

Le jeu. 11 oct. 2018 à 10:30, Peter Hull  a écrit :

> I can answer part of that, but I can't get access to the older system just
> now.
>
> On Wed, Oct 10, 2018 at 4:41 PM Philip Race 
> wrote:
> > In other words does
> >
> > -Dsun.java2d.uiScale=1.0
> >
> > even change the physical size of the window on JDK 9/10/11 ?
> >
> Yes, because I can run the same jar under Java 8 and 11. Without the
> scale option, the Java 11 window is bigger than the Java 8 one, by
> about 1.25x (this corresponds to my system setting)
> When I add the scale=1 option to both, they are both the same size
> (and the same as JDK8 without any scaling)
> I've attached 2 images so you can see what I mean, one is without any
> scale option (and I labelled the approx size on this) and the other is
> with -Dsun.java2d.uiScale=1.0.
> The 

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

[Bill York]

Thanks Phil,

All the 61 reports I mentioned below have the same stack. In the same 30 days 
we also received:


  *   120 reports about https://bugs.openjdk.java.net/browse/JDK-8146329 or 
https://bugs.openjdk.java.net/browse/JDK-8133783
 *   I can’t tell the difference between those two bug reports
 *   Note this is fixed in the JetBrains OpenJDK here: 
https://bintray.com/jetbrains/intellij-jdk/download_file?file_path=jbsdk8u152b1136.5_osx_x64.tar.gz

Bill

From: Phil Race 
Date: Wednesday, October 10, 2018 at 4:34 PM
To: Bill York 
Cc: "2d-dev@openjdk.java.net" <2d-dev@openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

Hi,

I expect it would be a good & safe thing to do, to check for NULL.
But I don't know if all of these reports you have are down to that.
Did you get stack traces for all of them ?
We also have open bugs like
https://bugs.openjdk.java.net/browse/JDK-8146329
https://bugs.openjdk.java.net/browse/JDK-8133783
which look different.

-phil.
On 10/10/2018 10:56 AM, Bill York wrote:
Thanks for the response Phil, here’s what I know.

Reports show:

  *   Mac OS – many versions 10.10 through 17.7
  *   Java - 8 u144-b01 (48 reports), 8 u152-b16 (12 reports) 8 
u152-release-1136-b5 – JetBrains (1 report)

Comments say:

  *   Screen change event.  I am using the jetbrains JRE, as you can see in the 
stack trace.
  *   I am on a mac and product crashes very often when I put my computer to 
sleep.
  *   Woke up computer after connecting to two external monitors.

I’ve annotated the function names with links to code I found on the OpenJDK 
site and the Apple site.

As an experiment, I created a simple X-Code project to examine how 
CFSTringCompare behaves when passed NULL. It does throw an EXC_BAD_ACCESS as is 
shown in the below stack trace. My example code is at the end of this message.

Stack trace shows:

[  7] 0x601c5848   
+
[  8] 0x7fff3cc4e678 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation+00140920
 
CFStringCompare+0024
[  9] 0x0001351a80f7 java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119031 
getBPPFromModeString+0032
 (see line 32)
[ 10] 0x0001351a819f java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119199 
createJavaDisplayMode+0053
 (see line 130)
[ 11] 0x0001351a841e java/jre/maci64/jre/lib/libawt_lwawt.dylib+00119838 
Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode+0031
 (see line 267)

Example code:


#import 



static int getBPPFromModeString(CFStringRef mode)

{

if ((CFStringCompare(mode, CFSTR(kIO30BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo)) {

// This is a strange mode, where we using 10 bits per RGB component and 
pack it into 32 bits

// Java is not ready to work with this mode but we have to specify it 
as supported

return 30;

}

else if (CFStringCompare(mode, CFSTR(IO32BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

return 32;

}

else if (CFStringCompare(mode, CFSTR(IO16BitDirectPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

return 16;

}

else if (CFStringCompare(mode, CFSTR(IO8BitIndexedPixels), 
kCFCompareCaseInsensitive) == kCFCompareEqualTo) {

return 8;

}



return 0;

}



int main(int argc, const char * argv[]) {

@autoreleasepool {

// insert code here...

CFStringRef mode;

getBPPFromModeString(mode);

NSLog(@"Hello, World!");

}

return 0;

}


From: Philip Race 
Organization: Oracle Corporation
Date: Wednesday, October 10, 2018 at 12:03 PM
To: Bill York 
Cc: "2d-dev@openjdk.java.net" 
<2d-dev@openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] Crash in CGraphicsDevice.m

The code you suspect has nothing to do with the webrev you list.
It was introduced in fixing 
https://bugs.openjdk.java.net/browse/JDK-7124247
So has been there since JDK 8 GA. Not recent .. perhaps you can tell us
more about your users JDK versions and what is the earliest that reproduces 
this crash ?

-phil.

On 10/10/18, 8:45 AM, 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

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

[Peter Hull]

I can answer part of that, but I can't get access to the older system just now.

On Wed, Oct 10, 2018 at 4:41 PM Philip Race  wrote:
> In other words does
>
> -Dsun.java2d.uiScale=1.0
>
> even change the physical size of the window on JDK 9/10/11 ?
>
Yes, because I can run the same jar under Java 8 and 11. Without the
scale option, the Java 11 window is bigger than the Java 8 one, by
about 1.25x (this corresponds to my system setting)
When I add the scale=1 option to both, they are both the same size
(and the same as JDK8 without any scaling)
I've attached 2 images so you can see what I mean, one is without any
scale option (and I labelled the approx size on this) and the other is
with -Dsun.java2d.uiScale=1.0.
The window title contains the system property "java.runtime.version"
so you can see which is which.

I do appreciate your help on this. It looks like it's coming down to
Intel's graphics driver, do you agree?

Pete

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

[Prasanta Sadhukhan]

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] Setting the FreeType LCD filter

[Laurent Bourgès]

Hi john,

I can sponsor you, preparing an official webrev in openjdk 12, as phil
asked for.

Laurent

Le lun. 8 oct. 2018 à 22:24, John Neffenger  a écrit :

> Now that we fixed a font problem in JavaFX [1], let's fix the same
> problem in Java. I would like your feedback on the Request for
> Enhancement described below:
>
> OpenJDK FreeType Font Fix
> https://github.com/jgneff/openjdk-freetype
>
> Thank you,
> John
>
> [1] https://github.com/javafxports/openjdk-jfx/issues/229
>