Re: [OpenJDK 2D-Dev] RFR: 8171303 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux
On 01.09.2020 03:42, Ajit Ghaisas wrote: In the HiDPI mode the VolatileImage internally have twice more pixels than BufferedImage, so when we draw the data to the VolatileImage and then scale it back to the size of the BufferedImage for comparison, the test fails. This looks good. I checked with OGL and Metal (project Lanai) on macOS. One question is - do we need to support this test in HiDPI mode? The difference between HiDPI and non-HiDPI mode is that VolatileImage has more pixels and every draw operation use scaled blits. The test in question scales the graphics ourselves. To eliminate the "sun.java2d.uiScale=1" we will need to apply the scale to the BufferedImage size, then we should skip the usage of "getSnapshot", and then we will need to scale all rendering to the BufferedImage(simulating the HiDPI in VolatileImage), but in the end, the same scaled blit will be tested. -- Best regards, Sergey.
Re: [OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week
As per the notifiication last week, as of NOW there should be NO MORE pushes to the hg://openjdk.java.net/jdk/client forest. --- So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to jdk/client should be >> 9am PDT Tuesday 1st Sept 2020 << --- -phil. On 8/28/20, 10:53 AM, Philip Race wrote: All, Contingent on Project Skara (ie mercurial ->git / githib) going active for the JDK project on schedule on 5th September, we intend to retire the jdk/client repo/forest as part of this transition. In other words, once mercurial is shut down and we move to git there will ONLY be the main JDK repo and all client pushes will go there. We will be making some internal testing changes which we hope will help us spot any breakages that pushes cause in time to prevent them making their way directly into a promoted build but they can't completely replace the manual testing we have been doing, so we will also be dependent on folks to be extra diligent from now on and not assume there is a gatekeeper who will spot their mistakes. But we do need some time to "flush" any last changes in client to jdk before mercurial shuts down. So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to jdk/client should be >> 9am PDT Tuesday 1st Sept 2020 << Anything pushed after that time may be lost forever :-) We'll also further enforce this as of 9am PDT Wednesday 2nd Sept 2020 by making the client repo mercurial repo read-only. The 24 hours is to help the integrator/gate keeper - not for your late pushes, For example if there's a breakage we need to back out before integrating we might need this. So not even "doc" or "test" changes - nothing please ! You may reasonably ask why then Tue/Wed for this if skara is not transitioning until Sat 5th September ? The answer is that in an unfortunate coincidence of timing we have a big lab move that begins around 9am PT Wed 2nd September, and all our testing capabilities will be off-line for several days. So any test jobs submitted after sometime Tuesday won't have time to complete, and the lab move won't be complete until after the skara transition. Any outstanding reviews that don't make the cut-off will of course have to be resubmitted as github pull requests and any approvals they may have accumulated will need to be re-approved. All of this is of course true for folks pushing directly to the mercurial main JDK repo - it is not related to the client repo retirement. -Phil
Re: [OpenJDK 2D-Dev] RFR: 8171303 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux
> On 26-Aug-2020, at 5:05 AM, Sergey Bylokhov > wrote: > > On 25.08.2020 14:59, Philip Race wrote: >> This is fine but >> 1) I like to see the bug under which you fixed it in the @bug list. > > It is not a product bug and the test isn't reworked, so it is not necessary > to have this test fix in the list of bugs > >> 2) I am not sure I see how all the various reasons for this test failing can >> be explained by this. > > In the HiDPI mode the VolatileImage internally have twice more pixels than > BufferedImage, so when we draw the data to > the VolatileImage and then scale it back to the size of the BufferedImage for > comparison, the test fails. This looks good. I checked with OGL and Metal (project Lanai) on macOS. One question is - do we need to support this test in HiDPI mode? > >> -phil. >> On 8/25/20, 1:37 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk/client. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171303 >>> Fix: http://cr.openjdk.java.net/~serb/8171303/webrev.00 >>> >>> This the only test which was created to check different types of >>> interpolation. >>> It checks the rendering to the VolatileImage and uses BufferedImage as a >>> gold image. >>> But it does not take into account that rendering to the VolatileImage might >>> be affected >>> by the HiDPI support. >>> > > > -- > Best regards, Sergey.
Re: [OpenJDK 2D-Dev] RFR: 8252133 The java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal pipeline is active
Hi Sergey, The fix looks good for me. Looking forward to your pull request. Best Regards, Alexey > On 30 Aug 2020, at 03:45, Sergey Bylokhov wrote: > > On 29.08.2020 17:39, Phil Race wrote: >> Sergey, >> The priority now is to flush outstanding review requests ahead of the skara >> transition. I should have made that clearer in my email but I think new >> requests such as this will need to wait. Especially anything that requires >> some deep thought by a reviewer as we have just one working day left. > > It is not a big deal to convert such a request to the PR. So I will work to > the usual rhythm and convert all review requests to PR once we moved to the > github. > >> -Phil. >>> On Aug 29, 2020, at 5:29 PM, Sergey Bylokhov >>> wrote: >>> >>> Hello. >>> Please review the fix for jdk/client. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8252133 >>> Fix: http://cr.openjdk.java.net/~serb/8252133/webrev.00 >>> >>> This bug easily reproduced by the test in question on the dual video card >>> systems >>> when the metal pipeline is active. But it is possible to reproduce it in >>> the OGL >>> pipeline as well, but it is required some additional steps. >>> >>> >>> Problem description: >>> Our CGraphicsEnvironment maintains the list of active graphics devices. >>> The one >>> important feature of this CGraphicsEnvironment is to invalidate the old >>> devices and >>> map them to the new devices. For example, if the user got a reference to >>> the device, >>> and this device was removed then this reference will refer to the main >>> screen. >>> >>> The problem in the current implementation arise when the system has two >>> video cards: >>> 1 The user get some GraphicsDevice >>> 2 The user sets the full-screen window for this device >>> 3 The user change screen resolution for this device >>> 4 The resolution of the screen is not changed ->> BUG. >>> >>> The problem is that somewhere after step 1 or 2 and before step 3 the macOS >>> decided >>> to switch to the discrete video card, but it does not report the old >>> device(integrated VC) >>> as removed, because actually no screens were removed. >>> >>> Since it was not reported as removed we did not invalidate it and did not >>> map it to the >>> new device ->> request to change the screen resolution at step 3 send to >>> some non existed >>> deviceID. >>> >>> As a fix I suggest to change this logic: >>> - Invalidate devices reported by macOS as removed >>> - Initialize the main screen >>> - Initialize all NEW screens >>> >>> To this logic: >>> - Ignore devices reported by the macOS as removed >>> - Initialize the main screen >>> - Initialize all NEW screens >>> - Check that the main device is in the list of all NEW devices >>> - Invalidate all OLD devices which are not in the list of NEW devices >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey.
