[OpenJDK 2D-Dev] [9] Review Request: 8146042 Offscreen rendering is different from onscreen one
Semyon Sadetsky
semyon.sadetsky at oracle.com
Tue Jan 19 11:30:22 UTC 2016
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 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/
>>>>>
>>>>> In this cases non-retina hw will not be covered. If there are some
>>>>> issues in the Robot, then you can skip it and use VolatileImage as a
>>>>> destination for rendering.
>>>> But the issue is reproducible in on-screen painting on Windows
>>>> platform.
>>>> It isn't necessary to spent extra efforts on the Mac workaround. The
>>>> test can be extended to the Mac platform later when Robot is fixed.
>>>
>>> I am sure that the problem is not in the robot itself, but in the fact
>>> the test does not take into account that device scale is not necessary
>>> =1 in which case it calculates incorrect expected coordinates. If this
>>> is the case then the same issue will be on win/linux with HiDPI
>>> display.
>> Not sure. I have Linux with retina display. The problem with Mac is that
>> lines are drawn with 1 pixel precision but screenshots are produced in
>> low resolution and 1px width black line becomes a blured gray line on
>> it. So is not possible to autotest with such inaccurate instrument.
>
> This problem should go away if usage of robot class will be skipped,
> just draw to VolatileImage and check its pixels via getSnapshot()(take
> into account default device scale). 1pt line in case of retina should
> be drawn in 2px.
>
>>> Can you also provide an additional information/examples on which
>>> coordinates we get an rounding error.
>> Please look on the left screenshot attached to the JIRA. Checkbox
>> rectangles are wrong.
>
> I mean the coordinates and code where we get this error. Something
> like this(when we draw the line in point 10 to point 12 we get an
> error when we calculate 12-10 etc)
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 my mac book-pro with integrated i7 GPU - rectangle is
drawn at wrong position.
--Semyon
>
>>>
>>>>>
>>>>>>
>>>>>> --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