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

Fri Sep 9 00:12:54 UTC 2016

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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>