I can't make any concrete promises but this is on our internal list of
things to try and find a resolution for with the Windows folks (I'm the
Java Engineering Manager). One of my team will likely spin up a new thread
if/when we have further details on this issue.
Cheers,
Martijn
On Tue, 23
For the record, Microsoft have no published a KB article acknowledging
the problem:-
https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used
-phil.
On 6/11/20, 9:12 PM, Jayathirth D v wrote:
+1.
Thanks,
Jay
On 12-Jun-2020, at 12:16 AM,
+1.
Thanks,
Jay
> On 12-Jun-2020, at 12:16 AM, Philip Race wrote:
>
>
> one more update to the tests
> cr.openjdk.java.net/~prr/8240654.2/
>
> I added
> @requires vm.gc.Z
>
> per the VM folks, ZGC needs Windows Server 2019 or the same vintage Window
> 10. if run on Windows Server 2016
>
+1
On 6/11/20 3:33 pm, Philip Race wrote:
BitBlt is not on the list of affected APIs provided by Microsoft.
And it is the JDK blit loop that copies from the Java heap memory into a
Windows bitmap buffer, so I don't see it being affected.
The BitBlt to the windows surface then operates on that
BitBlt is not on the list of affected APIs provided by Microsoft.
And it is the JDK blit loop that copies from the Java heap memory into a
Windows bitmap buffer, so I don't see it being affected.
The BitBlt to the windows surface then operates on that windows
allocated buffer.
-phil.
On
And if -Dsun.java2d.uiScale is set to "2" it will use the normal Blit.
It looks like the ScaledBlit uses "direct" access to the gdi surface.
ScaledBlit reads content of the GDIWindowSurfaceData in the GDIWinSD_GetRasInfo
and write it back in the
GDIWinSD_Unlock via BitBlt. Not sure this code
You can see the difference here from turning on tracing :-
$ jdk-client/build/windows-x64/jdk/bin/java -Dsun.java2d.d3d=false
-Dsun.java2d.uiScale=1.1 -Dsun.java2d.trace=log -XX:+UseZGC
LargeWindowPaintTest
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa,
AnyInt)
+1
-- Kevin
On 6/11/2020 11:46 AM, Philip Race wrote:
one more update to the tests
cr.openjdk.java.net/~prr/8240654.2/
I added
@requires vm.gc.Z per the VM folks, ZGC needs Windows Server 2019 or
the same vintage Window 10. if run on Windows Server 2016
ZGC errors out. This should prevent
one more update to the tests
cr.openjdk.java.net/~prr/8240654.2/
I added
@requires vm.gc.Z per the VM folks, ZGC needs Windows Server 2019 or the
same vintage Window 10. if run on Windows Server 2016
ZGC errors out. This should prevent that. -phil.
On 6/11/2020 11:13 AM, Kevin Rushforth
On 6/11/20 9:55 am, Philip Race wrote:
I have confirmed hit a different code path. It goes through generic 2D s/w
loops in this case.
ie we don't use GDIBlitLoops at all. The code in sun/java2d/pipe/DrawImage.java
ends up in
scaleSurfaceData which uses the loops in ScaledBlit.c.
But as far
+1
The updated LargeWindowPaintTest fails for me without the fix without my
having to manually set uiScale. It passes with the fix.
Interestingly enough, I finally saw the problem that Jay reported with
AlphaPrintTest: without the fix I initially get a blank (all white)
window. If I resize
Updated webrev here
http://cr.openjdk.java.net/~prr/8240654.1/index.html
The only changes are to the tests - to add -Dsun.java2d.uiScale=1 to the
onscreen test
and to add printer to the keys for the printing test.
It was pointed out by Stefan from the ZGC team that the changes in
I have confirmed hit a different code path. It goes through generic 2D
s/w loops in this case.
ie we don't use GDIBlitLoops at all. The code in
sun/java2d/pipe/DrawImage.java ends up in
scaleSurfaceData which uses the loops in ScaledBlit.c.
It is a bit surprising to me since I'd expect us to
> On 11-Jun-2020, at 8:58 PM, Kevin Rushforth
> wrote:
>
>
> > Also - for both of you - with the fix and without forcing uiScale=1 does
> > the test pass ?
>
> Yes the test passes with the fix and also passes without the fix if I don't
> force uiScale=1.
Same behaviour in my machine for
> On 11-Jun-2020, at 8:03 PM, Philip Race wrote:
>
>
>
> On 6/11/20, 1:57 AM, Jayathirth D v wrote:
>>
>> Hi Phil,
>>
>> I tried tested the fix in my Windows 10 machine with Intel integrated UHD
>> Graphics 620.
>>
>> LargeWindowPaintTest.java passes with/without fix in my machine.
>>
> Also - for both of you - with the fix and without forcing uiScale=1
does the test pass ?
Yes the test passes with the fix and also passes without the fix if I
don't force uiScale=1.
-- Kein
On 6/11/2020 7:44 AM, Philip Race wrote:
Can I get clarification here.
> I do, and had to run
Blitting a full screen window for me (slightly under 1920x1080) is a
little under 3 ms.
With no need to copy / retry it is a just around 1 ms which I am not
sure whether to trust completely.
On another machine with a finer grained timer it was > 1 ms.
-phil.
On 6/10/2020 6:50 PM, Sergey
Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.
-phil.
On 6/11/20, 7:44 AM, Philip Race wrote:
Can I get clarification here.
> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see
the failure with
Can I get clarification here.
> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see
the failure with LargeWindowPaintTest.
So you both mean a JDK 15 promoted build without this fix and without
this property passes because you have
a hidpi setup. And to see the failure without
On 6/11/20, 1:57 AM, Jayathirth D v wrote:
Hi Phil,
I tried tested the fix in my Windows 10 machine with Intel integrated
UHD Graphics 620.
LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame without any
instructions
Yes my machine was at 150% scaling.
If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.
@Phil : I think its better if we test at uiScale=1(larger memory footprint).
Please clarify.
Thanks,
Jay
Do you have a Hi-DPI machine? I do, and had to run with
"-Dsun.java2d.uiScale=1" in order to see the failure with
LargeWindowPaintTest.
For AlphaPrintTest, the test deliberately ensures that you print before
saying whether it passes or not. FWIW, I verified that the printing test
on my
Hi Phil,
I tried tested the fix in my Windows 10 machine with Intel integrated UHD
Graphics 620.
LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame without any
instructions and with fix it shows instructions for the test.
Typo : I tried tested -> I tried testing
> On 11-Jun-2020, at 2:27 PM, Jayathirth D v wrote:
>
> Hi Phil,
>
> I tried tested the fix in my Windows 10 machine with Intel integrated UHD
> Graphics 620.
>
> LargeWindowPaintTest.java passes with/without fix in my machine.
> AlphaPrintTest.java
+1
Just curious about what performance degradation we will have in the worst case.
On 6/10/20 3:57 pm, Kevin Rushforth wrote:
+1
Code changes look good.
I verified that the bug happens on my Windows 10 laptop with SwingSet2 and with
the LargeWindowPaintTest without the patch, and everything
+1
Code changes look good.
I verified that the bug happens on my Windows 10 laptop with SwingSet2
and with the LargeWindowPaintTest without the patch, and everything
looks good with the patch.
-- Kevin
On 6/10/2020 1:48 PM, Philip Race wrote:
Bug:
Bug: https://bugs.openjdk.java.net/browse/JDK-8240654
Webrev: http://cr.openjdk.java.net/~prr/8240654/index.html
This is for JDK 15 so review ASAP please since RDP 1 and the test cycle
are looming.
This is not a fix for a JDK bug. It is a bunch of workarounds for a
Microsoft Windows bug
27 matches
Mail list logo
