Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-21 Thread Sergey Bylokhov
On Fri, 21 May 2021 01:11:38 GMT, Sergey Bylokhov  wrote:

>>> But this is shared code, which has a specification it should work 
>>> everywhere, so even if on Linux and macOS it is not implemented in the best 
>>> way it should return something.
>> 
>> The stuff that is returned by the common code is already tested in UIManager 
>> tests. This issue is windows specific. This implementation at this moment of 
>> time is windows specific. Once we extend implementation - and i mean real 
>> implementation with support for multiple resolution icons - this test will 
>> be updated to reflect it. This is not a specification conformance test, it 
>> is implementation logic test.
>
> How it could be tested by the UIManager tests since this is a new method 
> added in this class? I guess it should work just out of the box, no? What is 
> the reason to not enable it, there are some issues?

I suggest running it now and do not wait while the new tck tests will be 
created and run, so we will not get a tck-red right before release.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 22:38:48 GMT, Sergey Bylokhov  wrote:

> But this is shared code, which has a specification it should work everywhere, 
> so even if on Linux and macOS it is not implemented in the best way it should 
> return something.

The stuff that is returned by the common code is already tested in UIManager 
tests. This issue is windows specific. This implementation at this moment of 
time is windows specific. Once we extend implementation - and i mean real 
implementation with support for multiple resolution icons - this test will be 
updated to reflect it. This is not a specification conformance test, it is 
implementation logic test.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 22:37:08 GMT, Sergey Bylokhov  wrote:

> I did not get how you will be able to force use MRI later since this method 
> is implemented as a return icon. So this choice should be made before 
> integration.

I am not going to force MRI usage - i am assuming that there might be an 
implementation that does not do it hence i am going to go to the lowest common 
denominator - Icon.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 19:25:38 GMT, Alexander Zuev  wrote:

>> Here I am not talking about specification, I am talking about the usage of 
>> it, is the instanceof+cast is helpful? It does not look good, why we cannot 
>> always return MRI?
>
>> Here I am not talking about specification, I am talking about the usage of 
>> it, is the instanceof+cast is helpful?
> 
> It is necessary until all the consequences of always returning of MRI is 
> extensively tested on all the supported platforms and it does not cause any 
> serious regression or visual degradations. So for now i would not enforce MRI 
> usage in this method which means use base image class instead and do the cast 
> later.

I did not get how you will be able to force use MRI later since this method is 
implemented as a return icon. So this choice should be made before integration.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 18:49:53 GMT, Alexander Zuev  wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8182043
>>> 27:  * @requires os.family == "windows"
>> 
>> Other than using "explorer" what prevents us to run this test on other 
>> platforms?
>
>> Other than using "explorer" what prevents us to run this test on other 
>> platforms?
> 
> Because right now it makes no sense? The functionality we are testing is 
> implemented on Windows only. Once we extend it to other platforms we might 
> change the test.

But this is shared code, which has a specification it should work everywhere, 
so even if on Linux and macOS it is not implemented in the best way it should 
return something.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 19:35:57 GMT, Phil Race  wrote:

> Really I would need to see what the actual delta ends up being to be sure for 
> this case.

I have updated the method documentation. Could you please take a look before i 
finalized the CSR again? I am really trying to push this functionality into 17 
and there's not much time left. Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Phil Race
On Thu, 20 May 2021 19:22:50 GMT, Alexander Zuev  wrote:

>> But it is still part of the specification unlike implnote/apinote, and we 
>> cannot use non-public classes there, since other JavaSE implementations may 
>> not have this class. see discussion on the link above.
>
>> But it is still part of the specification unlike implnote/apinote
> 
> I think you can suggest usage of the implNote here - i am going from the 
> initial description of the reason implSpec in the JEP saying that 
> implementation and logic of it may vary between different Java SE 
> implementations and even between different platforms so i am going with the 
> original reasoning for implSpec tag existence. If you disagree, please file 
> the separate issue for spec amendment once this PR is integrated. Or we can 
> discuss it and i file follow-up bug - whatever you prefer, but i honestly 
> think it is not a blocker and that this technical issue linger in this state 
> for way too long.

We absolutely should NOT reference a non-API class in the public javadoc, no 
matter whether
it is an implNote or implSpec. 
Additionally, if you add or remove an implNote or implSpec or update it for 
something much more than a typo you will need to revise the CSR.

Really I would need to see what the actual delta ends up being to be sure for 
this case.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 17:29:55 GMT, Sergey Bylokhov  wrote:

> Here I am not talking about specification, I am talking about the usage of 
> it, is the instanceof+cast is helpful?

It is necessary until all the consequences of always returning of MRI is 
extensively tested on all the supported platforms and it does not cause any 
serious regression or visual degradations. So for now i would not enforce MRI 
usage in this method which means use base image class instead and do the cast 
later.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 17:33:08 GMT, Sergey Bylokhov  wrote:

> But it is still part of the specification unlike implnote/apinote

I think you can suggest usage of the implNote here - i am going from the 
initial description of the reason implSpec in the JEP saying that 
implementation and logic of it may vary between different Java SE 
implementations and even between different platforms so i am going with the 
original reasoning for implSpec tag existence. If you disagree, please file the 
separate issue for spec amendment once this PR is integrated. Or we can discuss 
it and i file follow-up bug - whatever you prefer, but i honestly think it is 
not a blocker and that this technical issue linger in this state for way too 
long.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 16:09:14 GMT, Sergey Bylokhov  wrote:

> Other than using "explorer" what prevents us to run this test on other 
> platforms?

Because right now it makes no sense? The functionality we are testing is 
implemented on Windows only. Once we extend it to other platforms we might 
change the test.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 17:25:33 GMT, Alexander Zuev  wrote:

>> test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 72:
>> 
>>> 70: if (icon.getImage() instanceof MultiResolutionImage) {
>>> 71: MultiResolutionImage mri = (MultiResolutionImage) 
>>> icon.getImage();
>>> 72: if (mri.getResolutionVariant(size, size) == null) {
>> 
>> This is to describe one of my questions above, is this instanceof+cast 
>> cannot be improved? Why we cannot always wrap the data in the MRI and if we 
>> have only one icon return the MRI with one resolution?
>
>> This is to describe one of my questions above, is this instanceof+cast 
>> cannot be improved? Why we cannot always wrap the data in the MRI and if we 
>> have only one icon return the MRI with one resolution?
> 
> No because in specification we say that we do not guarantee the the icon 
> returned will be MRI. We know how it works on Windows so we test it this way.

Here I am not talking about specification, I am talking about the usage of it, 
is the instanceof+cast is helpful? It does not look good, why we cannot always 
return MRI?

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 16:58:36 GMT, Alexander Zuev  wrote:

>> No they will have the same size. That's why the broad wording is used that 
>> we take a requested size into consideration but we will return the best 
>> possible icon we can get and we do not guarantee that the icon size will 
>> change the outcome. Even on Windows if we request icon if sizes 1, 2, 3 and 
>> 4 the icon will be basically the same - minimal quality icon available.
>
>> My point was that the implspec is a normative specification and we cannot 
>> refer to non-public classes in that documentation.
> 
> implSpec may describe the behavior of the default implementation and if it 
> means referring the non-public API to clarify the behavior of this method i 
> do not see any issue here.

But it is still part of the specification unlike implnote/apinote, and we 
cannot use non-public classes there, since other JavaSE implementations may not 
have this class. see discussion on the link above.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 16:14:42 GMT, Sergey Bylokhov  wrote:

> BTW this is why I recommended filing a CSR after the fix is fully discussed 
> and agreed upon.

The CSR was filed almost five years ago.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 15:57:04 GMT, Sergey Bylokhov  wrote:

> This is to describe one of my questions above, is this instanceof+cast cannot 
> be improved? Why we cannot always wrap the data in the MRI and if we have 
> only one icon return the MRI with one resolution?

No because in specification we say that we do not guarantee the the icon 
returned will be MRI. We know how it works on Windows so we test it this way.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 16:53:06 GMT, Alexander Zuev  wrote:

>> As for the example on Linux, how it will work for different sizes?
>>Icon icon1 = fsv.getSystemIcon(new File("."), 16);
>>Icon icon2 = fsv.getSystemIcon(new File("."), 32);
>> Will the resulted icons have proper size 16 and 32?
>
> No they will have the same size. That's why the broad wording is used that we 
> take a requested size into consideration but we will return the best possible 
> icon we can get and we do not guarantee that the icon size will change the 
> outcome. Even on Windows if we request icon if sizes 1, 2, 3 and 4 the icon 
> will be basically the same - minimal quality icon available.

> My point was that the implspec is a normative specification and we cannot 
> refer to non-public classes in that documentation.

implSpec may describe the behavior of the default implementation and if it 
means referring the non-public API to clarify the behavior of this method i do 
not see any issue here.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 16:13:41 GMT, Sergey Bylokhov  wrote:

>> My point was that the implspec is a normative specification and we cannot 
>> refer to non-public classes in that documentation.
>
> As for the example on Linux, how it will work for different sizes?
>Icon icon1 = fsv.getSystemIcon(new File("."), 16);
>Icon icon2 = fsv.getSystemIcon(new File("."), 32);
> Will the resulted icons have proper size 16 and 32?

No they will have the same size. That's why the broad wording is used that we 
take a requested size into consideration but we will return the best possible 
icon we can get and we do not guarantee that the icon size will change the 
outcome. Even on Windows if we request icon if sizes 1, 2, 3 and 4 the icon 
will be basically the same - minimal quality icon available.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 07:30:00 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Empty  tag before @implSpec causes warning during javadoc generation

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 27:

> 25:  * @test
> 26:  * @bug 8182043
> 27:  * @requires os.family == "windows"

Other than using "explorer" what prevents us to run this test on other 
platforms?

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 14:55:06 GMT, Alexey Ivanov  wrote:

>> The CSR is already approved and changing specification at this point will 
>> require to roll it back to draft and then going trough the approval process 
>> again which in turn risks this change not to make it in the upcoming LTS 
>> release. I would prefer to integrate it and create a follow-up bug to 
>> clarify the wording where we can discuss the matter and - if it is worth it 
>> - to submit a new CSR to amend the specification.
>
> If *user coordinate system* is used in similar context in other methods, we 
> should change the wording to match it. I don't mind using a new bug to 
> clarify *virtual pixels*.
> 
> The term *user space* (coordinate system) is used in the majority of cases.

BTW this is why I recommended filing a CSR after the fix is fully discussed and 
agreed upon.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 16:01:32 GMT, Sergey Bylokhov  wrote:

>>> The @implSpec is part of the specification, it is different from the 
>>> @implNote, no?
>>> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
>>> 
>>> If we will specify this method in a way that will require support on all 
>>> platforms we will get tck-red immediately after this push.
>> 
>> Not exactly. The implNote is a note for future maintainers or people who 
>> will extend the functionality of the method. There will be no tck-red 
>> because the method is working and we did noted that we are taking into 
>> consideration the icon size and whenever technical possible we should return 
>> the multiresolution icon. So, for example, on Linux code
>> `FileSystemView fsv = FileSystemView.getFileSystemView();
>> 
>> Icon icon = fsv.getSystemIcon(new File("."));
>> Icon icon2 = fsv.getSystemIcon(new File("."), 16);
>> System.out.println("icon = " + icon);
>> System.out.println("icon2 = " + icon2);
>> `
>> will get icon and icon2 as the same single-resolution icon - but that will 
>> change when underlying implementation will be fixed. Right now it is not 
>> technical possible to return multi-resolution icon - we do not do it on 
>> Linux. Implementing the underlaying code for different system, as i said, is 
>> outside of the scope of this change.
>
> My point was that the implspec is a normative specification and we cannot 
> refer to non-public classes in that documentation.

As for the example on Linux, how it will work for different sizes?
   Icon icon1 = fsv.getSystemIcon(new File("."), 16);
   Icon icon2 = fsv.getSystemIcon(new File("."), 32);
Will the resulted icons have proper size 16 and 32?

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 07:30:00 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Empty  tag before @implSpec causes warning during javadoc generation

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 72:

> 70: if (icon.getImage() instanceof MultiResolutionImage) {
> 71: MultiResolutionImage mri = (MultiResolutionImage) 
> icon.getImage();
> 72: if (mri.getResolutionVariant(size, size) == null) {

This is to describe one of my questions above, is this instanceof+cast cannot 
be improved? Why we cannot always wrap the data in the MRI and if we have only 
one icon return the MRI with one resolution?

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 10:36:39 GMT, Alexander Zuev  wrote:

>> The @implSpec is part of the specification, it is different from the 
>> @implNote, no?
>> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
>> 
>> If we will specify this method in a way that will require support on all 
>> platforms we will get tck-red immediately after this push.
>
>> The @implSpec is part of the specification, it is different from the 
>> @implNote, no?
>> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
>> 
>> If we will specify this method in a way that will require support on all 
>> platforms we will get tck-red immediately after this push.
> 
> Not exactly. The implNote is a note for future maintainers or people who will 
> extend the functionality of the method. There will be no tck-red because the 
> method is working and we did noted that we are taking into consideration the 
> icon size and whenever technical possible we should return the 
> multiresolution icon. So, for example, on Linux code
> `FileSystemView fsv = FileSystemView.getFileSystemView();
> 
> Icon icon = fsv.getSystemIcon(new File("."));
> Icon icon2 = fsv.getSystemIcon(new File("."), 16);
> System.out.println("icon = " + icon);
> System.out.println("icon2 = " + icon2);
> `
> will get icon and icon2 as the same single-resolution icon - but that will 
> change when underlying implementation will be fixed. Right now it is not 
> technical possible to return multi-resolution icon - we do not do it on 
> Linux. Implementing the underlaying code for different system, as i said, is 
> outside of the scope of this change.

The implspec is a specification and we cannot refer to non-public classes in 
that documentation.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexey Ivanov
On Thu, 20 May 2021 08:26:07 GMT, Alexander Zuev  wrote:

>> SurfaceData is not a public class, do we use this term somewhere in the 
>> spec? If not then it will be better to use size/points in the user space 
>> coordinate system, it is used already in the java2d.
>
> The CSR is already approved and changing specification at this point will 
> require to roll it back to draft and then going trough the approval process 
> again which in turn risks this change not to make it in the upcoming LTS 
> release. I would prefer to integrate it and create a follow-up bug to clarify 
> the wording where we can discuss the matter and - if it is worth it - to 
> submit a new CSR to amend the specification.

If *user coordinate system* is used in similar context in other methods, we 
should change the wording to match it. I don't mind using a new bug to clarify 
*virtual pixels*.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 08:25:25 GMT, Sergey Bylokhov  wrote:

> The @implSpec is part of the specification, it is different from the 
> @implNote, no?
> https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988
> 
> If we will specify this method in a way that will require support on all 
> platforms we will get tck-red immediately after this push.

Not exactly. The implNote is a note for future maintainers or people who will 
extend the functionality of the method. There will be no tck-red because the 
method is working and we did noted that we are taking into consideration the 
icon size and whenever technical possible we should return the multiresolution 
icon. So, for example, on Linux code
`FileSystemView fsv = FileSystemView.getFileSystemView();

Icon icon = fsv.getSystemIcon(new File("."));
Icon icon2 = fsv.getSystemIcon(new File("."), 16);
System.out.println("icon = " + icon);
System.out.println("icon2 = " + icon2);
`
will get icon and icon2 as the same single-resolution icon - but that will 
change when underlying implementation will be fixed. Right now it is not 
technical possible to return multi-resolution icon - we do not do it on Linux. 
Implementing the underlaying code for different system, as i said, is outside 
of the scope of this change.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 08:13:21 GMT, Alexander Zuev  wrote:

>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java 
>> line 272:
>> 
>>> 270: * returned is a multi-resolution icon image,
>>> 271: * which allows better support for High DPI environments
>>> 272: * with different scaling factors.
>> 
>> Is the above text correct on all platforms? If it is not always MRI then how 
>> the user should use the icon? instanceof+cast? BTW an example does not show 
>> how to solve the bug itself, on how to access the "large icons".
>> 
>> Need to clarify: the implSpec is a part of the specification so can we point 
>> the non public "ShellFolder" class?
>
> implSpec marks that the paragraph below describes the details and logic of 
> the default implementation and not the API specification. This tag also says 
> that it can be changed in overriding or extending methods so it is Ok to 
> specify non-public class to help describe the implementation specifics.
> 
> As for the correctness on all platforms - that's the end goal of this new 
> method and i believe it should be implemented this way everywhere where 
> technically possible. But exact implementation on all platforms except 
> Windows is outside of the scope of this exact changeset.

The @implSpec is part of the specification, it is different from the @implNote, 
no?
https://bugs.openjdk.java.net/browse/JDK-8266541?focusedCommentId=14419988=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14419988

If we will specify this method in a way that will require support on all 
platforms we will get tck-red immediately after this push.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 08:18:02 GMT, Sergey Bylokhov  wrote:

>>> What are the "virtual pixels"? I remember we refer to something similar by 
>>> the point in the "user space coordinate system" Or probably we use the 
>>> virtual pixels somewhere?
>> 
>> It is to say that the sizes are given in the same pixels as other components 
>> in the container and are subject to be rendered with different resolution 
>> based on the display scaling factor with preserving of relative sizes and 
>> proportions. The same terminology is used i.e. in SurfaceData.
>
> SurfaceData is not a public class, do we use this term somewhere in the spec? 
> If not then it will be better to use size/points in the user space coordinate 
> system, it is used already in the java2d.

The CSR is already approved and changing specification at this point will 
require to roll it back to draft and then going trough the approval process 
again which in turn risks this change not to make it in the upcoming LTS 
release. I would prefer to integrate it and create a follow-up bug to clarify 
the wording where we can discuss the matter and - if it is worth it - to submit 
a new CSR to amend the specification.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 08:07:48 GMT, Alexander Zuev  wrote:

>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java 
>> line 275:
>> 
>>> 273: *
>>> 274: * @param f a {@code File} object
>>> 275: * @param size width and height of the icon in virtual pixels
>> 
>> What are the "virtual pixels"? I remember we refer to something similar by 
>> the point in the "user space coordinate system" Or probably we use the 
>> virtual pixels somewhere?
>
>> What are the "virtual pixels"? I remember we refer to something similar by 
>> the point in the "user space coordinate system" Or probably we use the 
>> virtual pixels somewhere?
> 
> It is to say that the sizes are given in the same pixels as other components 
> in the container and are subject to be rendered with different resolution 
> based on the display scaling factor with preserving of relative sizes and 
> proportions. The same terminology is used i.e. in SurfaceData.

SurfaceData is not a public class, do we use this term somewhere in the spec? 
If not then it will be better to use size/points in the user space coordinate 
system, it is used already in the java2d.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 07:47:02 GMT, Sergey Bylokhov  wrote:

>> Alexander Zuev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Empty  tag before @implSpec causes warning during javadoc generation
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java 
> line 272:
> 
>> 270: * returned is a multi-resolution icon image,
>> 271: * which allows better support for High DPI environments
>> 272: * with different scaling factors.
> 
> Is the above text correct on all platforms? If it is not always MRI then how 
> the user should use the icon? instanceof+cast? BTW an example does not show 
> how to solve the bug itself, on how to access the "large icons".
> 
> Need to clarify: the implSpec is a part of the specification so can we point 
> the non public "ShellFolder" class?

implSpec marks that the paragraph below describes the details and logic of the 
default implementation and not the API specification. This tag also says that 
it can be changed in overriding or extending methods so it is Ok to specify 
non-public class to help describe the implementation specifics.

As for the correctness on all platforms - that's the end goal of this new 
method and i believe it should be implemented this way everywhere where 
technically possible. But exact implementation on all platforms except Windows 
is outside of the scope of this exact changeset.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
On Thu, 20 May 2021 07:46:28 GMT, Sergey Bylokhov  wrote:

> What are the "virtual pixels"? I remember we refer to something similar by 
> the point in the "user space coordinate system" Or probably we use the 
> virtual pixels somewhere?

It is to say that the sizes are given in the same pixels as other components in 
the container and are subject to be rendered with different resolution based on 
the display scaling factor with preserving of relative sizes and proportions. 
The same terminology is used i.e. in SurfaceData.

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Sergey Bylokhov
On Thu, 20 May 2021 07:30:00 GMT, Alexander Zuev  wrote:

>> Fix updated after first round of review.
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Empty  tag before @implSpec causes warning during javadoc generation

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 
272:

> 270: * returned is a multi-resolution icon image,
> 271: * which allows better support for High DPI environments
> 272: * with different scaling factors.

Is the above text correct on all platforms? If it is not always MRI then how 
the user should use the icon? instanceof+cast? BTW an example does not show how 
to solve the bug itself, on how to access the "large icons".

Need to clarify: the implSpec is a part of the specification so can we point 
the non public "ShellFolder" class?

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 
275:

> 273: *
> 274: * @param f a {@code File} object
> 275: * @param size width and height of the icon in virtual pixels

What are the "virtual pixels"? I remember we refer to something similar by the 
point in the "user space coordinate system" Or probably we use the virtual 
pixels somewhere?

-

PR: https://git.openjdk.java.net/jdk/pull/2875


Re: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v10]

2021-05-20 Thread Alexander Zuev
> Fix updated after first round of review.

Alexander Zuev has updated the pull request incrementally with one additional 
commit since the last revision:

  Empty  tag before @implSpec causes warning during javadoc generation

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2875/files
  - new: https://git.openjdk.java.net/jdk/pull/2875/files/59224696..09c7f8d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2875=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2875=08-09

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

PR: https://git.openjdk.java.net/jdk/pull/2875