On 2/7/2016 11:37 PM, Sergey Bylokhov wrote:
On 01.02.16 12:23, Semyon Sadetsky wrote:
On 1/21/2016 5:04 PM, Sergey Bylokhov wrote:
On 19/01/16 14:30, Semyon Sadetsky wrote:
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.
It will fail on any hdpi systems(including osx+retina), The reason is
that: when you create a VolatileImage it will take into account
default transform of the GraphicsConfiguration(on hdpi systems it will
be x2). When you draw a line to this VI and then take s spapshot then
you convert the big VI image to the small BI. you need to take into
account this scale and draw VI to BI 1-2-1, something like this:
BufferedImage capture = new BufferedImage(12x2, 12x2,
BufferedImage.TYPE_4BYTE_ABGR_PRE);
capture.createGraphics().drawImage(vi,0,0,12x2,12x2,null);
Note that even in this case the line locations check is incorrect and
should be adjusted.
I tried what you've proposed. The position of the up-scaled image is
wrong as well 1-21 instead of 2-22.
Why wrong? this is correct result, the simple BufferedImage will
produce the same:
BufferedImage bi = new BufferedImage(12*2, 12*2,
BufferedImage.TYPE_INT_ARGB_PRE);
Graphics2D g1 = bi.createGraphics();
g1.scale(2,2);
g1.setColor(Color.black);
g1.drawRect(1, 1, 9, 9);
g1.dispose();
ImageIO.write(bi,"png",new File("gold.png"));
When you draw a line you set the middle point of the line, not the
left point. So the x=1px when scaled will cover the pixels 1 and 2,
not the 2 and 3.
No, the correct will be 2 and 3. In the small image 0 is white and 1 is
black. In its 2x-upscaled variant 0 and 1 are white and 2 and 3 are black.
The resulting rectangle should be centered in the image but it is
shifted to left top corner by 1px.
I think test may be remained the same.
--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
