Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v12]
On Wed, 10 Mar 2021 10:51:08 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal API. >> The entire work on this was done under [OpenJDK Project - >> Lanai](http://openjdk.java.net/projects/lanai/) >> >> We iterated through several Early Access (EA) builds and have reached a >> stage where it is ready to be integrated to openjdk/jdk. The latest EA build >> is available at - https://jdk.java.net/lanai/ >> >> A new option -Dsun.java2d.metal=true | True needs to be used to use this >> pipeline. >> >> **Testing :** >> This implementation has been tested with the tests present at - [Test Plan >> for JEP 382: New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) >> >> **Note to reviewers :** >> 1) Default rendering pipeline on macOS has not been changed by this PR. >> OpenGL still stays as the default rendering pipeline and Metal rendering >> pipeline is optional to choose. >> >> 2) To apply and test this PR - >> To enable the metal pipeline you must specify on command line >> -Dsun.java2d.metal=true (No message will be printed in this case) or >> -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is >> enabled gets printed) >> >> 3) Review comments (including some preliminary informal review comments) are >> tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598 > > Ajit Ghaisas has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 45 additional > commits since the last revision: > > - Lanai PR#213 - 8263325 - avu > - Lanai PR#212 - 8259825 - aghaisas > - Lanai PR#211 - 8262882 - aghaisas > - Merge branch 'master' into 8260931_lanai_JEP_branch > - Lanai PR#210 - 8263159 - jdv > - Lanai PR#209 - 8262936 - jdv > - Lanai PR#208 - 8262928 - jdv > - Lanai PR#207 - 8262750 - jdv > - Merge branch 'master' into 8260931_lanai_JEP_branch > - Lanai PR#206 - 8262729 - aghaisas > - ... and 35 more: > https://git.openjdk.java.net/jdk/compare/59142f88...3980ecbd Marked as reviewed by avu (no project role). - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify
On Thu, 11 Mar 2021 04:24:26 GMT, Prasanta Sadhukhan wrote: >> Nothing throws an exception or otherwise prevent this being negative but >> that would be a weird usage. Typically the weight is either zero or based on >> the font size .. which ought not to be negative but I don't think anything >> prevents it and I think we would treat it essentially as a transform. So If >> you really want to be careful here, then yes assume weight could be negative. > > By that same logic, then shouldn't absorbweight also be checked as != 0 > instead of > 0 as that also uses += gi.weight Hi, I am not sure about the absorbweight check; but currently the calculated value weightedAbsorb is only used when absorbing is true. And there the > 0 check is present too boolean absorbing = hitLimit && absorbweight > 0; - PR: https://git.openjdk.java.net/jdk/pull/2912
Re: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify
On Wed, 10 Mar 2021 18:48:50 GMT, Phil Race wrote: >> Hi, I am not sure about the weight > 0 check ; weight is initialized with >> 0: weight = 0; and later some values are potentially added up to weight: >> weight += gi.weight; >> I am not sure about those gi.weight values, maybe they can be negative too ? > > Nothing throws an exception or otherwise prevent this being negative but that > would be a weird usage. Typically the weight is either zero or based on the > font size .. which ought not to be negative but I don't think anything > prevents it and I think we would treat it essentially as a transform. So If > you really want to be careful here, then yes assume weight could be negative. By that same logic, then shouldn't absorbweight also be checked as != 0 instead of > 0 as that also uses += gi.weight - PR: https://git.openjdk.java.net/jdk/pull/2912
Re: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe
On Sat, 27 Feb 2021 18:33:52 GMT, Andrey Turbanov wrote: > 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not > thread safe Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2762
Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons
On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev wrote:
> Fix updated after first round of review.
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1044:
> 1042: new BufferedImage(iconSize, iconSize,
> BufferedImage.TYPE_INT_ARGB);
> 1043: img.setRGB(0, 0, iconSize, iconSize, iconBits, 0,
> iconSize);
> 1044: return img;
There are cases where the size of the buffered image is different from the
requested size. It could affect the layout because it breaks the assumption
that the returned image has the requested size but it may be larger. (Or is it
no longer possible?) I think it should be wrapped into
`MultiResolutionIconImage` in this case.
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1114:
> 1112: bothIcons.put(getLargeIcon?
> SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);
> 1113: newIcon = new
> MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE
> 1114: : SMALL_ICON_SIZE,
> bothIcons);
I still propose to refactor this code to make it clearer. The code always
returns two icons: _small + large_ or _large + small_ — combined in
`MultiResolutionIconImage`.
You can get `smallIcon` and `largeIcon` and then wrap them into
`MultiResolutionIconImage` in the correct order and store each icon in the
cache.
My opinion hasn't changed here.
I still think there's not much value in getting smaller icon size in addition
to larger one. Or does it provide an alternative image for the case where the
system scaling is 200% and the window is moved to a monitor with scaling of
100%?
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1195:
> 1193: */
> 1194: static Image getShell32Icon(int iconID, int size) {
> 1195: boolean useVGAColors = true; // Will be ignored on XP and later
I cannot see where `useVGAColors` is used. Since the supported OS are later
than XP, it can be removed, can't it?
src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 983:
> 981: size = 16;
> 982: }
> 983: hres = pIcon->Extract(szBuf, index, , NULL, (16 << 16)
> + size);
Suggestion:
hres = pIcon->Extract(szBuf, index, , NULL, size);
Now you request only one icon.
test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 64:
> 62: }
> 63:
> 64: if (icon.getIconWidth() != size) {
Does it make sense to check that the icon is a multi-resolution image with the
expected sizes?
We know for sure `explorer.exe` contains the entire set of icons.
src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line
264:
> 262: *
> 263: * The default implementation gets information from the
> 264: * ShellFolder class. Whenever possible, the icon
Do we continue using `` elements? I thought that {@code} is the preferred
way to markup class names.
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1112:
> 1110: Map bothIcons = new
> HashMap<>(2);
> : bothIcons.put(getLargeIcon?
> LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
> 1112: bothIcons.put(getLargeIcon?
> SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);
Suggestion:
bothIcons.put(getLargeIcon ?
LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
bothIcons.put(getLargeIcon ?
SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1146:
> 1144: }
> 1145: Map multiResolutionIcon = new HashMap<>();
> 1146: int start = size > MAX_QUALITY_ICON ?
> ICON_RESOLUTIONS.length - 1 : 0;
Does it make sense to always start at zero?
The icons of smaller size will never be used, will they?
Thus it's safe to start at the index which corresponds to the requested size if
`size` matches, or the index such as `ICON_RESOLUTIONS[index] < size &&
ICON_RESOLUTIONS[index + 1] > size`.
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1149:
> 1147: int increment = size > MAX_QUALITY_ICON ? -1 : 1;
> 1148: int end = size > MAX_QUALITY_ICON ? -1 :
> ICON_RESOLUTIONS.length;
> 1149: for (int i = start; i != end; i+=increment) {
Suggestion:
for (int i = start; i != end; i += increment) {
src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1422:
> 1420: int w = (int) width;
> 1421: int retindex = 0;
> 1422: for (Integer i: resolutionVariants.keySet()) {
Suggestion:
for (Integer i : resolutionVariants.keySet()) {
-
PR:
Re: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify
On Wed, 10 Mar 2021 12:55:34 GMT, Matthias Baesken wrote:
>> src/java.desktop/share/classes/java/awt/font/TextJustifier.java line 159:
>>
>>> 157: // predivide delta by weight
>>> 158: float weightedDelta = 0;
>>> 159: if (weight != 0) { // not used if weight == 0
>>
>> Can it ever be -ve? Maybe we can do weight > 0 check just as we do for
>> absorbweight?
>
> Hi, I am not sure about the weight > 0 check ; weight is initialized with
> 0: weight = 0; and later some values are potentially added up to weight:
> weight += gi.weight;
> I am not sure about those gi.weight values, maybe they can be negative too ?
Nothing throws an exception or otherwise prevent this being negative but that
would be a weird usage. Typically the weight is either zero or based on the
font size .. which ought not to be negative but I don't think anything prevents
it and I think we would treat it essentially as a transform. So If you really
want to be careful here, then yes assume weight could be negative.
-
PR: https://git.openjdk.java.net/jdk/pull/2912
[OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for remote printers update instead of polling
[JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers. That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates. It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services. It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry. I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`. - Commit messages: - 8263311: Watch registry changes for remote printers update instead of polling Changes: https://git.openjdk.java.net/jdk/pull/2915/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2915=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263311 Stats: 207 lines in 3 files changed: 31 ins; 158 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/2915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2915/head:pull/2915 PR: https://git.openjdk.java.net/jdk/pull/2915
Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v12]
On Wed, 10 Mar 2021 10:51:08 GMT, Ajit Ghaisas wrote: >> **Description :** >> This is the implementation of [JEP 382 : New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) >> It implements a Java 2D internal rendering pipeline for macOS using the >> Apple Metal API. >> The entire work on this was done under [OpenJDK Project - >> Lanai](http://openjdk.java.net/projects/lanai/) >> >> We iterated through several Early Access (EA) builds and have reached a >> stage where it is ready to be integrated to openjdk/jdk. The latest EA build >> is available at - https://jdk.java.net/lanai/ >> >> A new option -Dsun.java2d.metal=true | True needs to be used to use this >> pipeline. >> >> **Testing :** >> This implementation has been tested with the tests present at - [Test Plan >> for JEP 382: New macOS Rendering >> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) >> >> **Note to reviewers :** >> 1) Default rendering pipeline on macOS has not been changed by this PR. >> OpenGL still stays as the default rendering pipeline and Metal rendering >> pipeline is optional to choose. >> >> 2) To apply and test this PR - >> To enable the metal pipeline you must specify on command line >> -Dsun.java2d.metal=true (No message will be printed in this case) or >> -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is >> enabled gets printed) >> >> 3) Review comments (including some preliminary informal review comments) are >> tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598 > > Ajit Ghaisas has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 45 additional > commits since the last revision: > > - Lanai PR#213 - 8263325 - avu > - Lanai PR#212 - 8259825 - aghaisas > - Lanai PR#211 - 8262882 - aghaisas > - Merge branch 'master' into 8260931_lanai_JEP_branch > - Lanai PR#210 - 8263159 - jdv > - Lanai PR#209 - 8262936 - jdv > - Lanai PR#208 - 8262928 - jdv > - Lanai PR#207 - 8262750 - jdv > - Merge branch 'master' into 8260931_lanai_JEP_branch > - Lanai PR#206 - 8262729 - aghaisas > - ... and 35 more: > https://git.openjdk.java.net/jdk/compare/42b2f14b...3980ecbd Marked as reviewed by kcr (Author). - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify
On Wed, 10 Mar 2021 12:41:05 GMT, Prasanta Sadhukhan
wrote:
>> In java/awt/font/TextJustifier.java justify-method there is a potential code
>> path where divison by zero might happen , see also the Sonar finding
>> https://sonarcloud.io/project/issues?id=shipilev_jdk=AXcqMwpm8sPJZZzONu1k=false=CRITICAL=BUG
>>
>>
>> boolean hitLimit = (weight == 0) || (!lastPass && ((delta < 0)
>> == (delta < gslimit)));
>> boolean absorbing = hitLimit && absorbweight > 0;
>> // predivide delta by weight
>> float weightedDelta = delta / weight; // not used if weight == 0
>>
>> In case of (weight == 0) the division should not be done because the value
>> of weightedDelta is unused in this case anyway.
>
> src/java.desktop/share/classes/java/awt/font/TextJustifier.java line 159:
>
>> 157: // predivide delta by weight
>> 158: float weightedDelta = 0;
>> 159: if (weight != 0) { // not used if weight == 0
>
> Can it ever be -ve? Maybe we can do weight > 0 check just as we do for
> absorbweight?
Hi, I am not sure about the weight > 0 check ; weight is initialized with 0:
weight = 0; and later some values are potentially added up to weight:
weight += gi.weight;
I am not sure about those gi.weight values, maybe they can be negative too ?
-
PR: https://git.openjdk.java.net/jdk/pull/2912
Re: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify
On Wed, 10 Mar 2021 12:31:31 GMT, Matthias Baesken wrote:
> In java/awt/font/TextJustifier.java justify-method there is a potential code
> path where divison by zero might happen , see also the Sonar finding
> https://sonarcloud.io/project/issues?id=shipilev_jdk=AXcqMwpm8sPJZZzONu1k=false=CRITICAL=BUG
>
>
> boolean hitLimit = (weight == 0) || (!lastPass && ((delta < 0) ==
> (delta < gslimit)));
> boolean absorbing = hitLimit && absorbweight > 0;
> // predivide delta by weight
> float weightedDelta = delta / weight; // not used if weight == 0
>
> In case of (weight == 0) the division should not be done because the value of
> weightedDelta is unused in this case anyway.
src/java.desktop/share/classes/java/awt/font/TextJustifier.java line 159:
> 157: // predivide delta by weight
> 158: float weightedDelta = 0;
> 159: if (weight != 0) { // not used if weight == 0
Can it ever be -ve? Maybe we can do weight > 0 check just as we do for
absorbweight?
-
PR: https://git.openjdk.java.net/jdk/pull/2912
[OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in java/awt/font/TextJustifier.java justify
In java/awt/font/TextJustifier.java justify-method there is a potential code path where divison by zero might happen , see also the Sonar finding https://sonarcloud.io/project/issues?id=shipilev_jdk=AXcqMwpm8sPJZZzONu1k=false=CRITICAL=BUG boolean hitLimit = (weight == 0) || (!lastPass && ((delta < 0) == (delta < gslimit))); boolean absorbing = hitLimit && absorbweight > 0; // predivide delta by weight float weightedDelta = delta / weight; // not used if weight == 0 In case of (weight == 0) the division should not be done because the value of weightedDelta is unused in this case anyway. - Commit messages: - JDK-8263362 Changes: https://git.openjdk.java.net/jdk/pull/2912/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2912=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263362 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2912.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2912/head:pull/2912 PR: https://git.openjdk.java.net/jdk/pull/2912
Re: [OpenJDK 2D-Dev] Rendering images from PDF files slower in OpenJDK
Hi Sergey, Le lun. 8 mars 2021 à 06:00, Sergey Bylokhov a écrit : > Hi, Laurent. > > On 04.10.2018 23:45, Laurent Bourgès wrote: > > I looks like a call to let me have a look. Maybe I could inspect what > makes LCMS slow (lerp?) ... and optimize the C code or at least tune gcc > options. > > Did you have a chance to look at it? =) > No, I agreed with phil, it is more a LCMS optimization task, for anybody involved in this project. I could have a look since, but no time nor motivation, sorry. This ticket is closeable or stalled until someone rewrites LCMS to be more efficient. Cheers, Laurent
Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v11]
On Tue, 9 Mar 2021 20:18:08 GMT, Sergey Bylokhov wrote: >> Ajit Ghaisas has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 41 additional >> commits since the last revision: >> >> - Lanai PR#210 - 8263159 - jdv >> - Lanai PR#209 - 8262936 - jdv >> - Lanai PR#208 - 8262928 - jdv >> - Lanai PR#207 - 8262750 - jdv >> - Merge branch 'master' into 8260931_lanai_JEP_branch >> - Lanai PR#206 - 8262729 - aghaisas >> - Lanai PR#205 - 8262496 - avu >> - Lanai PR#203 - 8262313 - jdv >> - Lanai PR#202 - 8262293 - avu >> - Lanai PR#201 - 8261891 - avu >> - ... and 31 more: >> https://git.openjdk.java.net/jdk/compare/d65116dd...de456939 > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m > line 185: > >> 183: >> 184: NSRect contentRect = NSMakeRect(0, 0, 64, 64); >> 185: NSWindow *window = > > Some remnant from the scratch surface initialization? This will be removed under - JDK-8263363 - PR: https://git.openjdk.java.net/jdk/pull/2403
Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v10]
On Sun, 7 Mar 2021 22:40:53 GMT, Sergey Bylokhov wrote:
>> Ajit Ghaisas has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 36 additional
>> commits since the last revision:
>>
>> - Lanai PR#206 - 8262729 - aghaisas
>> - Lanai PR#205 - 8262496 - avu
>> - Lanai PR#203 - 8262313 - jdv
>> - Lanai PR#202 - 8262293 - avu
>> - Lanai PR#201 - 8261891 - avu
>> - Lanai PR#200 - 8262115 - aghaisas
>> - Merge branch 'master' into 8260931_lanai_JEP_branch
>> - Lanai PR#199 - 8262091 - aghaisas
>> - Lanai PR#198 - 8261646 - avu
>> - Lanai PR#197 - 8261960 - jdv
>> - ... and 26 more:
>> https://git.openjdk.java.net/jdk/compare/33534417...5cb1fd91
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CWarningWindow.java line 304:
>
>> 302: };
>> 303: }
>> 304: public MTLLayer createMTLLayer() {
>
> TODO to test that this functionality works
Testing was done under JDK-8261141.
-
PR: https://git.openjdk.java.net/jdk/pull/2403
Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v12]
> **Description :** > This is the implementation of [JEP 382 : New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361) > It implements a Java 2D internal rendering pipeline for macOS using the Apple > Metal API. > The entire work on this was done under [OpenJDK Project - > Lanai](http://openjdk.java.net/projects/lanai/) > > We iterated through several Early Access (EA) builds and have reached a stage > where it is ready to be integrated to openjdk/jdk. The latest EA build is > available at - https://jdk.java.net/lanai/ > > A new option -Dsun.java2d.metal=true | True needs to be used to use this > pipeline. > > **Testing :** > This implementation has been tested with the tests present at - [Test Plan > for JEP 382: New macOS Rendering > Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396) > > **Note to reviewers :** > 1) Default rendering pipeline on macOS has not been changed by this PR. > OpenGL still stays as the default rendering pipeline and Metal rendering > pipeline is optional to choose. > > 2) To apply and test this PR - > To enable the metal pipeline you must specify on command line > -Dsun.java2d.metal=true (No message will be printed in this case) or > -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is > enabled gets printed) > > 3) Review comments (including some preliminary informal review comments) are > tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598 Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 45 additional commits since the last revision: - Lanai PR#213 - 8263325 - avu - Lanai PR#212 - 8259825 - aghaisas - Lanai PR#211 - 8262882 - aghaisas - Merge branch 'master' into 8260931_lanai_JEP_branch - Lanai PR#210 - 8263159 - jdv - Lanai PR#209 - 8262936 - jdv - Lanai PR#208 - 8262928 - jdv - Lanai PR#207 - 8262750 - jdv - Merge branch 'master' into 8260931_lanai_JEP_branch - Lanai PR#206 - 8262729 - aghaisas - ... and 35 more: https://git.openjdk.java.net/jdk/compare/dfe037de...3980ecbd - Changes: - all: https://git.openjdk.java.net/jdk/pull/2403/files - new: https://git.openjdk.java.net/jdk/pull/2403/files/de456939..3980ecbd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2403=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2403=10-11 Stats: 4881 lines in 177 files changed: 1767 ins; 2327 del; 787 mod Patch: https://git.openjdk.java.net/jdk/pull/2403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403 PR: https://git.openjdk.java.net/jdk/pull/2403
Re: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows
On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy wrote: > Printing text using GlyphVector outline has bad quality on printers with low > DPI on Windows. > The GDI system used for text printing on Windows accepts only integer path > coordinates. > Rounding GlyphVector outline coordinates leads to distorted printed text. > > The issue had been reported as JDK-8256264 but was reverted because of the > regression JDK-8259007 "This test printed a blank page". > > The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo() > methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down. > > The regression was in the WPathGraphics.deviceDrawLine() method which uses > wPrinterJob.moveTo()/lineTo() methods without surrounding them with > wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up. > > I tried to put wPrinterJob.beginPath()/endPath() methods around > wPrinterJob.moveTo()/lineTo() in the method WPathGraphics.deviceDrawLine() > but the line was not drawn at all even without scaling coordinates up and > transform down (without JDK-8256264 fix). It looks like GDI treats this case > as an empty shape. > > The proposed fix applies path coordinates and transform scaling only in > WPathGraphics.convertToWPath() method. > The one more PathPrecisionScaleFactorShapeTest.java manual test is added > which checks that all methods that draw paths in WPathGraphics are used: line > in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in > WPathGraphics.convertToWPath() . > > The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were > run on Windows 10 Pro with the fix. > > There are two failed automated tests which fail without the fix as well: > java/awt/print/PrinterJob/GlyphPositions.java > java/awt/print/PrinterJob/PSQuestionMark.java > > The following manual tests have issues on my system: > - `java/awt/print/Dialog/PrintDlgPageable.java` > java.lang.IllegalAccessException: class > com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member > of class PrintDlgPageable with modifiers "public static" > > - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages > radio button, press the print button but the test does not finish and I do > not see any other dialogs with pass/fail buttons. > > - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests > that there is no ClassCastException thrown in printing checkbox and scrollbar > with XAWT. Error. Can't find HTML file: > test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html > > > - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with > instructions is shown but it does not contain print/pass/fail buttons and it > is not possible to close the window. > > - The tests below fail with "Error. Parse Exception: Arguments to `manual' > option not supported: yesno" message: > java/awt/print/Dialog/DialogOrient.java > java/awt/print/Dialog/DialogType.java > java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java > java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java > java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java > java/awt/print/PrinterJob/PageDialogTest.java > java/awt/print/PrinterJob/PageRanges.java > java/awt/print/PrinterJob/PageRangesDlgTest.java > java/awt/print/PrinterJob/PrintGlyphVectorTest.java > java/awt/print/PrinterJob/PrintLatinCJKTest.java > java/awt/print/PrinterJob/PrintTextTest.java > java/awt/print/PrinterJob/SwingUIText.java > java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java > java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java > java/awt/PrintJob/SaveDialogTitleTest.java src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 2033: > 2031: xForm.eDy = (FLOAT) elems[5]; > 2032: > 2033: ::SetWorldTransform((HDC)printDC, ); Probably we should check for the return value of all this system APIs SetGraphicsMode, GetWorldTransform, SetWorldTransform, ModifyWorldTransform to see if it succeeded? - PR: https://git.openjdk.java.net/jdk/pull/2756
Re: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows
On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy
wrote:
> Printing text using GlyphVector outline has bad quality on printers with low
> DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path
> coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
>
> The issue had been reported as JDK-8256264 but was reverted because of the
> regression JDK-8259007 "This test printed a blank page".
>
> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()
> methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
>
> The regression was in the WPathGraphics.deviceDrawLine() method which uses
> wPrinterJob.moveTo()/lineTo() methods without surrounding them with
> wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
>
> I tried to put wPrinterJob.beginPath()/endPath() methods around
> wPrinterJob.moveTo()/lineTo() in the method WPathGraphics.deviceDrawLine()
> but the line was not drawn at all even without scaling coordinates up and
> transform down (without JDK-8256264 fix). It looks like GDI treats this case
> as an empty shape.
>
> The proposed fix applies path coordinates and transform scaling only in
> WPathGraphics.convertToWPath() method.
> The one more PathPrecisionScaleFactorShapeTest.java manual test is added
> which checks that all methods that draw paths in WPathGraphics are used: line
> in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in
> WPathGraphics.convertToWPath() .
>
> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were
> run on Windows 10 Pro with the fix.
>
> There are two failed automated tests which fail without the fix as well:
> java/awt/print/PrinterJob/GlyphPositions.java
> java/awt/print/PrinterJob/PSQuestionMark.java
>
> The following manual tests have issues on my system:
> - `java/awt/print/Dialog/PrintDlgPageable.java`
> java.lang.IllegalAccessException: class
> com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member
> of class PrintDlgPageable with modifiers "public static"
>
> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages
> radio button, press the print button but the test does not finish and I do
> not see any other dialogs with pass/fail buttons.
>
> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests
> that there is no ClassCastException thrown in printing checkbox and scrollbar
> with XAWT. Error. Can't find HTML file:
> test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
>
>
> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with
> instructions is shown but it does not contain print/pass/fail buttons and it
> is not possible to close the window.
>
> - The tests below fail with "Error. Parse Exception: Arguments to `manual'
> option not supported: yesno" message:
> java/awt/print/Dialog/DialogOrient.java
> java/awt/print/Dialog/DialogType.java
> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
> java/awt/print/PrinterJob/PageDialogTest.java
> java/awt/print/PrinterJob/PageRanges.java
> java/awt/print/PrinterJob/PageRangesDlgTest.java
> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
> java/awt/print/PrinterJob/PrintLatinCJKTest.java
> java/awt/print/PrinterJob/PrintTextTest.java
> java/awt/print/PrinterJob/SwingUIText.java
> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
> java/awt/PrintJob/SaveDialogTitleTest.java
src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1025:
> 1023: * {@code GM_COMPATIBLE} or {@code GM_ADVANCED}.
> 1024: */
> 1025: private int setGraphicsMode(int mode) {
Is there any need of "int" return value? I dont see it is used in
restoreTransform()
-
PR: https://git.openjdk.java.net/jdk/pull/2756
Re: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe
On Sat, 27 Feb 2021 18:33:52 GMT, Andrey Turbanov wrote: > 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not > thread safe Marked as reviewed by kizune (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2762
