[OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one

Vadim Pakhnushev vadim.pakhnushev at oracle.com
Fri Sep 9 11:27:16 UTC 2016


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 cards/drivers.
To check if it's reproducible for you, hover the mouse above checkboxes 
in SwingSet2.
For me they appears corrupted after the hover.

Thanks,
Vadim

On 09.09.2016 14:16, Semyon Sadetsky wrote:
>
>
> 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 _without the fix_.
>>> My fix is not aimed to fix 803944. I cannot reproduce it. I have 
>>> i5-4300M (HD Graphics 4600) and Intel driver 10.18.10.3412 signed by 
>>> Microsoft. Which Intel card/APU and driver do you have?
>>
>> You removed all Intel cards from blacklist and this reintroduced 
>> 803944 since your fix doesn't address it.
>> 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 803944 again?
>>
>> What about the RenderRectTest? In what configuration it fails?
> It falls with d3d on Intel APUs.
>
> --Semyon
>>
>>>>
>>>> Do you have a standalone test from the original report?
>>> Simply run SwinSet2: all horizontal/vertical lines are shifted +1 px.
>>
>> Could you please be more specific? Shifted from where to where? Maybe 
>> attach good/bad screenshots to the JIRA?
>>
>> Thanks,
>> Vadim
>>
>>>
>>> --Semyon
>>>>
>>>> Vadim
>>>>
>>>> On 09.09.2016 10:31, 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, 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?
>>>>>
>>>>> It may be disabled by default, but at least the 
>>>>> sun.java2d.d3d=true option could enable it, no?
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 9/9/2016 4:58 AM, Philip Race wrote:
>>>>>> 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 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 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")
>>>>>>>>  #define NO_VERSION D_VERSION(0xffff, 0xffff, 0xffff, 0xffff)
>>>>>>>>
>>>>>>>>  static const ADAPTER_INFO badHardware[] = {
>>>>>>>>
>>>>>>>> -    // All Intel Chips.
>>>>>>>> -    { 0x8086, ALL_DEVICEIDS, NO_VERSION, OS_ALL },
>>>>>>>> -
>>>>>>>>      // ATI Mobility Radeon X1600, X1400, X1450, X1300, X1350
>>>>>>>>      // Reason: workaround for 6613066, 6687166
>>>>>>>>      // X1300 (four sub ids)
>>>>>>>>      { 0x1002, 0x714A, D_VERSION(6,14,10,6706), OS_WINXP },
>>>>>>>>      { 0x1002, 0x714A, D_VERSION(7,14,10,0567), OS_VISTA },
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 9/8/16, 4:06 PM, Semyon Sadetsky wrote:
>>>>>>>>> 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 ?
>>>>>>>>>>> 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 defer this.
>>>>>>>>>> I suppose those fudge factors are obtained experimentally. 
>>>>>>>>>> Not sure that any rationale is possible here.
>>>>>>>>>> The fix simply tested on different hardware. I hope after 
>>>>>>>>>> this fix D3D maybe enabled again for Intel APUs.
>>>>>>>>>> Currently it has been blacklisted in 8039444.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>>
>>>>>>>>>>> IIRC Semyon will need to change the code to bypass the check
>>>>>>>>>>> for Intel hardware. There is no env. variable or system 
>>>>>>>>>>> property to do this.
>>>>>>>>>>>
>>>>>>>>>>> -phil.
>>>>>>>>>>>
>>>>>>>>>>> On 9/8/16, 3:47 AM, Sergey Bylokhov wrote:
>>>>>>>>>>>> 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/
>>>>>>>>>>>>
>>>>>>>>>>>> Can you please confirm that the fix and test works if d3d 
>>>>>>>>>>>> is enabled on the intel vk? I recall that d3d was disabled 
>>>>>>>>>>>> on intel so probably to check that we need to force d3d 
>>>>>>>>>>>> manually.
>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/18/2016 9:12 AM, Semyon Sadetsky wrote:
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> 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 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/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I run the latest test(webrev.03) on my nvidia card, and 
>>>>>>>>>>>>>>>> it fails
>>>>>>>>>>>>>>>> after the fix, but pass before =(. I have no ati to 
>>>>>>>>>>>>>>>> check. Also I
>>>>>>>>>>>>>>>> cannot check the fix on intel card, because I cannot 
>>>>>>>>>>>>>>>> enable d3d on it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 1/14/2016 9:23 PM, Phil Race wrote:
>>>>>>>>>>>>>>>>>> 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 
>>>>>>>>>>>>>>>>>> hardware-dependent
>>>>>>>>>>>>>>>>>> territory but
>>>>>>>>>>>>>>>>>> it seems quite possible that this could just as 
>>>>>>>>>>>>>>>>>> easily introduce a
>>>>>>>>>>>>>>>>>> different artifact
>>>>>>>>>>>>>>>>>> on some other hardware.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What exactly are you testing on ? And I think it 
>>>>>>>>>>>>>>>>>> needs to include at
>>>>>>>>>>>>>>>>>> least one Nvidia
>>>>>>>>>>>>>>>>>> and one AMD/ATI card.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -phil.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 1/14/2016 10:09 AM, Semyon Sadetsky wrote:
>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please review the fix for jdk9.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146042
>>>>>>>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8146042/webrev.00/ 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The root cause is incorrect coordinate rounding in 
>>>>>>>>>>>>>>>>>>> D3D renderer. To
>>>>>>>>>>>>>>>>>>> fix the issue one of fudge factors was adjusted.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Another issue mentioning in the JIRA ticket is taken 
>>>>>>>>>>>>>>>>>>> out as a
>>>>>>>>>>>>>>>>>>> separate bug.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>




More information about the 2d-dev mailing list