Re: [OpenJDK 2D-Dev] Request for Review: JDK-8162591 All existing gradient paint implementations have issues with coordinates/sizes larger than Short.MAX_VALUE (exactly) on any Linux systems

2016-09-28 Thread Sergey Bylokhov

Thanks.

On 28.09.16 8:45, Clemens Eisserer wrote:

HI Jim,


All of those conditions are optimized equivalents to getting the
determinant.

invert() is a destructive call, but since getTransform is documented to
return a copy, that is fine - but getDeterminant() will involve less math to
check the condition...


Thanks for the clarification.

Please find the latest version of the patch at
http://93.83.133.214/8162591/webrev.04/ - where catching the Exception
has been replaced with a != 0.0 check against the determinant. Please
commit  in case no further issues are found.

Best regards, Clemens




--
Best regards, Sergey.


Re: [OpenJDK 2D-Dev] [8u Backport] Fix for JDK-8158356 : SIGSEGV when attempting to rotate BufferedImage using AffineTransform by NaN degrees

2016-09-28 Thread Philip Race

+1

-phil

On 9/14/16, 2:52 AM, Ajit Ghaisas wrote:

Hi Jim,

 I agree upon aborting the operation in case the non-finite slope is not 
due to divide by 0 case.
 As this is the 8u backport of the fix done in 9, I will address the review 
comment in JDK-8166009.

 The original backport webrev is still the same.
 http://cr.openjdk.java.net/~aghaisas/8158356/8u_backport/webrev.00/

 Request you to approve this 8u backport.

Regards,
Ajit

-Original Message-
From: Jim Graham
Sent: Friday, September 02, 2016 1:16 AM
To: Ajit Ghaisas; Philip Race; 2d-dev
Subject: Re: [8u Backport] Fix for JDK-8158356 : SIGSEGV when attempting to 
rotate BufferedImage using AffineTransform by NaN degrees

Hi Ajit,

In the cases where you "continue" on a non-finite slope, doesn't that mean that 
the edges will be mismatched?  If you can't determine the bounding polygon, perhaps the 
entire operation should be aborted instead...?

It's different from the case of dy1==dy2 which also results in a "continue" 
because in that case there are no edges to insert in the array because that edge of the 
bounding box doesn't occupy any vertical space.  In the case of an infinite slope, there 
could be edges expected to be produced (in fact there should be because we've already 
tested that dy1 != dy2), but the loop doesn't produce any edge values and stale data is 
left in the array.

...jim

On 9/1/16 2:14 AM, Ajit Ghaisas wrote:

Hi,



This is a review request for 8u back-port of the fix done in JDK-9.



Bug :

https://bugs.openjdk.java.net/browse/JDK-8158356



Root cause :

The root cause of the crash is - NaN is converted to an integer and used as 
array index in mlib_ImageScanPoly.c.



Fix :

The native method previously did not check the validity of the
input double argument. Now, I have added a check for finite double values.



Webrev :


http://cr.openjdk.java.net/~aghaisas/8158356/8u_backport/webrev.00/



Regards,

Ajit



Re: [OpenJDK 2D-Dev] [9] RFR JDK-8166685: We should unpin stream and pixel buffer in case of setjmp during writeImage in JPEG.

2016-09-28 Thread Philip Race

+1

-phil.

On 9/26/16, 12:35 AM, Jayathirth D V wrote:


Hi,

Please review the following fix in JDK9 at your convenience:

Bug : https://bugs.openjdk.java.net/browse/JDK-8166685

Webrev : http://cr.openjdk.java.net/~jdv/8166685/webrev.00/ 



Issue : As part of fix for JDK- 8162461 we removed RELEASE_ARRAYS() in 
writeImage() call in imageioJPEG.c for setjmp case.


Root cause : We can perform non-local jump to setjmp from longjmp 
during anytime in write process. If there is no RELEASE_ARRAYS() call 
then it might crash JVM as it was happening in JDK- 8162461.


Solution : We should have RELEASE_ARRAYS() call in setjmp case for 
writeImage() in imageioJPEG.c.


Thanks,

Jay



Re: [OpenJDK 2D-Dev] Different rounding applied by ProcessPath and ShapeSpanIterator

2016-09-28 Thread Clemens Eisserer
Hi Jim,

> They do operate differently.  They aren't meant to be mixed and matched.

Thanks a lot for the detailed description of the relationship between
SSI and ProcessPath.
I did some further digging as to why the xrender pipeline has issues
with the test attached to the mentioned bug report - because when I
wrote the xrender pipeline the java2d specific code was written with
the OpenGL pipeline used sample - which also mixes SSI with
ProcessPath.

The testcase works fine with D3D/OpenGL, because BufferedRenderPipe
has intrinsics for operations that can be lowered to parallelograms.
As soon as I replace the rectangle with an arc, the OpenGL pipeline
shows alignment issues like xrender. This makes sense, because the
code for draw(SunGraphics2D sg2d, Shape s) and fill(SunGraphics2D
sg2d, Shape s) is quite compareable between xrender and d3d/ogl.

The main culprit seems to be that the test fills with a 3px wide
stroke (-> SSI is used) and later calls draw() with a 1px stroke
(ProcessPath). If the stroke does not change, SSI or ProcessPath are
used consistently for fills and draws - otherwise it can occur that
they are "mixed and matched".

I have to admit I am unsure how to proceed...

Best regards, Clemens


[OpenJDK 2D-Dev] HiDPI support issues on Windows

2016-09-28 Thread Anton Tarasov

Hello,

JDK9 comes with HiDPI support on Windows/Linux which is really great. As 
we gave it a try, we found it looking pretty good with an integer scale 
(2x) but revealed some rendering flaws with float scales.


Let me please demonstrate it with SwingSet2 + JDK9-ea-b137 + Windows 8.1 
in 150% scale (1.5f)


demo1 

Dragging Frame-0 behind the pallet makes the pallet wavy.
Also, as Frame-0 moves it may leave traces.

demo2 

Unstable look of a control. For instance, these two combos are decorated 
differently (and not perfectly).


demo3 

Scrolling traces.

demo4 

Menu traces.
Colored rendering artifacts.

Additionally, I'm attaching a test source & pics kindly provided by 
Renaud (cc'd) from AndroidStudio. The demo finely shows problems on the 
example of primitive rendering.


Scaling 100% 



Scaling 125% 



Scaling 150% 



It seems like most of the mentioned issues are caused by inaccurate 
rounding performed during the rendering cycle.


So, I'd like to ask you please share your thoughts on it. How serious is 
the problem at all (I guess you're aware of it)? What is solvable on the 
JDK side, and what is not (e.g. demo2 and the Renaud's test case)?
Do you have plans to resolve it by jdk9 GA, or earlier/later? Any 
technical details behind it are very welcome as well.


Thanks in advance,
Anton.
/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */
package testscalingrectangles;

import java.awt.*;
import java.awt.event.*;
import java.util.HashMap;
import java.util.Map;
import javax.swing.*;
import javax.swing.border.LineBorder;

public class MinimalSwingApplication {
public static void main(String[] args) {
MinimalSwingApplication app = new MinimalSwingApplication();
app.buildAndDisplayGui();
}

private void buildAndDisplayGui(){
JFrame frame = new JFrame("Test Frame");
frame.setPreferredSize(new Dimension(240, 120));
buildContent(frame);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);
frame.addComponentListener(new ComponentAdapter() {
@Override
public void componentMoved(ComponentEvent e) {
frame.repaint();
}
});
}

private void buildContent(JFrame aFrame){
JButton repaintButton = new JButton();
repaintButton.setText("Repaint");
repaintButton.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
aFrame.repaint();
}
});

JLabel scaleFactorLabel = new JLabel();
JPanel topPanel = new JPanel();
topPanel.setLayout(new BoxLayout(topPanel, BoxLayout.LINE_AXIS));
topPanel.add(new JLabel());
topPanel.add(Box.createHorizontalGlue());
topPanel.add(scaleFactorLabel);
topPanel.add(Box.createHorizontalGlue());
topPanel.add(new JLabel());

JPanel panel = new JPanel(new BorderLayout());
panel.add(topPanel, BorderLayout.NORTH);
panel.add(new MyPanel(scaleFactorLabel), BorderLayout.CENTER);
panel.add(repaintButton, BorderLayout.SOUTH);
aFrame.getContentPane().add(panel);
}

private class MyPanel extends JPanel {
private JLabel myLabel;

public MyPanel(JLabel label) {
super();
myLabel = label;

setLayout(new BoxLayout(this, BoxLayout.LINE_AXIS));
setBorder(new LineBorder(Color.BLUE, 2));

Map renderingHints1 = new HashMap<>();
renderingHints1.put(RenderingHints.KEY_STROKE_CONTROL, 
RenderingHints.VALUE_STROKE_NORMALIZE);
add(new MyPaintRectPanel(renderingHints1));

Map renderingHints2 = new HashMap<>();
renderingHints1.put(RenderingHints.KEY_STROKE_CONTROL, 
RenderingHints.VALUE_STROKE_PURE);
add(new MyPaintRectPanel(renderingHints2));
}

@Override
protected void paintComponent(Graphics g) {
super.paintComponent(g);
if (g instanceof Graphics2D) {
Graphics2D g2d = (Graphics2D)g;
myLabel.setText("Scale=" + (int)(g2d.getTransform().getScaleX() 
* 100) + "%");
}

//int wRect = 5;
//int hRect = 5;
//int xRect0 =