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

Philip Race philip.race at oracle.com
Fri Sep 9 15:14:22 UTC 2016 

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