Thanks! I found this setting very useful.
--Semyon
On 9/30/2016 6:51 AM, Philip Race wrote:
BTW I just noticed in the source code that there is an
environment variable that disables the check :
see windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
static BOOL bNoHwCheck =
BTW I just noticed in the source code that there is an
environment variable that disables the check :
see windows/native/libawt/java2d/d3d/D3DPipelineManager.cpp
static BOOL bNoHwCheck = (getenv("J2D_D3D_NO_HWCHECK") != NULL);
if that is set it does everything except return the code that means
I think this bug should be downgraded to P4 and deferred.
Put a link in the bug report to the fix so we can revive it later.
-phil.
On 9/9/16, 6:55 AM, Semyon Sadetsky wrote:
On 9/9/2016 4:08 PM, Vadim Pakhnushev wrote:
On 09.09.2016 15:58, Semyon Sadetsky wrote:
On 09.09.2016 14:45, Vadim
No .. that would be an incompatible change that might surprise a lot of
people.
-phil.
On 9/9/16, 12:31 AM, Semyon Sadetsky wrote:
I cannot reproduce JDK-803944. It is about very specific hardware
configuration with two different video cards.
I didn't find any evaluation/justification,
On 9/9/2016 4:08 PM, Vadim Pakhnushev wrote:
On 09.09.2016 15:58, Semyon Sadetsky wrote:
On 09.09.2016 14:45, Vadim Pakhnushev wrote:
My cards are HD Graphics 3000 (0x8086/0x0126) with 9.17.10.4101 and
ATI Radeon HD 5700 (0x1002/0x68b8) with driver 8.17.10.1333
ATI is unrelated to this
On 09.09.2016 15:58, Semyon Sadetsky wrote:
On 09.09.2016 14:45, Vadim Pakhnushev wrote:
My cards are HD Graphics 3000 (0x8086/0x0126) with 9.17.10.4101 and
ATI Radeon HD 5700 (0x1002/0x68b8) with driver 8.17.10.1333
ATI is unrelated to this fix. Could you upgrade to the latest driver
from
On 09.09.2016 14:45, Vadim Pakhnushev wrote:
My cards are HD Graphics 3000 (0x8086/0x0126) with 9.17.10.4101 and
ATI Radeon HD 5700 (0x1002/0x68b8) with driver 8.17.10.1333
ATI is unrelated to this fix. Could you upgrade to the latest driver
from
My cards are HD Graphics 3000 (0x8086/0x0126) with 9.17.10.4101 and
ATI Radeon HD 5700 (0x1002/0x68b8) with driver 8.17.10.1333
ATI is unrelated to this fix. Could you upgrade to the latest driver
from https://downloadcenter.intel.com/search?keyword=hd+graphics+3000
and try to reproduce
Yes I can see it now, the test fails only if I remove Intel cards from
blacklist.
And it passes with the fix and SwingSet2 looks better.
Unfortunately, this reintroduce 803944 at least on my card/driver and
from the history of that bug the issue can be reproduced on wide variety
of
On 09.09.2016 13:43, Vadim Pakhnushev wrote:
On 09.09.2016 13:12, Semyon Sadetsky wrote:
On 09.09.2016 12:56, Vadim Pakhnushev wrote:
Semyon,
I can reproduce JDK-803944 on my machine with your fix.
More importantly, the RenderRectTest is passed for me on Windows 7
on ATI and Intel cards
On 09.09.2016 13:12, Semyon Sadetsky wrote:
On 09.09.2016 12:56, Vadim Pakhnushev wrote:
Semyon,
I can reproduce JDK-803944 on my machine with your fix.
More importantly, the RenderRectTest is passed for me on Windows 7 on
ATI and Intel cards _without the fix_.
My fix is not aimed to fix
On 09.09.2016 12:56, Vadim Pakhnushev wrote:
Semyon,
I can reproduce JDK-803944 on my machine with your fix.
More importantly, the RenderRectTest is passed for me on Windows 7 on
ATI and Intel cards _without the fix_.
My fix is not aimed to fix 803944. I cannot reproduce it. I have
i5-4300M
Semyon,
I can reproduce JDK-803944 on my machine with your fix.
More importantly, the RenderRectTest is passed for me on Windows 7 on
ATI and Intel cards _without the fix_.
Do you have a standalone test from the original report?
Vadim
On 09.09.2016 10:31, Semyon Sadetsky wrote:
I cannot
I cannot reproduce JDK-803944. It is about very specific hardware
configuration with two different video cards.
I didn't find any evaluation/justification, neither in JIRA nor in the
review on the alias, for the 803944 resolution that d3d should be
disabled for all Intel video cards. Why?
Please consider https://bugs.openjdk.java.net/browse/JDK-8039444
and the various bugs that were closed as a duplicate of that bug.
I don't think you can easily show this fix resolves all of these ..
-phil.
On 9/8/16, 5:12 PM, Semyon Sadetsky wrote:
I have 2 laptops Intel i5, i7. Both working
I have 2 laptops Intel i5, i7. Both working with d3d normally. Some
visual defects will be corrected after this fix.
And I didn't get why d3d is disabled for all Intel without possibility
to switch it on?
--Semyon
On 09.09.2016 02:10, Philip Race wrote:
The following is just for testing
The following is just for testing right ? It should not be in this webrev
as part of what you propose to push ..
--
src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h
Print this page
@@ -49,13 +49,10 @@
// all versions must fail ("there's no version of the driver that passes")
I have reworked fix to not affect ATI and NVidia.
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.05/
--Semyon
On 9/9/2016 12:20 AM, Semyon Sadetsky wrote:
On 08.09.2016 22:57, Philip Race wrote:
Can you provide something like a rationale for why these particular
values might work
Can you provide something like a rationale for why these particular
values might work ?
Otherwise this seems like a fix that can't be reviewed, only tested.
So that testing will be important. If you can be sure it passes
on ATI, Nvidia, and Intel then we can take it .. otherwise we should
On 05.09.16 13:36, Semyon Sadetsky wrote:
At last I could get NVidia machine (special thanks to Yuri).
The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/
At last I could get NVidia machine (special thanks to Yuri).
The updated fix should improve the situation on NVidia. For that one
common height/width fudge factor was separated in two different.
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.04/
--Semyon
On 3/18/2016 9:12 AM, Semyon
Hi Phil,
Sergey wrote it fails on nvidia cards. I could play with fudge factors
values but I don't have nvidia based video to test.
--Semyon
On 3/17/2016 11:05 PM, Phil Race wrote:
Semyon,
Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
Semyon,
Any update on this ?
FWIW I used jprt to build your patch as I am having windows build
problems and
it passed on my ATI card.
-phil.
On 03/01/2016 04:37 PM, Sergey Bylokhov wrote:
On 15.01.16 9:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot
On 15.01.16 9:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact pixel to
pixel image but the scaled one. So Mac platform should be excluded from
testing:
Please see the updated webrev
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.03/.
The test is changed to execute per-pixel compare of on-screen and
off-screen images in case of HiDPI device since the shape positioning
depends on the scale factor.
--Semyon
On 2/7/2016 11:37 PM, Sergey
On 2/7/2016 11:37 PM, Sergey Bylokhov wrote:
On 01.02.16 12:23, Semyon Sadetsky wrote:
On 1/21/2016 5:04 PM, Sergey Bylokhov wrote:
On 19/01/16 14:30, Semyon Sadetsky wrote:
We are getting error because of incorrect fudge factor added to the
"to"
line coordinates (for line from - to).
On 19/01/16 14:30, Semyon Sadetsky wrote:
We are getting error because of incorrect fudge factor added to the "to"
line coordinates (for line from - to).
See the updated version of the fix in which test should work on OS X:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.02/
Test fails on
On 1/16/2016 12:10 AM, Sergey Bylokhov wrote:
On 15/01/16 19:40, Semyon Sadetsky wrote:
On 1/15/2016 6:46 PM, Sergey Bylokhov wrote:
On 15/01/16 17:29, Semyon Sadetsky wrote:
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact pixel to
pixel image but the scaled one. So Mac platform should be excluded from
testing:
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact pixel to
pixel image but the scaled one. So Mac platform
On 15/01/16 17:29, Semyon Sadetsky wrote:
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact pixel to
pixel
On 1/15/2016 6:46 PM, Sergey Bylokhov wrote:
On 15/01/16 17:29, Semyon Sadetsky wrote:
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen
On 15/01/16 19:40, Semyon Sadetsky wrote:
On 1/15/2016 6:46 PM, Sergey Bylokhov wrote:
On 15/01/16 17:29, Semyon Sadetsky wrote:
On 1/15/2016 4:30 PM, Sergey Bylokhov wrote:
On 15/01/16 09:59, Semyon Sadetsky wrote:
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other
Hi, Semyon.
On what OS/VideCards did you test it? The test fails on my OSX using ogl
pipeline.
On 14/01/16 21:09, Semyon Sadetsky wrote:
Hello,
Please review the fix for jdk9.
bug: https://bugs.openjdk.java.net/browse/JDK-8146042
webrev:
This fudge factor was last adjusted in
https://bugs.openjdk.java.net/browse/JDK-6597822
way back before the D3D pipeline was released and the comments seem to
indicate that
there was a fair amount of testing on different hardware.
I don't know why this seems to be in un-specified
Hi Phil & Sergey,
I have integrated Intel GPU i5 and cannot test other hardware.
On Mac's retina display the screen capture doesn't return exact pixel to
pixel image but the scaled one. So Mac platform should be excluded from
testing:
http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.01/
36 matches
Mail list logo
