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

[Philip Race]

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