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)
--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
--
Best regards, Sergey.
