From james.graham at oracle.com Sun Oct 2 19:10:39 2016 From: james.graham at oracle.com (Jim Graham) Date: Sun, 2 Oct 2016 12:10:39 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> References: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> Message-ID: After looking into the code in RepaintManager and re-reading Alexander's message again I can see how it describes what is going on more clearly. Fixing the rounding errors doesn't necessarily require avoiding use of the intermediate image for damage repair, you just have to make sure that you use the incoming xywh as suggestions for what needs to be redrawn, but instead determine exact pixels that you will repaint (usually floor,floor,ceil,ceil to "round out" the area), and then use those pixel-precise locations instead of passing along the integers that came from the repaint requests and hoping for the right rounding. The problem is that a number of the interfaces used by the RepaintManager take integers and hide a scale from the caller so we need to either work around their implicit scale, or possible create internal variants that let us work in pixels. In other words, the typical boilerplate for intermediate image damage repair would be: // repainting x,y,w,h img = make image (w,h) g = img.getGraphics() g.setClip(x,y,w,h) g.translate(-x,-y) component.paint(g) destination.drawImage(img, x,y) but that boilerplate only works if x,y are exact pixel coordinates, but since it is all being doing on a scaled graphics then x,y will transform to arbitrary not-necessarily-integer locations and then all bets are off. Fixing this could either rely on using float interfaces wherever available, or by undoing all of the implicit scales and working in pixels, but being aware of the scale that is required for the destination. Something like one of these boilerplates instead: // repainting x,y,w,h integers using floats float pixelx1 = floor(x * scaleX) float pixely1 = floor(y * scaleY) float pixelx2 = ceil((x+w) * scaleX) float pixely2 = ceil((y+h) * scaleY) int pixelw = (int) (pixelx2 - pixelx1) int pixelh = (int) (pixely2 - pixely1) // Note that the code currently asks the destination to make // a compatible image of a virtual pixel size that is then // scaled to match. A "make me an image of this many pixels" // might be less cumbersome. img = make image (ceil(pixelw / scaleX), ceil(pixelh / scaleY)) g = img.getGraphics() // will be scaled already // The following will use the translate(double, double) method g.setClip(new Rectangle2D.Double(pixel* / scale*)) g.translate(-pixelx1 / scaleX, -pixely1 / scaleY) component.paint(g) // Since there is no drawImage(img, float x, float y)... destination.translate(pixelx1 / scaleX, pixely1 / scaleY) destination.drawImage(img, 0, 0) // (restore transforms where needed) That version uses floating point interfaces in a number of key places (notably translate() calls are available as either int or double in the Graphics and have to use the setClip(Shape) method to specify a floating point rectangle), but a down side is that using those interfaces means that you have a value that you know is at a pixel boundary and you pass it in as "number / scale" only to have the code in the Graphics immediately apply that scale and you end up with the final result of "number / scale * scale" which might incur round-off errors and end up being slightly off of a pixel. In another approach, you could also kill all of the transforms and do it more directly in pixels as in the following: // repainting x,y,w,h integers using unscaled operations // Some parts more cumbersome to undo the implicit scaling // but it won't suffer from round-off errors when constantly // scaling and unscaling through the various interfaces // that have transforms built in int pixelx1 = (int) floor(x * scaleX) int pixely1 = (int) floor(y * scaleY) int pixelx2 = (int) ceil((x+w) * scaleX) int pixely2 = (int) ceil((y+h) * scaleY) int pixelw = pixelx2 - pixelx1; int pixelh = pixely2 - pixely1; // Not sure if there is a mechanism for this since I think // all of the interfaces to get a compatible image are // designed to assume that the caller is not scale-aware. img = make pixel-sized image (pixelw, pixelh) g = img.getGraphics() // assuming that g would be unscaled in this case, but // if g is scaled, then g.setTransform(IDENTITY) // translate by an integer amount, and then scale g.setClip(pixelx1, pixely1, pixelw, pixelh) g.translate(pixelx1, pixely1) g.scale(scaleX, scaleY); component.paint(g) destinationg.setTransform(IDENTITY) destinationg.drawImage(img, pixelx1, pixely1) // (restore transforms where needed) ...jim On 9/30/2016 1:30 PM, Jim Graham wrote: > > > On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote: >> The problem is that the RepaintManager draws a region to a buffered >> image at first and draws the image after that to the >> window. >> Suppose the image has int coordinates and size (x, y, w, h) in the >> user space. It should be drawn into the region with >> coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2). >> If floating point UI scale is used (like 1.5) the region coordinates >> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * >> x2, 1.5 * y2) in the dev space. >> Now these coordinates need to be rounded and the process really >> depends on the evenness or oddness of the start and end >> coordinates. They both can be rounded to one side or to opposite. >> Depending on this some lines near the drawn image >> region can be not filled or just wrongly filled. > > The repaint manager should compute the nearest pixel bounds outside of > the scaled repaint area, and then adjust the rendering to repaint all of > those pixels. You don't "round" here, you "floor,floor,ceil,ceil" (and > then worry how to present the clip region to the app so it can do the > right thing - probably by clipping to a Rect2D.Float() and letting the > integer g.getClipBounds() further round out the coordinates which means > extra paint calls, but at least you'll repaint all the dirty pixels and > they will be blitted to the right destination pixels if the code that > sends them to the screen is aware of the full resolution...) > > ...jim From vitaly.provodin at jetbrains.com Mon Oct 3 08:18:36 2016 From: vitaly.provodin at jetbrains.com (Vitaly Provodin) Date: Mon, 3 Oct 2016 15:18:36 +0700 Subject: [OpenJDK 2D-Dev] Regression test failures - could not find entries in JDK Bug System Message-ID: Hello, My question relates to failures of the Regression tests (jdk/test) on OpenJDK8 and how to identify whether a failure is expected or not. Running java/awt and javax/swing tests against OpenJDK8 on various platforms I got some failures. Trying to find any explanations for these failures I looked through the JDK Bug System and could not find any bugs explaining them, for example, for the following two tests *-java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java* > Failed. > Program > `/Users/builduser/buildAgent/work/13ab0d4c51b0de0b/jbsdk/jdk/Contents/Home/bin/java' > timed out (timeout set to 240000ms, elapsed time was 240786ms). *- javax/swing/JPopupMenu/6800513/bug6800513.java* Failed. > Execution failed: `main' threw exception: java.lang.Exception: popup class > is: javax.swing.PopupFactory$HeavyWeightPopup, expected: > javax.swing.PopupFactory$LightWeightPopup I found out that these tests were excluded from runs against JDK 8 Update Releases Early Access Build (EAB) - see Test Results page at http://download.java.net/openjdk/testresults/8. Please note, I do not know the status of these results, whether they are actual for OpenJDK8 final release or not. Also, I paid attention to that most of the failures I am talking about are not included into jdk/test/ProblemList.txt as for now. Supposing once these tests were excluded from runs, there were some causes for that e.g. some known product or test issues which were not intended to be fixed for this particular release. My question is how can I get to know these causes in order to differentiate expected and unexpected failures - any of these tests, which were excluded from EAB runs because of one issue, may fail because of another. I tried to follow the link at Summary column placed on the page http://download.java.net/openjdk/testresults/9 and could not get information about statuses of the tests (similar to OpenJDK8). So another question, how can I get the list of regression tests (if any) which expectedly fail for some particular OpenJDK release? Thanks, Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 3 15:35:44 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 03 Oct 2016 08:35:44 -0700 Subject: [OpenJDK 2D-Dev] Regression test failures - could not find entries in JDK Bug System In-Reply-To: References: Message-ID: <57F27AD0.70408@oracle.com> This seems to be a question that is not specific to the client tests even if the examples are. And I have no idea about these testresults files So I think that you should instead raise this question on quality-discuss at openjdk.java.net .. -phil. On 10/3/16, 1:18 AM, Vitaly Provodin wrote: > > Hello, > > My question relates to failures of the Regression tests (jdk/test) on > OpenJDK8 and how to identify whether a failure is expected or not. > > Running java/awt and javax/swing tests against OpenJDK8 on various > platforms I got some failures. Trying to find any explanations for > these failures I looked through the JDK Bug System and could not find > any bugs explaining them, for example, for the following two tests > > /-java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java/ > > Failed. > Program > `/Users/builduser/buildAgent/work/13ab0d4c51b0de0b/jbsdk/jdk/Contents/Home/bin/java' > timed out (timeout set to 240000ms, elapsed time was 240786ms). > > /- javax/swing/JPopupMenu/6800513/bug6800513.java/ > > Failed. > Execution failed: `main' threw exception: java.lang.Exception: > popup class is: javax.swing.PopupFactory$HeavyWeightPopup, > expected: javax.swing.PopupFactory$LightWeightPopup > > I found out that these tests were excluded from runs against JDK 8 > Update Releases Early Access Build (EAB) - see Test Results page at > http://download.java.net/openjdk/testresults/8. Please note, I do not > know the status of these results, whether they are actual for OpenJDK8 > final release or not. Also, I paid attention to that most of the > failures I am talking about are not included into > jdk/test/ProblemList.txt as for now. > > Supposing once these tests were excluded from runs, there were some > causes for that e.g. some known product or test issues which were not > intended to be fixed for this particular release. My question is how > can I get to know these causes in order to differentiate expected and > unexpected failures - any of these tests, which were excluded from EAB > runs because of one issue, may fail because of another. > > I tried to follow the link at Summary column placed on the page > http://download.java.net/openjdk/testresults/9 and could not get > information about statuses of the tests (similar to OpenJDK8). So > another question, how can I get the list of regression tests (if any) > which expectedly fail for some particular OpenJDK release? > > Thanks, > > Vitaly > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Oct 3 18:53:24 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Oct 2016 11:53:24 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8165981: Consider making some classes in javax.imageio.plugins.tiff final Message-ID: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> A trivial change, code-wise: --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java @@ -261,7 +261,7 @@ * @see TIFFDirectory * @see TIFFTag */ -public class TIFFField implements Cloneable { +public final class TIFFField implements Cloneable { --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFImageReadParam.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFImageReadParam.java @@ -48,7 +48,7 @@ * * @since 9 */ -public class TIFFImageReadParam extends ImageReadParam { +public final class TIFFImageReadParam extends ImageReadParam { Question is whether TIFFDirectory might be made final as well. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 3 19:44:45 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 3 Oct 2016 12:44:45 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8165981: Consider making some classes in javax.imageio.plugins.tiff final In-Reply-To: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> References: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> Message-ID: <89c6eefe-bfbe-829c-8be6-2900de0cfcc0@oracle.com> Ok to the two you are making final. > Question is whether TIFFDirectory might be made final as well. com.sun.imageio.plugins.tiff.TIFFIFD extends TIFFDirectory so that is more than a case of marking it final. Therefore it at least depends on whether you think that internal subclass really needs to be a subclass ? -phil. On 10/03/2016 11:53 AM, Brian Burkhalter wrote: > A trivial change, code-wise: > > --- > a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java > +++ > b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java > @@ -261,7 +261,7 @@ > * @see TIFFDirectory > * @see TIFFTag > */ > -public class TIFFField implements Cloneable { > +public final class TIFFField implements Cloneable { > > > --- > a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFImageReadParam.java > +++ > b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFImageReadParam.java > @@ -48,7 +48,7 @@ > * > * @since 9 > */ > -public class TIFFImageReadParam extends ImageReadParam { > +public final class TIFFImageReadParam extends ImageReadParam { > > Question is whether TIFFDirectory might be made final as well. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Oct 3 19:51:12 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Oct 2016 12:51:12 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8165981: Consider making some classes in javax.imageio.plugins.tiff final In-Reply-To: <89c6eefe-bfbe-829c-8be6-2900de0cfcc0@oracle.com> References: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> <89c6eefe-bfbe-829c-8be6-2900de0cfcc0@oracle.com> Message-ID: <1D0E5B40-2791-47AC-AF9A-C79154325080@oracle.com> Good point. I think TIFFIFD needs to be a subclass therefore lets leave TIFFDirectory as is. Thanks, Brian On Oct 3, 2016, at 12:44 PM, Phil Race wrote: > > Question is whether TIFFDirectory might be made final as well. > > com.sun.imageio.plugins.tiff.TIFFIFD extends TIFFDirectory so that > is more than a case of marking it final. > Therefore it at least depends on whether you think that internal subclass > really needs to be a subclass ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at jetbrains.com Mon Oct 3 21:41:28 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 4 Oct 2016 00:41:28 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: References: Message-ID: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> Hi Alexandr, I looked at the testcase 8162350 closely and found your explanation below not quite precise... When you repaint a letter with an slightly expanded dirty rect, you've got it as [40-1, 0-1, 80+2, 60+2] = [39, -1, 82, 62]. Let's count only "x". As Jim noted, the code to draw is: // repainting x,y,w,h img = make image (w,h) g = img.getGraphics() g.setClip(x,y,w,h) g.translate(-x,-y) component.paint(g) destination.drawImage(img, x,y) The transformation matrix of "g" is double (AffineTransform.java). So, g.translate(-39) translates to -39*1.5=-58.5. The top-left pixel of the letter [40, 0]=[40*1.5, 0]=[60, 0] thus is painted into x=[60-58.5]=1.5 of the intermediate "img". And I suspect it's eventually not rounded up but is floor'ed to x=1. Then, the "img" is drawn at x=[39]=[39*1.5]=58.5 which I suspect is also eventually floor'ed to x=58. As the result, the top-left pixel of the letter appears at x=[58+1]=59, not at x=60. That's the shift. Not sure if my guess is correct though. The Jim's last suggestion seems to address the problem, as it scales & rounds first and then passes already computed values down. Does the solution affect RepaintManager only? Or I suspect there will be a problem with: // Not sure if there is a mechanism for this since I think // all of the interfaces to get a compatible image are // designed to assume that the caller is not scale-aware. img = make pixel-sized image (pixelw, pixelh) because the comments are true. Thanks, Anton. On 9/30/2016 1:22 PM, Alexandr Scherbatiy wrote: > > Hello Anton, > > Yes, we are working on it. > > For example, there is the known issue DK-8162350 RepaintManager shifts > repainted region when the floating point UI scale is used. > https://bugs.openjdk.java.net/browse/JDK-8162350 > > The problem is that the RepaintManager draws a region to a buffered > image at first and draws the image after that to the window. > Suppose the image has int coordinates and size (x, y, w, h) in the > user space. It should be drawn into the region with coordinates (x, y, > x+width, y+height) = (x1, y1, x2, y2). > If floating point UI scale is used (like 1.5) the region coordinates > are converted to values (1.5 * x1, 1.5 * y1, 1.5 * x2, 1.5 * y2) in > the dev space. > Now these coordinates need to be rounded and the process really > depends on the evenness or oddness of the start and end coordinates. > They both can be rounded to one side or to opposite. Depending on this > some lines near the drawn image region can be not filled or just > wrongly filled. > > If I try to not use a buffered image in the RepaintManager it seems > that some problems are just gone away (internal frame moving artifacts > on the SwingSet2 demo or squares in MinimalSwingApplication are drawn > as squares and not rectangles). > But not all of them. The artifacts during the scrolling in the > SwingSet2 demo still exist. > > I have filled an issue on it just to keep track of them: JDK-8166954 > Drawing artifacts with floating point UI scale > https://bugs.openjdk.java.net/browse/JDK-8166954 > > The another problem which we are working on is that a selected text is > just shifted: 8156217 Selected text is shifted on HiDPI display > https://bugs.openjdk.java.net/browse/JDK-8156217 > > To support this we were needed to add some new API which support > floating point coordinates in the View, TextUI and JTextComponent classes. > The issue is on the review: > http://mail.openjdk.java.net/pipermail/swing-dev/2016-September/006705.html > > Thanks, > Alexandr. > > On 9/28/2016 1:17 PM, Anton Tarasov wrote: >> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at jetbrains.com Mon Oct 3 21:43:08 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 4 Oct 2016 00:43:08 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: References: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> Message-ID: Hi Jim, Thank you for the details! This gives a clue. Anton. On 10/2/2016 10:10 PM, Jim Graham wrote: > After looking into the code in RepaintManager and re-reading > Alexander's message again I can see how it describes what is going on > more clearly. > > Fixing the rounding errors doesn't necessarily require avoiding use of > the intermediate image for damage repair, you just have to make sure > that you use the incoming xywh as suggestions for what needs to be > redrawn, but instead determine exact pixels that you will repaint > (usually floor,floor,ceil,ceil to "round out" the area), and then use > those pixel-precise locations instead of passing along the integers > that came from the repaint requests and hoping for the right > rounding. The problem is that a number of the interfaces used by the > RepaintManager take integers and hide a scale from the caller so we > need to either work around their implicit scale, or possible create > internal variants that let us work in pixels. > > In other words, the typical boilerplate for intermediate image damage > repair would be: > > // repainting x,y,w,h > img = make image (w,h) > g = img.getGraphics() > g.setClip(x,y,w,h) > g.translate(-x,-y) > component.paint(g) > destination.drawImage(img, x,y) > > but that boilerplate only works if x,y are exact pixel coordinates, > but since it is all being doing on a scaled graphics then x,y will > transform to arbitrary not-necessarily-integer locations and then all > bets are off. > > Fixing this could either rely on using float interfaces wherever > available, or by undoing all of the implicit scales and working in > pixels, but being aware of the scale that is required for the > destination. Something like one of these boilerplates instead: > > // repainting x,y,w,h integers using floats > float pixelx1 = floor(x * scaleX) > float pixely1 = floor(y * scaleY) > float pixelx2 = ceil((x+w) * scaleX) > float pixely2 = ceil((y+h) * scaleY) > int pixelw = (int) (pixelx2 - pixelx1) > int pixelh = (int) (pixely2 - pixely1) > // Note that the code currently asks the destination to make > // a compatible image of a virtual pixel size that is then > // scaled to match. A "make me an image of this many pixels" > // might be less cumbersome. > img = make image (ceil(pixelw / scaleX), > ceil(pixelh / scaleY)) > g = img.getGraphics() // will be scaled already > // The following will use the translate(double, double) method > g.setClip(new Rectangle2D.Double(pixel* / scale*)) > g.translate(-pixelx1 / scaleX, -pixely1 / scaleY) > component.paint(g) > // Since there is no drawImage(img, float x, float y)... > destination.translate(pixelx1 / scaleX, pixely1 / scaleY) > destination.drawImage(img, 0, 0) > // (restore transforms where needed) > > That version uses floating point interfaces in a number of key places > (notably translate() calls are available as either int or double in > the Graphics and have to use the setClip(Shape) method to specify a > floating point rectangle), but a down side is that using those > interfaces means that you have a value that you know is at a pixel > boundary and you pass it in as "number / scale" only to have the code > in the Graphics immediately apply that scale and you end up with the > final result of "number / scale * scale" which might incur round-off > errors and end up being slightly off of a pixel. > > In another approach, you could also kill all of the transforms and do > it more directly in pixels as in the following: > > // repainting x,y,w,h integers using unscaled operations > // Some parts more cumbersome to undo the implicit scaling > // but it won't suffer from round-off errors when constantly > // scaling and unscaling through the various interfaces > // that have transforms built in > int pixelx1 = (int) floor(x * scaleX) > int pixely1 = (int) floor(y * scaleY) > int pixelx2 = (int) ceil((x+w) * scaleX) > int pixely2 = (int) ceil((y+h) * scaleY) > int pixelw = pixelx2 - pixelx1; > int pixelh = pixely2 - pixely1; > // Not sure if there is a mechanism for this since I think > // all of the interfaces to get a compatible image are > // designed to assume that the caller is not scale-aware. > img = make pixel-sized image (pixelw, pixelh) > g = img.getGraphics() > // assuming that g would be unscaled in this case, but > // if g is scaled, then g.setTransform(IDENTITY) > // translate by an integer amount, and then scale > g.setClip(pixelx1, pixely1, pixelw, pixelh) > g.translate(pixelx1, pixely1) > g.scale(scaleX, scaleY); > component.paint(g) > destinationg.setTransform(IDENTITY) > destinationg.drawImage(img, pixelx1, pixely1) > // (restore transforms where needed) > > ...jim > > On 9/30/2016 1:30 PM, Jim Graham wrote: >> >> >> On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote: >>> The problem is that the RepaintManager draws a region to a buffered >>> image at first and draws the image after that to the >>> window. >>> Suppose the image has int coordinates and size (x, y, w, h) in the >>> user space. It should be drawn into the region with >>> coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2). >>> If floating point UI scale is used (like 1.5) the region coordinates >>> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * >>> x2, 1.5 * y2) in the dev space. >>> Now these coordinates need to be rounded and the process really >>> depends on the evenness or oddness of the start and end >>> coordinates. They both can be rounded to one side or to opposite. >>> Depending on this some lines near the drawn image >>> region can be not filled or just wrongly filled. >> >> The repaint manager should compute the nearest pixel bounds outside of >> the scaled repaint area, and then adjust the rendering to repaint all of >> those pixels. You don't "round" here, you "floor,floor,ceil,ceil" (and >> then worry how to present the clip region to the app so it can do the >> right thing - probably by clipping to a Rect2D.Float() and letting the >> integer g.getClipBounds() further round out the coordinates which means >> extra paint calls, but at least you'll repaint all the dirty pixels and >> they will be blitted to the right destination pixels if the code that >> sends them to the screen is aware of the full resolution...) >> >> ...jim From james.graham at oracle.com Mon Oct 3 22:05:03 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 3 Oct 2016 15:05:03 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> Message-ID: <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> Hi Anton, Yes, the numbers you are describing are consistent with performing that standard boilerplate using an origin/translate that is not exactly at an integer pixel location. My comments about our mechanisms not allowing for scale-aware allocations can be dealt with in a couple of ways: - Add some internal pixel-based interfaces for scale aware code, like RepaintManager (and consider making them public for applications to use) - Simply ask for a large enough integer to make sure you got the entire clip to fit in it and let the allocator give you an even larger image. It doesn't matter if you paint into a larger image (other than having to allocate an extra row/column on occasion). After that, as long as you set the translates and clip to exact pixel locations within the temp image, you should be fine. You also have to deal with limiting your blit to the destination, probably using drawImage(dxy12, sxy12) variant ...jim On 10/3/2016 2:41 PM, Anton Tarasov wrote: > Hi Alexandr, > > I looked at the testcase 8162350 closely and found your explanation > below not quite precise... > > When you repaint a letter with an slightly expanded dirty rect, you've > got it as [40-1, 0-1, 80+2, 60+2] = [39, -1, 82, 62]. Let's count only "x". > As Jim noted, the code to draw is: > > // repainting x,y,w,h > img = make image (w,h) > g = img.getGraphics() > g.setClip(x,y,w,h) > g.translate(-x,-y) > component.paint(g) > destination.drawImage(img, x,y) > > The transformation matrix of "g" is double (AffineTransform.java). So, > g.translate(-39) translates to -39*1.5=-58.5. The top-left pixel of the > letter [40, 0]=[40*1.5, 0]=[60, 0] thus is painted into x=[60-58.5]=1.5 > of the intermediate "img". And I suspect it's eventually not rounded up > but is floor'ed to x=1. Then, the "img" is drawn at x=[39]=[39*1.5]=58.5 > which I suspect is also eventually floor'ed to x=58. As the result, the > top-left pixel of the letter appears at x=[58+1]=59, not at x=60. That's > the shift. Not sure if my guess is correct though. > > The Jim's last suggestion seems to address the problem, as it scales & > rounds first and then passes already computed values down. Does the > solution affect RepaintManager only? Or I suspect there will be a > problem with: > > // Not sure if there is a mechanism for this since I think > // all of the interfaces to get a compatible image are > // designed to assume that the caller is not scale-aware. > img = make pixel-sized image (pixelw, pixelh) > > because the comments are true. > > Thanks, > Anton. > > On 9/30/2016 1:22 PM, Alexandr Scherbatiy wrote: >> >> Hello Anton, >> >> Yes, we are working on it. >> >> For example, there is the known issue DK-8162350 RepaintManager shifts >> repainted region when the floating point UI scale is used. >> https://bugs.openjdk.java.net/browse/JDK-8162350 >> >> The problem is that the RepaintManager draws a region to a buffered >> image at first and draws the image after that to the window. >> Suppose the image has int coordinates and size (x, y, w, h) in the >> user space. It should be drawn into the region with coordinates (x, y, >> x+width, y+height) = (x1, y1, x2, y2). >> If floating point UI scale is used (like 1.5) the region coordinates >> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * x2, 1.5 * y2) in >> the dev space. >> Now these coordinates need to be rounded and the process really >> depends on the evenness or oddness of the start and end coordinates. >> They both can be rounded to one side or to opposite. Depending on this >> some lines near the drawn image region can be not filled or just >> wrongly filled. >> >> If I try to not use a buffered image in the RepaintManager it seems >> that some problems are just gone away (internal frame moving artifacts >> on the SwingSet2 demo or squares in MinimalSwingApplication are drawn >> as squares and not rectangles). >> But not all of them. The artifacts during the scrolling in the >> SwingSet2 demo still exist. >> >> I have filled an issue on it just to keep track of them: JDK-8166954 >> Drawing artifacts with floating point UI scale >> https://bugs.openjdk.java.net/browse/JDK-8166954 >> >> The another problem which we are working on is that a selected text is >> just shifted: 8156217 Selected text is shifted on HiDPI display >> https://bugs.openjdk.java.net/browse/JDK-8156217 >> >> To support this we were needed to add some new API which support >> floating point coordinates in the View, TextUI and JTextComponent classes. >> The issue is on the review: >> http://mail.openjdk.java.net/pipermail/swing-dev/2016-September/006705.html >> >> Thanks, >> Alexandr. >> >> On 9/28/2016 1:17 PM, Anton Tarasov wrote: >>> 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. >> > From vitaly.provodin at jetbrains.com Tue Oct 4 02:36:46 2016 From: vitaly.provodin at jetbrains.com (Vitaly Provodin) Date: Tue, 4 Oct 2016 09:36:46 +0700 Subject: [OpenJDK 2D-Dev] Regression test failures - could not find entries in JDK Bug System In-Reply-To: <57F27AD0.70408@oracle.com> References: <57F27AD0.70408@oracle.com> Message-ID: <647A634A-52BD-49AF-B693-D87CB08F2AB2@jetbrains.com> Philip, Anyway, thanks for the advise. Thanks, Vitaly > On 03 Oct 2016, at 22:35, Philip Race wrote: > > This seems to be a question that is not specific to the client tests > even if the examples are. And I have no idea about these testresults files > > So I think that you should instead raise this question on > quality-discuss at openjdk.java.net .. > > -phil. > > On 10/3/16, 1:18 AM, Vitaly Provodin wrote: >> >> Hello, >> >> My question relates to failures of the Regression tests (jdk/test) on OpenJDK8 and how to identify whether a failure is expected or not. >> >> Running java/awt and javax/swing tests against OpenJDK8 on various platforms I got some failures. Trying to find any explanations for these failures I looked through the JDK Bug System and could not find any bugs explaining them, for example, for the following two tests >> >> -java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java >> Failed. >> Program `/Users/builduser/buildAgent/work/13ab0d4c51b0de0b/jbsdk/jdk/Contents/Home/bin/java' timed out (timeout set to 240000ms, elapsed time was 240786ms). >> >> - javax/swing/JPopupMenu/6800513/bug6800513.java >> >> Failed. >> Execution failed: `main' threw exception: java.lang.Exception: popup class is: javax.swing.PopupFactory$HeavyWeightPopup, expected: javax.swing.PopupFactory$LightWeightPopup >> >> I found out that these tests were excluded from runs against JDK 8 Update Releases Early Access Build (EAB) - see Test Results page at http://download.java.net/openjdk/testresults/8 . Please note, I do not know the status of these results, whether they are actual for OpenJDK8 final release or not. Also, I paid attention to that most of the failures I am talking about are not included into jdk/test/ProblemList.txt as for now. >> >> Supposing once these tests were excluded from runs, there were some causes for that e.g. some known product or test issues which were not intended to be fixed for this particular release. My question is how can I get to know these causes in order to differentiate expected and unexpected failures - any of these tests, which were excluded from EAB runs because of one issue, may fail because of another. >> >> I tried to follow the link at Summary column placed on the page http://download.java.net/openjdk/testresults/9 and could not get information about statuses of the tests (similar to OpenJDK8). So another question, how can I get the list of regression tests (if any) which expectedly fail for some particular OpenJDK release? >> >> Thanks, >> Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Oct 4 11:39:06 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 4 Oct 2016 04:39:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice Message-ID: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-6294607 Webrev : http://cr.openjdk.java.net/~jdv/6294607/webrev.00/ Issue : When we call ImageWriteParam.getCompressionTypes() for GIF it returns two compression types "LZW" & "lzw". Root cause : Basically we support only LZW compression for GIF. In ImageWriteParam, there are many places in specification where we mention about multiple compression types. In case of GIF, since it returns same compression type twice it would be misleading. Solution : Update GIFImageWriter to return only one compression type string. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Oct 4 16:24:26 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 4 Oct 2016 09:24:26 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice In-Reply-To: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> References: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> Message-ID: This seems fine to me. Perhaps the test could be reworked to look for any plugin that reports a duplicate compression type ? That may be more useful as a test .. Is this the only plugin that exhibits such duplication ? -phil. On 10/04/2016 04:39 AM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience: > > Bug : https://bugs.openjdk.java.net/browse/JDK-6294607 > > Webrev : http://cr.openjdk.java.net/~jdv/6294607/webrev.00/ > > > Issue : When we call ImageWriteParam.getCompressionTypes() for GIF it > returns two compression types ?LZW? & ?lzw?. > > Root cause : Basically we support only LZW compression for GIF. In > ImageWriteParam, there are many places in specification where we > mention about multiple compression types. In case of GIF, since it > returns same compression type twice it would be misleading. > > Solution : Update GIFImageWriter to return only one compression type > string. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at jetbrains.com Tue Oct 4 20:01:55 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 4 Oct 2016 23:01:55 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> Message-ID: <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> Hi Jim, On 10/4/2016 1:05 AM, Jim Graham wrote: > Hi Anton, > > Yes, the numbers you are describing are consistent with performing > that standard boilerplate using an origin/translate that is not > exactly at an integer pixel location. > > My comments about our mechanisms not allowing for scale-aware > allocations can be dealt with in a couple of ways: > > - Add some internal pixel-based interfaces for scale aware code, like > RepaintManager (and consider making them public for applications to use) Ok, that's clear. > > - Simply ask for a large enough integer to make sure you got the > entire clip to fit in it and let the allocator give you an even larger > image. It doesn't matter if you paint into a larger image (other than > having to allocate an extra row/column on occasion). After that, as > long as you set the translates and clip to exact pixel locations > within the temp image, you should be fine. You also have to deal with > limiting your blit to the destination, probably using drawImage(dxy12, > sxy12) variant That's not quite clear, sorry. Are you talking about a scale-aware image? How does its size helps if we still translate/clip? Anyway, I roughly tried your approach mentioned in the previous e-mail, but forcing RM to paint via offscreen BufferedImage, not volatile (just for a quick check). It solved the shift issue of the demo listed in 8162350, which is cool. It also solved the traces of InternalFrame and menu in SwingSet2. Scrolling still traces (I suppose it should be resolved in JViewport/blitting). Also, the problem with primitives rendering (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is still there. But it seems to relate to line-thikness (border-thickness) rounding inaccuracy. What we can do with that?... Thanks, Anton. > > ...jim > > On 10/3/2016 2:41 PM, Anton Tarasov wrote: >> Hi Alexandr, >> >> I looked at the testcase 8162350 closely and found your explanation >> below not quite precise... >> >> When you repaint a letter with an slightly expanded dirty rect, you've >> got it as [40-1, 0-1, 80+2, 60+2] = [39, -1, 82, 62]. Let's count >> only "x". >> As Jim noted, the code to draw is: >> >> // repainting x,y,w,h >> img = make image (w,h) >> g = img.getGraphics() >> g.setClip(x,y,w,h) >> g.translate(-x,-y) >> component.paint(g) >> destination.drawImage(img, x,y) >> >> The transformation matrix of "g" is double (AffineTransform.java). So, >> g.translate(-39) translates to -39*1.5=-58.5. The top-left pixel of the >> letter [40, 0]=[40*1.5, 0]=[60, 0] thus is painted into x=[60-58.5]=1.5 >> of the intermediate "img". And I suspect it's eventually not rounded up >> but is floor'ed to x=1. Then, the "img" is drawn at x=[39]=[39*1.5]=58.5 >> which I suspect is also eventually floor'ed to x=58. As the result, the >> top-left pixel of the letter appears at x=[58+1]=59, not at x=60. That's >> the shift. Not sure if my guess is correct though. >> >> The Jim's last suggestion seems to address the problem, as it scales & >> rounds first and then passes already computed values down. Does the >> solution affect RepaintManager only? Or I suspect there will be a >> problem with: >> >> // Not sure if there is a mechanism for this since I think >> // all of the interfaces to get a compatible image are >> // designed to assume that the caller is not scale-aware. >> img = make pixel-sized image (pixelw, pixelh) >> >> because the comments are true. >> >> Thanks, >> Anton. >> >> On 9/30/2016 1:22 PM, Alexandr Scherbatiy wrote: >>> >>> Hello Anton, >>> >>> Yes, we are working on it. >>> >>> For example, there is the known issue DK-8162350 RepaintManager shifts >>> repainted region when the floating point UI scale is used. >>> https://bugs.openjdk.java.net/browse/JDK-8162350 >>> >>> The problem is that the RepaintManager draws a region to a buffered >>> image at first and draws the image after that to the window. >>> Suppose the image has int coordinates and size (x, y, w, h) in the >>> user space. It should be drawn into the region with coordinates (x, y, >>> x+width, y+height) = (x1, y1, x2, y2). >>> If floating point UI scale is used (like 1.5) the region coordinates >>> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * x2, 1.5 * y2) in >>> the dev space. >>> Now these coordinates need to be rounded and the process really >>> depends on the evenness or oddness of the start and end coordinates. >>> They both can be rounded to one side or to opposite. Depending on this >>> some lines near the drawn image region can be not filled or just >>> wrongly filled. >>> >>> If I try to not use a buffered image in the RepaintManager it seems >>> that some problems are just gone away (internal frame moving artifacts >>> on the SwingSet2 demo or squares in MinimalSwingApplication are drawn >>> as squares and not rectangles). >>> But not all of them. The artifacts during the scrolling in the >>> SwingSet2 demo still exist. >>> >>> I have filled an issue on it just to keep track of them: JDK-8166954 >>> Drawing artifacts with floating point UI scale >>> https://bugs.openjdk.java.net/browse/JDK-8166954 >>> >>> The another problem which we are working on is that a selected text is >>> just shifted: 8156217 Selected text is shifted on HiDPI display >>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>> >>> To support this we were needed to add some new API which support >>> floating point coordinates in the View, TextUI and JTextComponent >>> classes. >>> The issue is on the review: >>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-September/006705.html >>> >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/28/2016 1:17 PM, Anton Tarasov wrote: >>>> 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. >>> >> From james.graham at oracle.com Tue Oct 4 20:22:11 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 4 Oct 2016 13:22:11 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> Message-ID: <3e56c684-3caf-0a18-4d92-fd1df46fb882@oracle.com> On 10/4/16 1:01 PM, Anton Tarasov wrote: >> - Simply ask for a large enough integer to make sure you got the entire clip to fit in it and let the allocator give >> you an even larger image. It doesn't matter if you paint into a larger image (other than having to allocate an extra >> row/column on occasion). After that, as long as you set the translates and clip to exact pixel locations within the >> temp image, you should be fine. You also have to deal with limiting your blit to the destination, probably using >> drawImage(dxy12, sxy12) variant > That's not quite clear, sorry. Are you talking about a scale-aware image? How does its size helps if we still > translate/clip? Usually it isn't an issue if an image allocation mechanism returns a larger-than-necessary image for use as a temp image. In fact, most places that use a temp image will keep an old image around and only reallocate it if it is too small, but reuse it if it is larger than needed. In that case, we don't necessarily need to tell the image allocation mechanisms the exact pixel size of the image we want, we just need to make sure it returns an image with "at least" as many pixels as we need. In that case, while it would be nice to be able to say specifically how many pixels we want, all that we need in a case like RepaintManager is to know what math it is doing so we can name a number that is large enough that it doesn't give us something too small. On the other hand, things like setting the clip and setting the translation on the graphics and blitting the result to the destination - all of those will absolutely need a way for us to be pixel accurate in the numbers we provide... ...jim From james.graham at oracle.com Tue Oct 4 20:28:52 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 4 Oct 2016 13:28:52 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> Message-ID: <879e1396-a8ff-b260-cf99-1c574400ec56@oracle.com> On 10/4/16 1:01 PM, Anton Tarasov wrote: > Anyway, I roughly tried your approach mentioned in the previous e-mail, but forcing RM to paint via offscreen > BufferedImage, not volatile (just for a quick check). > It solved the shift issue of the demo listed in 8162350, which is cool. It also solved the traces of InternalFrame and > menu in SwingSet2. Scrolling still traces (I suppose it should be resolved in JViewport/blitting). > Also, the problem with primitives rendering (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is > still there. But it seems to relate to line-thikness (border-thickness) rounding inaccuracy. What we can do with that?... Yes, blitting is a separate, but related case where pixel-exactness matters. When we scroll a pane we need to scroll it by a precise number of pixels and then paint the newly visible information at a precise pixel location. Solving this aspect might require events to have higher precision data available. We should probably take detailed conversations about the solutions to the bug reports... ...jim From james.graham at oracle.com Tue Oct 4 20:30:34 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 4 Oct 2016 13:30:34 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> Message-ID: <07758c1e-876b-525c-edb3-f9ef3f663994@oracle.com> I wasn't familiar with the test code for this particular case. Is it in a bug report somewhere? ...jim On 10/4/16 1:01 PM, Anton Tarasov wrote: > Also, the problem with primitives rendering (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is > still there. But it seems to relate to line-thikness (border-thickness) rounding inaccuracy. What we can do with that?... From anton.tarasov at jetbrains.com Tue Oct 4 20:46:25 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Tue, 4 Oct 2016 23:46:25 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <07758c1e-876b-525c-edb3-f9ef3f663994@oracle.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <07758c1e-876b-525c-edb3-f9ef3f663994@oracle.com> Message-ID: On 10/4/2016 11:30 PM, Jim Graham wrote: > I wasn't familiar with the test code for this particular case. Is it > in a bug report somewhere? Jim, I'm re-attaching it (it was in my first e-mail). Thanks, Anton. > > ...jim > > On 10/4/16 1:01 PM, Anton Tarasov wrote: >> Also, the problem with primitives rendering >> (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) >> is >> still there. But it seems to relate to line-thikness >> (border-thickness) rounding inaccuracy. What we can do with that?... -------------- next part -------------- /* * 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 = this.getSize().width / 2 - wRect; // int yRect0 = this.getSize().height / 2 - hRect; // int xRect1 = xRect0 + wRect + 1; // int yRect1 = yRect0 + hRect + 1; //myLabel2.setText("X=" + xRect0 + ", Y= " + yRect0); } } private class MyPaintRectPanel extends JPanel { private Map myRenderingHints; public MyPaintRectPanel(Map renderingHints) { myRenderingHints = renderingHints; } @Override protected void paintComponent(Graphics g) { super.paintComponent(g); if (g instanceof Graphics2D) { Graphics2D g2d = (Graphics2D)g; for (RenderingHints.Key key : myRenderingHints.keySet()) { g2d.setRenderingHint(key, myRenderingHints.get(key)); } //((Graphics2D) g).setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); //g2d.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_NORMALIZE); //g2d.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE); } int wRect = 5; int hRect = 5; int xRect0 = this.getSize().width / 2 - wRect; int yRect0 = this.getSize().height / 2 - hRect; int xRect1 = xRect0 + wRect + 1; int yRect1 = yRect0 + hRect + 1; //myLabel.setText("X=" + xRect0 + ", Y= " + yRect0); // Fill the background as RED to illustrate the problem. We are filling // a red rectangle of size (0, 0, w, h * 2 + 1) // This happens` because of the way rounding works in the default transform. // From a API perspective, you would not expect any "red" to remain, since // we cover it up g.setColor(Color.RED); g.fillRect(xRect0, yRect0, wRect * 2 + 1, hRect * 2 + 1); // Draw 4 rectangles g.setColor(Color.PINK); g.fillRect(xRect0, yRect0, wRect, hRect); g.fillRect(xRect1, yRect0, wRect, hRect); g.fillRect(xRect0, yRect1, wRect, hRect); g.fillRect(xRect1, yRect1, wRect, hRect); // Draw borders of 4 rectangles g.setColor(Color.GREEN); g.drawRect(xRect0, yRect0, wRect - 1, hRect - 1); g.drawRect(xRect1, yRect0, wRect - 1, hRect - 1); g.drawRect(xRect0, yRect1, wRect - 1, hRect - 1); g.drawRect(xRect1, yRect1, wRect - 1, hRect - 1); // Draw horiz/vert lines in the middle of the 4 rectangles g.setColor(Color.BLUE); int xMiddle = xRect1 - 1; int yMiddle = yRect1 - 1; g.drawLine(xRect0, yMiddle, xRect0 + wRect * 2, yMiddle); g.drawLine(xMiddle, yRect0, xMiddle, yRect0 + hRect * 2); } } } From Sergey.Bylokhov at oracle.com Tue Oct 4 23:13:08 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Oct 2016 02:13:08 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8165981: Consider making some classes in javax.imageio.plugins.tiff final In-Reply-To: <1D0E5B40-2791-47AC-AF9A-C79154325080@oracle.com> References: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> <89c6eefe-bfbe-829c-8be6-2900de0cfcc0@oracle.com> <1D0E5B40-2791-47AC-AF9A-C79154325080@oracle.com> Message-ID: <8dd572da-d18f-1169-aec7-27bd8fb40b5d@oracle.com> Probably some methods can be made final also (at least setters and getters)? because it always a problem when we validate something in the setter(constructor), but the user returns something unspecified from the overriden getter. On 03.10.16 22:51, Brian Burkhalter wrote: > Good point. I think TIFFIFD needs to be a subclass therefore lets leave > TIFFDirectory as is. > > Thanks, > > Brian > > On Oct 3, 2016, at 12:44 PM, Phil Race > wrote: > >> > Question is whether TIFFDirectory might be made final as well. >> >> com.sun.imageio.plugins.tiff.TIFFIFD extends TIFFDirectory so that >> is more than a case of marking it final. >> Therefore it at least depends on whether you think that internal subclass >> really needs to be a subclass ? > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Wed Oct 5 06:52:30 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 4 Oct 2016 23:52:30 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice In-Reply-To: References: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> Message-ID: <079b9aab-a737-4149-a6d3-d83c95e42dc2@default> Hi Phil, I have verified all plugins only GIF has this duplication problem. Thanks, Jay From: Phil Race Sent: Tuesday, October 04, 2016 9:54 PM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice This seems fine to me. Perhaps the test could be reworked to look for any plugin that reports a duplicate compression type ? That may be more useful as a test .. Is this the only plugin that exhibits such duplication ? -phil. On 10/04/2016 04:39 AM, Jayathirth D V wrote: Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-6294607 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/6294607/webrev.00/"http://cr.openjdk.java.net/~jdv/6294607/webrev.00/ Issue : When we call ImageWriteParam.getCompressionTypes() for GIF it returns two compression types "LZW" & "lzw". Root cause : Basically we support only LZW compression for GIF. In ImageWriteParam, there are many places in specification where we mention about multiple compression types. In case of GIF, since it returns same compression type twice it would be misleading. Solution : Update GIFImageWriter to return only one compression type string. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Oct 5 12:34:47 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Oct 2016 15:34:47 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: References: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> Message-ID: <1e234c83-fbef-563f-c837-5f94e873d512@oracle.com> Looking to this bug I found something new for me. At least rounding of the image is non-intuitive. Usually our animation is a sequence of draw/drawImage+fillRect/clearRect. But in case of fractional scale we transform drawImage and fillRect differently, which can cause some artifacts, because drawImage can fill more pixels than fillRect(even if the clip is set). Some other root of artifacts is a usage of vectors API like drawLine/drawRect, which can produce artifacts outside the component if the clip is incorrectly set and if it set properly such API can produce too thin lines. On 02.10.16 22:10, Jim Graham wrote: > After looking into the code in RepaintManager and re-reading Alexander's > message again I can see how it describes what is going on more clearly. > > Fixing the rounding errors doesn't necessarily require avoiding use of > the intermediate image for damage repair, you just have to make sure > that you use the incoming xywh as suggestions for what needs to be > redrawn, but instead determine exact pixels that you will repaint > (usually floor,floor,ceil,ceil to "round out" the area), and then use > those pixel-precise locations instead of passing along the integers that > came from the repaint requests and hoping for the right rounding. The > problem is that a number of the interfaces used by the RepaintManager > take integers and hide a scale from the caller so we need to either work > around their implicit scale, or possible create internal variants that > let us work in pixels. > > In other words, the typical boilerplate for intermediate image damage > repair would be: > > // repainting x,y,w,h > img = make image (w,h) > g = img.getGraphics() > g.setClip(x,y,w,h) > g.translate(-x,-y) > component.paint(g) > destination.drawImage(img, x,y) > > but that boilerplate only works if x,y are exact pixel coordinates, but > since it is all being doing on a scaled graphics then x,y will transform > to arbitrary not-necessarily-integer locations and then all bets are off. > > Fixing this could either rely on using float interfaces wherever > available, or by undoing all of the implicit scales and working in > pixels, but being aware of the scale that is required for the > destination. Something like one of these boilerplates instead: > > // repainting x,y,w,h integers using floats > float pixelx1 = floor(x * scaleX) > float pixely1 = floor(y * scaleY) > float pixelx2 = ceil((x+w) * scaleX) > float pixely2 = ceil((y+h) * scaleY) > int pixelw = (int) (pixelx2 - pixelx1) > int pixelh = (int) (pixely2 - pixely1) > // Note that the code currently asks the destination to make > // a compatible image of a virtual pixel size that is then > // scaled to match. A "make me an image of this many pixels" > // might be less cumbersome. > img = make image (ceil(pixelw / scaleX), > ceil(pixelh / scaleY)) > g = img.getGraphics() // will be scaled already > // The following will use the translate(double, double) method > g.setClip(new Rectangle2D.Double(pixel* / scale*)) > g.translate(-pixelx1 / scaleX, -pixely1 / scaleY) > component.paint(g) > // Since there is no drawImage(img, float x, float y)... > destination.translate(pixelx1 / scaleX, pixely1 / scaleY) > destination.drawImage(img, 0, 0) > // (restore transforms where needed) > > That version uses floating point interfaces in a number of key places > (notably translate() calls are available as either int or double in the > Graphics and have to use the setClip(Shape) method to specify a floating > point rectangle), but a down side is that using those interfaces means > that you have a value that you know is at a pixel boundary and you pass > it in as "number / scale" only to have the code in the Graphics > immediately apply that scale and you end up with the final result of > "number / scale * scale" which might incur round-off errors and end up > being slightly off of a pixel. > > In another approach, you could also kill all of the transforms and do it > more directly in pixels as in the following: > > // repainting x,y,w,h integers using unscaled operations > // Some parts more cumbersome to undo the implicit scaling > // but it won't suffer from round-off errors when constantly > // scaling and unscaling through the various interfaces > // that have transforms built in > int pixelx1 = (int) floor(x * scaleX) > int pixely1 = (int) floor(y * scaleY) > int pixelx2 = (int) ceil((x+w) * scaleX) > int pixely2 = (int) ceil((y+h) * scaleY) > int pixelw = pixelx2 - pixelx1; > int pixelh = pixely2 - pixely1; > // Not sure if there is a mechanism for this since I think > // all of the interfaces to get a compatible image are > // designed to assume that the caller is not scale-aware. > img = make pixel-sized image (pixelw, pixelh) > g = img.getGraphics() > // assuming that g would be unscaled in this case, but > // if g is scaled, then g.setTransform(IDENTITY) > // translate by an integer amount, and then scale > g.setClip(pixelx1, pixely1, pixelw, pixelh) > g.translate(pixelx1, pixely1) > g.scale(scaleX, scaleY); > component.paint(g) > destinationg.setTransform(IDENTITY) > destinationg.drawImage(img, pixelx1, pixely1) > // (restore transforms where needed) > > ...jim > > On 9/30/2016 1:30 PM, Jim Graham wrote: >> >> >> On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote: >>> The problem is that the RepaintManager draws a region to a buffered >>> image at first and draws the image after that to the >>> window. >>> Suppose the image has int coordinates and size (x, y, w, h) in the >>> user space. It should be drawn into the region with >>> coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2). >>> If floating point UI scale is used (like 1.5) the region coordinates >>> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * >>> x2, 1.5 * y2) in the dev space. >>> Now these coordinates need to be rounded and the process really >>> depends on the evenness or oddness of the start and end >>> coordinates. They both can be rounded to one side or to opposite. >>> Depending on this some lines near the drawn image >>> region can be not filled or just wrongly filled. >> >> The repaint manager should compute the nearest pixel bounds outside of >> the scaled repaint area, and then adjust the rendering to repaint all of >> those pixels. You don't "round" here, you "floor,floor,ceil,ceil" (and >> then worry how to present the clip region to the app so it can do the >> right thing - probably by clipping to a Rect2D.Float() and letting the >> integer g.getClipBounds() further round out the coordinates which means >> extra paint calls, but at least you'll repaint all the dirty pixels and >> they will be blitted to the right destination pixels if the code that >> sends them to the screen is aware of the full resolution...) >> >> ...jim -- Best regards, Sergey. From philip.race at oracle.com Wed Oct 5 16:19:18 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 05 Oct 2016 09:19:18 -0700 Subject: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock. In-Reply-To: <8d8beea3-f191-40c3-b5ac-2ee9c51c8d15@default> References: <588a9a7e-90f0-42a2-b94b-2c5ad1f0f9ec@default> <57E404D6.1090600@oracle.com> <57E55AF1.6030703@oracle.com> <8d8beea3-f191-40c3-b5ac-2ee9c51c8d15@default> Message-ID: <57F52806.8020709@oracle.com> +1 -phil. On 9/29/16, 1:49 AM, Jayathirth D V wrote: > > Hi Phil, > > New changes are submitted in JDK9 under JDK-8166685. > > Please find updated webrev for review in JDK8u: > > http://cr.openjdk.java.net/~jdv/8162461.8u/webrev.01/ > > > I have verified JCK, jtreg and JPRT for updated changes in JDK8u. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Friday, September 23, 2016 10:10 PM > *To:* Jayathirth D V > *Cc:* 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI > up-call made whilst holding JNI critical lock. > > You can't re-use the 9 bug ID in 9. So you will need to create a new > bug to fix > that in 9. > > But for 8u it can be part of this fix .. it would be weird to > knowingly check in > a problem just so you could fix it separately. > > > -phil. > > On 9/23/16, 12:13 AM, Jayathirth D V wrote: > > Hi Phil, > > I assumed setjmp/longjmp functions to be internal error handling > mechanism rather than C standard library functions which provide > non-local jumps. > > I verified setjmp/longjmp usage in ImageIO JPEG context and we > need that RELEASE_ARRAYS() call in writeImage() which I have removed. > > Does I have to create a new Bug and add the RELEASE_ARRAY() call > in writeImage() or I have to check-in this change under > JDK-8162461 only? > > After check-in of this modification I will raise new webrev for 8u > backport. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Thursday, September 22, 2016 9:51 PM > *To:* Jayathirth D V > *Cc:* 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to > JNI up-call made whilst holding JNI critical lock. > > I see this is mostly what I approved for JDK9 but I noticed you > made a change > after I approved it and I did not see or approve the updated version. > I am concerned about this comment you posted for the JDK 9 webrev : > > >Regarding "2856 RELEASE_ARRAYS(env, data, (const JOCTET > *)(dest->next_output_byte));". > >We don't need this RELEASE_ARRAY() call at this place as we have > not yet pinned any buffer. > > So I have removed it. > >Please find updated webrev for review : > >http://cr.openjdk.java.net/~jdv/8162461/webrev.02/ > > > What makes you so sure we have not pinned a buffer by then ? > setjmp is special. It may return from any point in the writing > process. > > In other words that removal looks wrong to me. > > -phil. > > On 9/15/16, 1:29 AM, Jayathirth D V wrote: > > Hi, > > Please review the following backport to JDK-8u from JDK-9 at > your convenience: > > JDK-9 review thread : > http://mail.openjdk.java.net/pipermail/2d-dev/2016-September/007601.html > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8162461 > > JDK-8u Webrev : > http://cr.openjdk.java.net/~jdv/8162461.8u/webrev.00/ > > > Issue : If we try to perform operations like > reader.abort()/reader.dispose()/ reader.reset() in any of the > IIOReadUpdateListener callbacks, JVM will throw deadlock error. > > Root cause : We are making callbacks from native side to Java > by holding some resources in JNI critical lock. > > Solution : We have to release the JNI critical lock on the > resources before we call Java function from native side. If we > have JNI critical lock and we throw an Exception in that case > also we should release the lock. > > I have verified jtreg, JCK and JPRT in JDK8u-dev also. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Wed Oct 5 19:23:59 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 5 Oct 2016 12:23:59 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <1e234c83-fbef-563f-c837-5f94e873d512@oracle.com> References: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> <1e234c83-fbef-563f-c837-5f94e873d512@oracle.com> Message-ID: <20171b04-4411-bc6b-cc24-c4a72db0b1ea@oracle.com> Hi Sergey, I'd be interested in the details of that analysis. Are you saying that drawImage can violate the clip? That would be a big problem if true. I looked at the clip validation code and did spot an issue. When the clip is a Rectangle2D or a transformed Rectangle (which produces an R2D after transformation in some cases), the clip is set from r2d.getBounds() (line 1908 in SG2D) which performs a floor/ceil operation, but it should be governed by the center-of-pixel inclusion rule that governs fills. It should instead be something like: x0 = ceil(r2d.x - 0.5); y0 = ceil(r2d.y - 0.5); x1 = ceil(r2d.getMaxX() - 0.5); y1 = ceil(r2d.getMaxY() - 0.5); (see the code in copyArea for an example of this) We could probably add code like that to the Region class in case it is needed in other places... ...jim On 10/5/16 5:34 AM, Sergey Bylokhov wrote: > Looking to this bug I found something new for me. At least rounding of the image is non-intuitive. Usually our animation > is a sequence of draw/drawImage+fillRect/clearRect. But in case of fractional scale we transform drawImage and fillRect > differently, which can cause some artifacts, because drawImage can fill more pixels than fillRect(even if the clip is set). > > Some other root of artifacts is a usage of vectors API like drawLine/drawRect, which can produce artifacts outside the > component if the clip is incorrectly set and if it set properly such API can produce too thin lines. > > On 02.10.16 22:10, Jim Graham wrote: >> After looking into the code in RepaintManager and re-reading Alexander's >> message again I can see how it describes what is going on more clearly. >> >> Fixing the rounding errors doesn't necessarily require avoiding use of >> the intermediate image for damage repair, you just have to make sure >> that you use the incoming xywh as suggestions for what needs to be >> redrawn, but instead determine exact pixels that you will repaint >> (usually floor,floor,ceil,ceil to "round out" the area), and then use >> those pixel-precise locations instead of passing along the integers that >> came from the repaint requests and hoping for the right rounding. The >> problem is that a number of the interfaces used by the RepaintManager >> take integers and hide a scale from the caller so we need to either work >> around their implicit scale, or possible create internal variants that >> let us work in pixels. >> >> In other words, the typical boilerplate for intermediate image damage >> repair would be: >> >> // repainting x,y,w,h >> img = make image (w,h) >> g = img.getGraphics() >> g.setClip(x,y,w,h) >> g.translate(-x,-y) >> component.paint(g) >> destination.drawImage(img, x,y) >> >> but that boilerplate only works if x,y are exact pixel coordinates, but >> since it is all being doing on a scaled graphics then x,y will transform >> to arbitrary not-necessarily-integer locations and then all bets are off. >> >> Fixing this could either rely on using float interfaces wherever >> available, or by undoing all of the implicit scales and working in >> pixels, but being aware of the scale that is required for the >> destination. Something like one of these boilerplates instead: >> >> // repainting x,y,w,h integers using floats >> float pixelx1 = floor(x * scaleX) >> float pixely1 = floor(y * scaleY) >> float pixelx2 = ceil((x+w) * scaleX) >> float pixely2 = ceil((y+h) * scaleY) >> int pixelw = (int) (pixelx2 - pixelx1) >> int pixelh = (int) (pixely2 - pixely1) >> // Note that the code currently asks the destination to make >> // a compatible image of a virtual pixel size that is then >> // scaled to match. A "make me an image of this many pixels" >> // might be less cumbersome. >> img = make image (ceil(pixelw / scaleX), >> ceil(pixelh / scaleY)) >> g = img.getGraphics() // will be scaled already >> // The following will use the translate(double, double) method >> g.setClip(new Rectangle2D.Double(pixel* / scale*)) >> g.translate(-pixelx1 / scaleX, -pixely1 / scaleY) >> component.paint(g) >> // Since there is no drawImage(img, float x, float y)... >> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >> destination.drawImage(img, 0, 0) >> // (restore transforms where needed) >> >> That version uses floating point interfaces in a number of key places >> (notably translate() calls are available as either int or double in the >> Graphics and have to use the setClip(Shape) method to specify a floating >> point rectangle), but a down side is that using those interfaces means >> that you have a value that you know is at a pixel boundary and you pass >> it in as "number / scale" only to have the code in the Graphics >> immediately apply that scale and you end up with the final result of >> "number / scale * scale" which might incur round-off errors and end up >> being slightly off of a pixel. >> >> In another approach, you could also kill all of the transforms and do it >> more directly in pixels as in the following: >> >> // repainting x,y,w,h integers using unscaled operations >> // Some parts more cumbersome to undo the implicit scaling >> // but it won't suffer from round-off errors when constantly >> // scaling and unscaling through the various interfaces >> // that have transforms built in >> int pixelx1 = (int) floor(x * scaleX) >> int pixely1 = (int) floor(y * scaleY) >> int pixelx2 = (int) ceil((x+w) * scaleX) >> int pixely2 = (int) ceil((y+h) * scaleY) >> int pixelw = pixelx2 - pixelx1; >> int pixelh = pixely2 - pixely1; >> // Not sure if there is a mechanism for this since I think >> // all of the interfaces to get a compatible image are >> // designed to assume that the caller is not scale-aware. >> img = make pixel-sized image (pixelw, pixelh) >> g = img.getGraphics() >> // assuming that g would be unscaled in this case, but >> // if g is scaled, then g.setTransform(IDENTITY) >> // translate by an integer amount, and then scale >> g.setClip(pixelx1, pixely1, pixelw, pixelh) >> g.translate(pixelx1, pixely1) >> g.scale(scaleX, scaleY); >> component.paint(g) >> destinationg.setTransform(IDENTITY) >> destinationg.drawImage(img, pixelx1, pixely1) >> // (restore transforms where needed) >> >> ...jim >> >> On 9/30/2016 1:30 PM, Jim Graham wrote: >>> >>> >>> On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote: >>>> The problem is that the RepaintManager draws a region to a buffered >>>> image at first and draws the image after that to the >>>> window. >>>> Suppose the image has int coordinates and size (x, y, w, h) in the >>>> user space. It should be drawn into the region with >>>> coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2). >>>> If floating point UI scale is used (like 1.5) the region coordinates >>>> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * >>>> x2, 1.5 * y2) in the dev space. >>>> Now these coordinates need to be rounded and the process really >>>> depends on the evenness or oddness of the start and end >>>> coordinates. They both can be rounded to one side or to opposite. >>>> Depending on this some lines near the drawn image >>>> region can be not filled or just wrongly filled. >>> >>> The repaint manager should compute the nearest pixel bounds outside of >>> the scaled repaint area, and then adjust the rendering to repaint all of >>> those pixels. You don't "round" here, you "floor,floor,ceil,ceil" (and >>> then worry how to present the clip region to the app so it can do the >>> right thing - probably by clipping to a Rect2D.Float() and letting the >>> integer g.getClipBounds() further round out the coordinates which means >>> extra paint calls, but at least you'll repaint all the dirty pixels and >>> they will be blitted to the right destination pixels if the code that >>> sends them to the screen is aware of the full resolution...) >>> >>> ...jim > > From philip.race at oracle.com Wed Oct 5 23:05:41 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 05 Oct 2016 16:05:41 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font always displays as regular - no bold or oblique. Message-ID: <57F58745.7000601@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8166034 Non-AA fonts aren't always being bolded on OS X. FWIW I believe this is in part a platform (OS) bug since it is terribly inconsistent across fonts and in some cases even sizes. So we need to look into why but it definitely isn't something that calls for changing the font used by the Motif L&F as proposed here http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006732.html And it calls out something I've seen a few times recently and I've documented some examples in the bug report. So we need to explain in the java.awt.Font spec. that sometimes we are beholden to the limits of the platform. Investigating specific issues then become quality bugs .. but not conformance ones. Added class description text below :- -phil. diff --git a/src/java.desktop/share/classes/java/awt/Font.java b/src/java.desktop/share/classes/java/awt/Font.java --- a/src/java.desktop/share/classes/java/awt/Font.java +++ b/src/java.desktop/share/classes/java/awt/Font.java @@ -154,6 +154,13 @@ * associated with a font face, each differing in size, style, transform * and font features. *

+ * The visual rendering of all, or part of, one logical font vis-a-vis another + * may not always be different where there are limited suitable fonts available. + * The same is true for one style vis-a-vis another. This is generally + * due to one form or another of platform limitation or behavior. + * In the absence of such limitations a compliant implementation + * will render glyphs which exhibit the requested properties. + *

* The {@link GraphicsEnvironment#getAllFonts() getAllFonts} method * of the {@code GraphicsEnvironment} class returns an * array of all font faces available in the system. These font faces are From jayathirth.d.v at oracle.com Thu Oct 6 08:19:22 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 6 Oct 2016 01:19:22 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice In-Reply-To: <079b9aab-a737-4149-a6d3-d83c95e42dc2@default> References: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> <079b9aab-a737-4149-a6d3-d83c95e42dc2@default> Message-ID: <9b21239f-651d-4c00-8a3b-2fe7cc68b147@default> Hi Phil, As discussed offline, I have updated test case to include check for duplication of compression types for all ImageIO plugins. Please review the updated webrev at your convenience : http://cr.openjdk.java.net/~jdv/6294607/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, October 05, 2016 12:23 PM To: Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice Hi Phil, I have verified all plugins only GIF has this duplication problem. Thanks, Jay From: Phil Race Sent: Tuesday, October 04, 2016 9:54 PM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice This seems fine to me. Perhaps the test could be reworked to look for any plugin that reports a duplicate compression type ? That may be more useful as a test .. Is this the only plugin that exhibits such duplication ? -phil. On 10/04/2016 04:39 AM, Jayathirth D V wrote: Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-6294607 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/6294607/webrev.00/"http://cr.openjdk.java.net/~jdv/6294607/webrev.00/ Issue : When we call ImageWriteParam.getCompressionTypes() for GIF it returns two compression types "LZW" & "lzw". Root cause : Basically we support only LZW compression for GIF. In ImageWriteParam, there are many places in specification where we mention about multiple compression types. In case of GIF, since it returns same compression type twice it would be misleading. Solution : Update GIFImageWriter to return only one compression type string. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Thu Oct 6 09:27:21 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 6 Oct 2016 02:27:21 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock. In-Reply-To: <57F52806.8020709@oracle.com> References: <588a9a7e-90f0-42a2-b94b-2c5ad1f0f9ec@default> <57E404D6.1090600@oracle.com> <57E55AF1.6030703@oracle.com> <8d8beea3-f191-40c3-b5ac-2ee9c51c8d15@default> <57F52806.8020709@oracle.com> Message-ID: <0ff476a8-efb9-49e5-87c3-2fbe51623b0c@default> Looks OK to me. Regards, Ajit From: Philip Race Sent: Wednesday, October 05, 2016 9:49 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock. +1 -phil. On 9/29/16, 1:49 AM, Jayathirth D V wrote: Hi Phil, New changes are submitted in JDK9 under JDK-8166685. Please find updated webrev for review in JDK8u: HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8162461.8u/webrev.01/"http://cr.openjdk.java.net/~jdv/8162461.8u/webrev.01/ I have verified JCK, jtreg and JPRT for updated changes in JDK8u. Thanks, Jay From: Philip Race Sent: Friday, September 23, 2016 10:10 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock. You can't re-use the 9 bug ID in 9. So you will need to create a new bug to fix that in 9. But for 8u it can be part of this fix .. it would be weird to knowingly check in a problem just so you could fix it separately. -phil. On 9/23/16, 12:13 AM, Jayathirth D V wrote: Hi Phil, I assumed setjmp/longjmp functions to be internal error handling mechanism rather than C standard library functions which provide non-local jumps. I verified setjmp/longjmp usage in ImageIO JPEG context and we need that RELEASE_ARRAYS() call in writeImage() which I have removed. Does I have to create a new Bug and add the RELEASE_ARRAY() call in writeImage() or I have to check-in this change under JDK-8162461 only? After check-in of this modification I will raise new webrev for 8u backport. Thanks, Jay From: Philip Race Sent: Thursday, September 22, 2016 9:51 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock. I see this is mostly what I approved for JDK9 but I noticed you made a change after I approved it and I did not see or approve the updated version. I am concerned about this comment you posted for the JDK 9 webrev : >Regarding "2856 RELEASE_ARRAYS(env, data, (const JOCTET *)(dest->next_output_byte));". >We don't need this RELEASE_ARRAY() call at this place as we have not yet pinned any buffer. > So I have removed it. >Please find updated webrev for review : >HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8162461/webrev.02/"http://cr.openjdk.java.net/~jdv/8162461/webrev.02/ What makes you so sure we have not pinned a buffer by then ? setjmp is special. It may return from any point in the writing process. In other words that removal looks wrong to me. -phil. On 9/15/16, 1:29 AM, Jayathirth D V wrote: Hi, Please review the following backport to JDK-8u from JDK-9 at your convenience: JDK-9 review thread : http://mail.openjdk.java.net/pipermail/2d-dev/2016-September/007601.html Bug : https://bugs.openjdk.java.net/browse/JDK-8162461 JDK-8u Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8162461.8u/webrev.00/"http://cr.openjdk.java.net/~jdv/8162461.8u/webrev.00/ Issue : If we try to perform operations like reader.abort()/reader.dispose()/ reader.reset() in any of the IIOReadUpdateListener callbacks, JVM will throw deadlock error. Root cause : We are making callbacks from native side to Java by holding some resources in JNI critical lock. Solution : We have to release the JNI critical lock on the resources before we call Java function from native side. If we have JNI critical lock and we throw an Exception in that case also we should release the lock. I have verified jtreg, JCK and JPRT in JDK8u-dev also. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at jetbrains.com Thu Oct 6 09:57:41 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Thu, 6 Oct 2016 12:57:41 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <3e56c684-3caf-0a18-4d92-fd1df46fb882@oracle.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <3e56c684-3caf-0a18-4d92-fd1df46fb882@oracle.com> Message-ID: > On 04 Oct 2016, at 23:22, Jim Graham wrote: > > On 10/4/16 1:01 PM, Anton Tarasov wrote: >>> - Simply ask for a large enough integer to make sure you got the entire clip to fit in it and let the allocator give >>> you an even larger image. It doesn't matter if you paint into a larger image (other than having to allocate an extra >>> row/column on occasion). After that, as long as you set the translates and clip to exact pixel locations within the >>> temp image, you should be fine. You also have to deal with limiting your blit to the destination, probably using >>> drawImage(dxy12, sxy12) variant >> That's not quite clear, sorry. Are you talking about a scale-aware image? How does its size helps if we still >> translate/clip? > > Usually it isn't an issue if an image allocation mechanism returns a larger-than-necessary image for use as a temp image. In fact, most places that use a temp image will keep an old image around and only reallocate it if it is too small, but reuse it if it is larger than needed. > > In that case, we don't necessarily need to tell the image allocation mechanisms the exact pixel size of the image we want, we just need to make sure it returns an image with "at least" as many pixels as we need. In that case, while it would be nice to be able to say specifically how many pixels we want, all that we need in a case like RepaintManager is to know what math it is doing so we can name a number that is large enough that it doesn't give us something too small. Ok, I see, RepaintManager already caches images to perform intermediate drawing. Thanks, Anton. > > On the other hand, things like setting the clip and setting the translation on the graphics and blitting the result to the destination - all of those will absolutely need a way for us to be pixel accurate in the numbers we provide... > > ...jim From anton.tarasov at jetbrains.com Thu Oct 6 10:11:56 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Thu, 6 Oct 2016 13:11:56 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <879e1396-a8ff-b260-cf99-1c574400ec56@oracle.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <879e1396-a8ff-b260-cf99-1c574400ec56@oracle.com> Message-ID: <44A09AC9-77C5-4E44-83F9-8AA26D7AF1AC@jetbrains.com> Hi all, On 04 Oct 2016, at 23:28, Jim Graham wrote: > > On 10/4/16 1:01 PM, Anton Tarasov wrote: >> Anyway, I roughly tried your approach mentioned in the previous e-mail, but forcing RM to paint via offscreen >> BufferedImage, not volatile (just for a quick check). >> It solved the shift issue of the demo listed in 8162350, which is cool. It also solved the traces of InternalFrame and >> menu in SwingSet2. Scrolling still traces (I suppose it should be resolved in JViewport/blitting). >> Also, the problem with primitives rendering (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is >> still there. But it seems to relate to line-thikness (border-thickness) rounding inaccuracy. What we can do with that?... > > Yes, blitting is a separate, but related case where pixel-exactness matters. When we scroll a pane we need to scroll it by a precise number of pixels and then paint the newly visible information at a precise pixel location. Solving this aspect might require events to have higher precision data available. > > We should probably take detailed conversations about the solutions to the bug reports? What do you think, is it possible to address the mentioned issues in jdk9, not deferring them? The new HiDPI support will affect all the users having fractional scale screens... Thanks, Anton. From Sergey.Bylokhov at oracle.com Thu Oct 6 13:02:02 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 6 Oct 2016 16:02:02 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <20171b04-4411-bc6b-cc24-c4a72db0b1ea@oracle.com> References: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> <1e234c83-fbef-563f-c837-5f94e873d512@oracle.com> <20171b04-4411-bc6b-cc24-c4a72db0b1ea@oracle.com> Message-ID: <21585f66-d63b-bd6c-cbc2-42892c98999b@oracle.com> hi, Jim. Can you please take a look to the small example(attached) which was created by Alex. The test uses 3 operations: fillRect, drawImage, drawRect. Each time we draw something to the left rectangle [0,0,w,h] and to the right rectangle[w,0,w,h]. I can understand why fillrect draw the shapes one after another, w/o overlapping and gaps. I also understand why results of drawRect are overlaps, sine w,h is a middle of the line. But why the images are overlapped? So results on the screen will be depending on what image was painted last time. Note that the clip is set for both images, but this does not help. Also the clips cannot prevent overlapping of drawrect(I guess it should). On 05.10.16 22:23, Jim Graham wrote: > Hi Sergey, > > I'd be interested in the details of that analysis. Are you saying that > drawImage can violate the clip? That would be a big problem if true. > > I looked at the clip validation code and did spot an issue. When the > clip is a Rectangle2D or a transformed Rectangle (which produces an R2D > after transformation in some cases), the clip is set from > r2d.getBounds() (line 1908 in SG2D) which performs a floor/ceil > operation, but it should be governed by the center-of-pixel inclusion > rule that governs fills. It should instead be something like: > > x0 = ceil(r2d.x - 0.5); > y0 = ceil(r2d.y - 0.5); > x1 = ceil(r2d.getMaxX() - 0.5); > y1 = ceil(r2d.getMaxY() - 0.5); > (see the code in copyArea for an example of this) > > We could probably add code like that to the Region class in case it is > needed in other places... > > ...jim > > On 10/5/16 5:34 AM, Sergey Bylokhov wrote: >> Looking to this bug I found something new for me. At least rounding of >> the image is non-intuitive. Usually our animation >> is a sequence of draw/drawImage+fillRect/clearRect. But in case of >> fractional scale we transform drawImage and fillRect >> differently, which can cause some artifacts, because drawImage can >> fill more pixels than fillRect(even if the clip is set). >> >> Some other root of artifacts is a usage of vectors API like >> drawLine/drawRect, which can produce artifacts outside the >> component if the clip is incorrectly set and if it set properly such >> API can produce too thin lines. >> >> On 02.10.16 22:10, Jim Graham wrote: >>> After looking into the code in RepaintManager and re-reading Alexander's >>> message again I can see how it describes what is going on more clearly. >>> >>> Fixing the rounding errors doesn't necessarily require avoiding use of >>> the intermediate image for damage repair, you just have to make sure >>> that you use the incoming xywh as suggestions for what needs to be >>> redrawn, but instead determine exact pixels that you will repaint >>> (usually floor,floor,ceil,ceil to "round out" the area), and then use >>> those pixel-precise locations instead of passing along the integers that >>> came from the repaint requests and hoping for the right rounding. The >>> problem is that a number of the interfaces used by the RepaintManager >>> take integers and hide a scale from the caller so we need to either work >>> around their implicit scale, or possible create internal variants that >>> let us work in pixels. >>> >>> In other words, the typical boilerplate for intermediate image damage >>> repair would be: >>> >>> // repainting x,y,w,h >>> img = make image (w,h) >>> g = img.getGraphics() >>> g.setClip(x,y,w,h) >>> g.translate(-x,-y) >>> component.paint(g) >>> destination.drawImage(img, x,y) >>> >>> but that boilerplate only works if x,y are exact pixel coordinates, but >>> since it is all being doing on a scaled graphics then x,y will transform >>> to arbitrary not-necessarily-integer locations and then all bets are >>> off. >>> >>> Fixing this could either rely on using float interfaces wherever >>> available, or by undoing all of the implicit scales and working in >>> pixels, but being aware of the scale that is required for the >>> destination. Something like one of these boilerplates instead: >>> >>> // repainting x,y,w,h integers using floats >>> float pixelx1 = floor(x * scaleX) >>> float pixely1 = floor(y * scaleY) >>> float pixelx2 = ceil((x+w) * scaleX) >>> float pixely2 = ceil((y+h) * scaleY) >>> int pixelw = (int) (pixelx2 - pixelx1) >>> int pixelh = (int) (pixely2 - pixely1) >>> // Note that the code currently asks the destination to make >>> // a compatible image of a virtual pixel size that is then >>> // scaled to match. A "make me an image of this many pixels" >>> // might be less cumbersome. >>> img = make image (ceil(pixelw / scaleX), >>> ceil(pixelh / scaleY)) >>> g = img.getGraphics() // will be scaled already >>> // The following will use the translate(double, double) method >>> g.setClip(new Rectangle2D.Double(pixel* / scale*)) >>> g.translate(-pixelx1 / scaleX, -pixely1 / scaleY) >>> component.paint(g) >>> // Since there is no drawImage(img, float x, float y)... >>> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >>> destination.drawImage(img, 0, 0) >>> // (restore transforms where needed) >>> >>> That version uses floating point interfaces in a number of key places >>> (notably translate() calls are available as either int or double in the >>> Graphics and have to use the setClip(Shape) method to specify a floating >>> point rectangle), but a down side is that using those interfaces means >>> that you have a value that you know is at a pixel boundary and you pass >>> it in as "number / scale" only to have the code in the Graphics >>> immediately apply that scale and you end up with the final result of >>> "number / scale * scale" which might incur round-off errors and end up >>> being slightly off of a pixel. >>> >>> In another approach, you could also kill all of the transforms and do it >>> more directly in pixels as in the following: >>> >>> // repainting x,y,w,h integers using unscaled operations >>> // Some parts more cumbersome to undo the implicit scaling >>> // but it won't suffer from round-off errors when constantly >>> // scaling and unscaling through the various interfaces >>> // that have transforms built in >>> int pixelx1 = (int) floor(x * scaleX) >>> int pixely1 = (int) floor(y * scaleY) >>> int pixelx2 = (int) ceil((x+w) * scaleX) >>> int pixely2 = (int) ceil((y+h) * scaleY) >>> int pixelw = pixelx2 - pixelx1; >>> int pixelh = pixely2 - pixely1; >>> // Not sure if there is a mechanism for this since I think >>> // all of the interfaces to get a compatible image are >>> // designed to assume that the caller is not scale-aware. >>> img = make pixel-sized image (pixelw, pixelh) >>> g = img.getGraphics() >>> // assuming that g would be unscaled in this case, but >>> // if g is scaled, then g.setTransform(IDENTITY) >>> // translate by an integer amount, and then scale >>> g.setClip(pixelx1, pixely1, pixelw, pixelh) >>> g.translate(pixelx1, pixely1) >>> g.scale(scaleX, scaleY); >>> component.paint(g) >>> destinationg.setTransform(IDENTITY) >>> destinationg.drawImage(img, pixelx1, pixely1) >>> // (restore transforms where needed) >>> >>> ...jim >>> >>> On 9/30/2016 1:30 PM, Jim Graham wrote: >>>> >>>> >>>> On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote: >>>>> The problem is that the RepaintManager draws a region to a buffered >>>>> image at first and draws the image after that to the >>>>> window. >>>>> Suppose the image has int coordinates and size (x, y, w, h) in the >>>>> user space. It should be drawn into the region with >>>>> coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2). >>>>> If floating point UI scale is used (like 1.5) the region coordinates >>>>> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * >>>>> x2, 1.5 * y2) in the dev space. >>>>> Now these coordinates need to be rounded and the process really >>>>> depends on the evenness or oddness of the start and end >>>>> coordinates. They both can be rounded to one side or to opposite. >>>>> Depending on this some lines near the drawn image >>>>> region can be not filled or just wrongly filled. >>>> >>>> The repaint manager should compute the nearest pixel bounds outside of >>>> the scaled repaint area, and then adjust the rendering to repaint >>>> all of >>>> those pixels. You don't "round" here, you "floor,floor,ceil,ceil" (and >>>> then worry how to present the clip region to the app so it can do the >>>> right thing - probably by clipping to a Rect2D.Float() and letting the >>>> integer g.getClipBounds() further round out the coordinates which means >>>> extra paint calls, but at least you'll repaint all the dirty pixels and >>>> they will be blitted to the right destination pixels if the code that >>>> sends them to the screen is aware of the full resolution...) >>>> >>>> ...jim >> >> -- Best regards, Sergey. -------------- next part -------------- import java.awt.Color; import java.awt.Graphics2D; import java.awt.image.BufferedImage; import java.io.File; import javax.imageio.ImageIO; public final class FPDrawImageTest { static final Color LEFT_COLOR = new Color(255, 0, 0, 100); static final Color RIGHT_COLOR = new Color(0, 0, 255, 100); public static void main(final String[] args) throws Exception { int w = 7; int h = 7; // Init image BufferedImage img = new BufferedImage(70, 70, BufferedImage.TYPE_INT_ARGB); Graphics2D g = img.createGraphics(); g.setColor(Color.WHITE); g.fillRect(0, 0, img.getWidth(), img.getHeight()); //g.scale(1, 1); g.scale(1.5, 1.5); // FillRect g.setColor(LEFT_COLOR); g.fillRect(0, 0, w, h); g.setColor(RIGHT_COLOR); g.fillRect(w, 0, w, h); // MoveTo the next line g.translate(0, h + 3); // DrawImage BufferedImage img1 = createImage(w, h, LEFT_COLOR); g.setClip(0, 0, w, h); g.drawImage(img1, 0, 0, null); BufferedImage img2 = createImage(w, h, RIGHT_COLOR); g.setClip(w, 0, w, h); g.drawImage(img2, w, 0, null); g.setClip(null); // MoveTo the next line g.translate(0, h + 3); // DrawRect g.setColor(LEFT_COLOR); g.setClip(0, 0, w, h); g.drawRect(0, 0, w, h); g.setColor(RIGHT_COLOR); g.setClip(w, 0, w, h); g.drawRect(w, 0, w, h); g.dispose(); ImageIO.write(img, "png", new File("two-images-clip-s150.png")); } private static BufferedImage createImage(int w, int h, Color c1) { BufferedImage img = new BufferedImage(w, h, BufferedImage.TYPE_INT_ARGB); Graphics2D g = img.createGraphics(); g.setColor(c1); g.fillRect(0, 0, w, h); return img; } } From Sergey.Bylokhov at oracle.com Thu Oct 6 13:24:26 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 6 Oct 2016 16:24:26 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <21585f66-d63b-bd6c-cbc2-42892c98999b@oracle.com> References: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> <1e234c83-fbef-563f-c837-5f94e873d512@oracle.com> <20171b04-4411-bc6b-cc24-c4a72db0b1ea@oracle.com> <21585f66-d63b-bd6c-cbc2-42892c98999b@oracle.com> Message-ID: Immediately after I sent a message I realized that we had similar discussion about clip already. It seems this is the same bug as discussed here: http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html And those solution fix this bug as well. I will file a separate bug and send a review request soon. On 06.10.16 16:02, Sergey Bylokhov wrote: > hi, Jim. > Can you please take a look to the small example(attached) which was > created by Alex. > The test uses 3 operations: fillRect, drawImage, drawRect. > Each time we draw something to the left rectangle [0,0,w,h] and to the > right rectangle[w,0,w,h]. > I can understand why fillrect draw the shapes one after another, w/o > overlapping and gaps. > I also understand why results of drawRect are overlaps, sine w,h is a > middle of the line. > > But why the images are overlapped? So results on the screen will be > depending on what image was painted last time. Note that the clip is set > for both images, but this does not help. Also the clips cannot prevent > overlapping of drawrect(I guess it should). > > > On 05.10.16 22:23, Jim Graham wrote: >> Hi Sergey, >> >> I'd be interested in the details of that analysis. Are you saying that >> drawImage can violate the clip? That would be a big problem if true. >> >> I looked at the clip validation code and did spot an issue. When the >> clip is a Rectangle2D or a transformed Rectangle (which produces an R2D >> after transformation in some cases), the clip is set from >> r2d.getBounds() (line 1908 in SG2D) which performs a floor/ceil >> operation, but it should be governed by the center-of-pixel inclusion >> rule that governs fills. It should instead be something like: >> >> x0 = ceil(r2d.x - 0.5); >> y0 = ceil(r2d.y - 0.5); >> x1 = ceil(r2d.getMaxX() - 0.5); >> y1 = ceil(r2d.getMaxY() - 0.5); >> (see the code in copyArea for an example of this) >> >> We could probably add code like that to the Region class in case it is >> needed in other places... >> >> ...jim >> >> On 10/5/16 5:34 AM, Sergey Bylokhov wrote: >>> Looking to this bug I found something new for me. At least rounding of >>> the image is non-intuitive. Usually our animation >>> is a sequence of draw/drawImage+fillRect/clearRect. But in case of >>> fractional scale we transform drawImage and fillRect >>> differently, which can cause some artifacts, because drawImage can >>> fill more pixels than fillRect(even if the clip is set). >>> >>> Some other root of artifacts is a usage of vectors API like >>> drawLine/drawRect, which can produce artifacts outside the >>> component if the clip is incorrectly set and if it set properly such >>> API can produce too thin lines. >>> >>> On 02.10.16 22:10, Jim Graham wrote: >>>> After looking into the code in RepaintManager and re-reading >>>> Alexander's >>>> message again I can see how it describes what is going on more clearly. >>>> >>>> Fixing the rounding errors doesn't necessarily require avoiding use of >>>> the intermediate image for damage repair, you just have to make sure >>>> that you use the incoming xywh as suggestions for what needs to be >>>> redrawn, but instead determine exact pixels that you will repaint >>>> (usually floor,floor,ceil,ceil to "round out" the area), and then use >>>> those pixel-precise locations instead of passing along the integers >>>> that >>>> came from the repaint requests and hoping for the right rounding. The >>>> problem is that a number of the interfaces used by the RepaintManager >>>> take integers and hide a scale from the caller so we need to either >>>> work >>>> around their implicit scale, or possible create internal variants that >>>> let us work in pixels. >>>> >>>> In other words, the typical boilerplate for intermediate image damage >>>> repair would be: >>>> >>>> // repainting x,y,w,h >>>> img = make image (w,h) >>>> g = img.getGraphics() >>>> g.setClip(x,y,w,h) >>>> g.translate(-x,-y) >>>> component.paint(g) >>>> destination.drawImage(img, x,y) >>>> >>>> but that boilerplate only works if x,y are exact pixel coordinates, but >>>> since it is all being doing on a scaled graphics then x,y will >>>> transform >>>> to arbitrary not-necessarily-integer locations and then all bets are >>>> off. >>>> >>>> Fixing this could either rely on using float interfaces wherever >>>> available, or by undoing all of the implicit scales and working in >>>> pixels, but being aware of the scale that is required for the >>>> destination. Something like one of these boilerplates instead: >>>> >>>> // repainting x,y,w,h integers using floats >>>> float pixelx1 = floor(x * scaleX) >>>> float pixely1 = floor(y * scaleY) >>>> float pixelx2 = ceil((x+w) * scaleX) >>>> float pixely2 = ceil((y+h) * scaleY) >>>> int pixelw = (int) (pixelx2 - pixelx1) >>>> int pixelh = (int) (pixely2 - pixely1) >>>> // Note that the code currently asks the destination to make >>>> // a compatible image of a virtual pixel size that is then >>>> // scaled to match. A "make me an image of this many pixels" >>>> // might be less cumbersome. >>>> img = make image (ceil(pixelw / scaleX), >>>> ceil(pixelh / scaleY)) >>>> g = img.getGraphics() // will be scaled already >>>> // The following will use the translate(double, double) method >>>> g.setClip(new Rectangle2D.Double(pixel* / scale*)) >>>> g.translate(-pixelx1 / scaleX, -pixely1 / scaleY) >>>> component.paint(g) >>>> // Since there is no drawImage(img, float x, float y)... >>>> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >>>> destination.drawImage(img, 0, 0) >>>> // (restore transforms where needed) >>>> >>>> That version uses floating point interfaces in a number of key places >>>> (notably translate() calls are available as either int or double in the >>>> Graphics and have to use the setClip(Shape) method to specify a >>>> floating >>>> point rectangle), but a down side is that using those interfaces means >>>> that you have a value that you know is at a pixel boundary and you pass >>>> it in as "number / scale" only to have the code in the Graphics >>>> immediately apply that scale and you end up with the final result of >>>> "number / scale * scale" which might incur round-off errors and end up >>>> being slightly off of a pixel. >>>> >>>> In another approach, you could also kill all of the transforms and >>>> do it >>>> more directly in pixels as in the following: >>>> >>>> // repainting x,y,w,h integers using unscaled operations >>>> // Some parts more cumbersome to undo the implicit scaling >>>> // but it won't suffer from round-off errors when constantly >>>> // scaling and unscaling through the various interfaces >>>> // that have transforms built in >>>> int pixelx1 = (int) floor(x * scaleX) >>>> int pixely1 = (int) floor(y * scaleY) >>>> int pixelx2 = (int) ceil((x+w) * scaleX) >>>> int pixely2 = (int) ceil((y+h) * scaleY) >>>> int pixelw = pixelx2 - pixelx1; >>>> int pixelh = pixely2 - pixely1; >>>> // Not sure if there is a mechanism for this since I think >>>> // all of the interfaces to get a compatible image are >>>> // designed to assume that the caller is not scale-aware. >>>> img = make pixel-sized image (pixelw, pixelh) >>>> g = img.getGraphics() >>>> // assuming that g would be unscaled in this case, but >>>> // if g is scaled, then g.setTransform(IDENTITY) >>>> // translate by an integer amount, and then scale >>>> g.setClip(pixelx1, pixely1, pixelw, pixelh) >>>> g.translate(pixelx1, pixely1) >>>> g.scale(scaleX, scaleY); >>>> component.paint(g) >>>> destinationg.setTransform(IDENTITY) >>>> destinationg.drawImage(img, pixelx1, pixely1) >>>> // (restore transforms where needed) >>>> >>>> ...jim >>>> >>>> On 9/30/2016 1:30 PM, Jim Graham wrote: >>>>> >>>>> >>>>> On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote: >>>>>> The problem is that the RepaintManager draws a region to a buffered >>>>>> image at first and draws the image after that to the >>>>>> window. >>>>>> Suppose the image has int coordinates and size (x, y, w, h) in the >>>>>> user space. It should be drawn into the region with >>>>>> coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2). >>>>>> If floating point UI scale is used (like 1.5) the region coordinates >>>>>> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * >>>>>> x2, 1.5 * y2) in the dev space. >>>>>> Now these coordinates need to be rounded and the process really >>>>>> depends on the evenness or oddness of the start and end >>>>>> coordinates. They both can be rounded to one side or to opposite. >>>>>> Depending on this some lines near the drawn image >>>>>> region can be not filled or just wrongly filled. >>>>> >>>>> The repaint manager should compute the nearest pixel bounds outside of >>>>> the scaled repaint area, and then adjust the rendering to repaint >>>>> all of >>>>> those pixels. You don't "round" here, you "floor,floor,ceil,ceil" >>>>> (and >>>>> then worry how to present the clip region to the app so it can do the >>>>> right thing - probably by clipping to a Rect2D.Float() and letting the >>>>> integer g.getClipBounds() further round out the coordinates which >>>>> means >>>>> extra paint calls, but at least you'll repaint all the dirty pixels >>>>> and >>>>> they will be blitted to the right destination pixels if the code that >>>>> sends them to the screen is aware of the full resolution...) >>>>> >>>>> ...jim >>> >>> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Oct 6 13:44:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 6 Oct 2016 16:44:43 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: References: <38cfa226-bf2a-a2c3-7bf1-5727c87256dc@oracle.com> <1e234c83-fbef-563f-c837-5f94e873d512@oracle.com> <20171b04-4411-bc6b-cc24-c4a72db0b1ea@oracle.com> <21585f66-d63b-bd6c-cbc2-42892c98999b@oracle.com> Message-ID: On 06.10.16 16:24, Sergey Bylokhov wrote: > Immediately after I sent a message I realized that we had similar > discussion about clip already. > It seems this is the same bug as discussed here: > http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html > > And those solution fix this bug as well. I will file a separate bug and > send a review request soon. But I still have a question is it correct behavior that the images are overlapped w/o clip? (since fillRect works as expected w/o clip) > > On 06.10.16 16:02, Sergey Bylokhov wrote: >> hi, Jim. >> Can you please take a look to the small example(attached) which was >> created by Alex. >> The test uses 3 operations: fillRect, drawImage, drawRect. >> Each time we draw something to the left rectangle [0,0,w,h] and to the >> right rectangle[w,0,w,h]. >> I can understand why fillrect draw the shapes one after another, w/o >> overlapping and gaps. >> I also understand why results of drawRect are overlaps, sine w,h is a >> middle of the line. >> >> But why the images are overlapped? So results on the screen will be >> depending on what image was painted last time. Note that the clip is set >> for both images, but this does not help. Also the clips cannot prevent >> overlapping of drawrect(I guess it should). >> >> >> On 05.10.16 22:23, Jim Graham wrote: >>> Hi Sergey, >>> >>> I'd be interested in the details of that analysis. Are you saying that >>> drawImage can violate the clip? That would be a big problem if true. >>> >>> I looked at the clip validation code and did spot an issue. When the >>> clip is a Rectangle2D or a transformed Rectangle (which produces an R2D >>> after transformation in some cases), the clip is set from >>> r2d.getBounds() (line 1908 in SG2D) which performs a floor/ceil >>> operation, but it should be governed by the center-of-pixel inclusion >>> rule that governs fills. It should instead be something like: >>> >>> x0 = ceil(r2d.x - 0.5); >>> y0 = ceil(r2d.y - 0.5); >>> x1 = ceil(r2d.getMaxX() - 0.5); >>> y1 = ceil(r2d.getMaxY() - 0.5); >>> (see the code in copyArea for an example of this) >>> >>> We could probably add code like that to the Region class in case it is >>> needed in other places... >>> >>> ...jim >>> >>> On 10/5/16 5:34 AM, Sergey Bylokhov wrote: >>>> Looking to this bug I found something new for me. At least rounding of >>>> the image is non-intuitive. Usually our animation >>>> is a sequence of draw/drawImage+fillRect/clearRect. But in case of >>>> fractional scale we transform drawImage and fillRect >>>> differently, which can cause some artifacts, because drawImage can >>>> fill more pixels than fillRect(even if the clip is set). >>>> >>>> Some other root of artifacts is a usage of vectors API like >>>> drawLine/drawRect, which can produce artifacts outside the >>>> component if the clip is incorrectly set and if it set properly such >>>> API can produce too thin lines. >>>> >>>> On 02.10.16 22:10, Jim Graham wrote: >>>>> After looking into the code in RepaintManager and re-reading >>>>> Alexander's >>>>> message again I can see how it describes what is going on more >>>>> clearly. >>>>> >>>>> Fixing the rounding errors doesn't necessarily require avoiding use of >>>>> the intermediate image for damage repair, you just have to make sure >>>>> that you use the incoming xywh as suggestions for what needs to be >>>>> redrawn, but instead determine exact pixels that you will repaint >>>>> (usually floor,floor,ceil,ceil to "round out" the area), and then use >>>>> those pixel-precise locations instead of passing along the integers >>>>> that >>>>> came from the repaint requests and hoping for the right rounding. The >>>>> problem is that a number of the interfaces used by the RepaintManager >>>>> take integers and hide a scale from the caller so we need to either >>>>> work >>>>> around their implicit scale, or possible create internal variants that >>>>> let us work in pixels. >>>>> >>>>> In other words, the typical boilerplate for intermediate image damage >>>>> repair would be: >>>>> >>>>> // repainting x,y,w,h >>>>> img = make image (w,h) >>>>> g = img.getGraphics() >>>>> g.setClip(x,y,w,h) >>>>> g.translate(-x,-y) >>>>> component.paint(g) >>>>> destination.drawImage(img, x,y) >>>>> >>>>> but that boilerplate only works if x,y are exact pixel coordinates, >>>>> but >>>>> since it is all being doing on a scaled graphics then x,y will >>>>> transform >>>>> to arbitrary not-necessarily-integer locations and then all bets are >>>>> off. >>>>> >>>>> Fixing this could either rely on using float interfaces wherever >>>>> available, or by undoing all of the implicit scales and working in >>>>> pixels, but being aware of the scale that is required for the >>>>> destination. Something like one of these boilerplates instead: >>>>> >>>>> // repainting x,y,w,h integers using floats >>>>> float pixelx1 = floor(x * scaleX) >>>>> float pixely1 = floor(y * scaleY) >>>>> float pixelx2 = ceil((x+w) * scaleX) >>>>> float pixely2 = ceil((y+h) * scaleY) >>>>> int pixelw = (int) (pixelx2 - pixelx1) >>>>> int pixelh = (int) (pixely2 - pixely1) >>>>> // Note that the code currently asks the destination to make >>>>> // a compatible image of a virtual pixel size that is then >>>>> // scaled to match. A "make me an image of this many pixels" >>>>> // might be less cumbersome. >>>>> img = make image (ceil(pixelw / scaleX), >>>>> ceil(pixelh / scaleY)) >>>>> g = img.getGraphics() // will be scaled already >>>>> // The following will use the translate(double, double) method >>>>> g.setClip(new Rectangle2D.Double(pixel* / scale*)) >>>>> g.translate(-pixelx1 / scaleX, -pixely1 / scaleY) >>>>> component.paint(g) >>>>> // Since there is no drawImage(img, float x, float y)... >>>>> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >>>>> destination.drawImage(img, 0, 0) >>>>> // (restore transforms where needed) >>>>> >>>>> That version uses floating point interfaces in a number of key places >>>>> (notably translate() calls are available as either int or double in >>>>> the >>>>> Graphics and have to use the setClip(Shape) method to specify a >>>>> floating >>>>> point rectangle), but a down side is that using those interfaces means >>>>> that you have a value that you know is at a pixel boundary and you >>>>> pass >>>>> it in as "number / scale" only to have the code in the Graphics >>>>> immediately apply that scale and you end up with the final result of >>>>> "number / scale * scale" which might incur round-off errors and end up >>>>> being slightly off of a pixel. >>>>> >>>>> In another approach, you could also kill all of the transforms and >>>>> do it >>>>> more directly in pixels as in the following: >>>>> >>>>> // repainting x,y,w,h integers using unscaled operations >>>>> // Some parts more cumbersome to undo the implicit scaling >>>>> // but it won't suffer from round-off errors when constantly >>>>> // scaling and unscaling through the various interfaces >>>>> // that have transforms built in >>>>> int pixelx1 = (int) floor(x * scaleX) >>>>> int pixely1 = (int) floor(y * scaleY) >>>>> int pixelx2 = (int) ceil((x+w) * scaleX) >>>>> int pixely2 = (int) ceil((y+h) * scaleY) >>>>> int pixelw = pixelx2 - pixelx1; >>>>> int pixelh = pixely2 - pixely1; >>>>> // Not sure if there is a mechanism for this since I think >>>>> // all of the interfaces to get a compatible image are >>>>> // designed to assume that the caller is not scale-aware. >>>>> img = make pixel-sized image (pixelw, pixelh) >>>>> g = img.getGraphics() >>>>> // assuming that g would be unscaled in this case, but >>>>> // if g is scaled, then g.setTransform(IDENTITY) >>>>> // translate by an integer amount, and then scale >>>>> g.setClip(pixelx1, pixely1, pixelw, pixelh) >>>>> g.translate(pixelx1, pixely1) >>>>> g.scale(scaleX, scaleY); >>>>> component.paint(g) >>>>> destinationg.setTransform(IDENTITY) >>>>> destinationg.drawImage(img, pixelx1, pixely1) >>>>> // (restore transforms where needed) >>>>> >>>>> ...jim >>>>> >>>>> On 9/30/2016 1:30 PM, Jim Graham wrote: >>>>>> >>>>>> >>>>>> On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote: >>>>>>> The problem is that the RepaintManager draws a region to a buffered >>>>>>> image at first and draws the image after that to the >>>>>>> window. >>>>>>> Suppose the image has int coordinates and size (x, y, w, h) in the >>>>>>> user space. It should be drawn into the region with >>>>>>> coordinates (x, y, x+width, y+height) = (x1, y1, x2, y2). >>>>>>> If floating point UI scale is used (like 1.5) the region coordinates >>>>>>> are converted to values (1.5 * x1, 1.5 * y1, 1.5 * >>>>>>> x2, 1.5 * y2) in the dev space. >>>>>>> Now these coordinates need to be rounded and the process really >>>>>>> depends on the evenness or oddness of the start and end >>>>>>> coordinates. They both can be rounded to one side or to opposite. >>>>>>> Depending on this some lines near the drawn image >>>>>>> region can be not filled or just wrongly filled. >>>>>> >>>>>> The repaint manager should compute the nearest pixel bounds >>>>>> outside of >>>>>> the scaled repaint area, and then adjust the rendering to repaint >>>>>> all of >>>>>> those pixels. You don't "round" here, you "floor,floor,ceil,ceil" >>>>>> (and >>>>>> then worry how to present the clip region to the app so it can do the >>>>>> right thing - probably by clipping to a Rect2D.Float() and letting >>>>>> the >>>>>> integer g.getClipBounds() further round out the coordinates which >>>>>> means >>>>>> extra paint calls, but at least you'll repaint all the dirty pixels >>>>>> and >>>>>> they will be blitted to the right destination pixels if the code that >>>>>> sends them to the screen is aware of the full resolution...) >>>>>> >>>>>> ...jim >>>> >>>> >> >> > > -- Best regards, Sergey. From philip.race at oracle.com Thu Oct 6 16:52:03 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 6 Oct 2016 09:52:03 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font always displays as regular - no bold or oblique. In-Reply-To: <57F58745.7000601@oracle.com> References: <57F58745.7000601@oracle.com> Message-ID: <2acc9e8c-6d34-912f-0859-bcc2284b7d98@oracle.com> I've also had a suggestion to be more succinct and just add one line : "Glyphs may not always be rendered with the requested properties (e.g, font and style) due to platform limitations such as absence of certain fonts". I'd be OK with either my wording or the above .. -phil. On 10/05/2016 04:05 PM, Philip Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8166034 > > Non-AA fonts aren't always being bolded on OS X. > FWIW I believe this is in part a platform (OS) bug since it is > terribly inconsistent > across fonts and in some cases even sizes. > > So we need to look into why but it definitely isn't something that > calls for changing the font used by the Motif L&F as proposed here > http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006732.html > > And it calls out something I've seen a few times recently and I've > documented some examples in the bug report. > So we need to explain in the java.awt.Font spec. that sometimes > we are beholden to the limits of the platform. > > Investigating specific issues then become quality bugs .. but not > conformance ones. > > Added class description text below :- > > -phil. > > diff --git a/src/java.desktop/share/classes/java/awt/Font.java > b/src/java.desktop/share/classes/java/awt/Font.java > --- a/src/java.desktop/share/classes/java/awt/Font.java > +++ b/src/java.desktop/share/classes/java/awt/Font.java > @@ -154,6 +154,13 @@ > * associated with a font face, each differing in size, style, transform > * and font features. > *

> + * The visual rendering of all, or part of, one logical font > vis-a-vis another > + * may not always be different where there are limited suitable fonts > available. > + * The same is true for one style vis-a-vis another. This is generally > + * due to one form or another of platform limitation or behavior. > + * In the absence of such limitations a compliant implementation > + * will render glyphs which exhibit the requested properties. > + *

> * The {@link GraphicsEnvironment#getAllFonts() getAllFonts} method > * of the {@code GraphicsEnvironment} class returns an > * array of all font faces available in the system. These font faces are From james.graham at oracle.com Thu Oct 6 18:31:43 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 6 Oct 2016 11:31:43 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <07758c1e-876b-525c-edb3-f9ef3f663994@oracle.com> Message-ID: <18f1b0a7-1c08-f7d1-74da-14fc99e5c156@oracle.com> Ah, I see. There are a lot of mistaken assumptions in the rendering there. It's not just line thickness, it is assumptions about stroke control and positioning of strokes. The biggest issue seems to be that developers (including our own internal Swing developers who heard this lecture from me decades ago, but ignored it because it was inconvenient and not yet relevant at the time) who use the integer-based draw commands assume that their lines are centered on the pixel that they are naming. In other words "if I draw a line along x=5 then I am telling the system to fill all the pixels with an X coordinate of 5", but that is not what that drawing request is asking for. The coordinates are at pixel edges and it is an artifact of our fill/stroke rules and stroke control hinting that has made this work out at 1:1 scaling. As soon as you scale you can see the issues. We used to only scale for printing, but now we are starting to scale for the screen. g.drawRect(0,0,w-1,h-1) is a completely disfunctional way to outline a component with any settings other than 1:1 coordinates and STROKE_CONTROL on. I've been mentioning this for years (going on decades now), but Swing was addicted to that boilerplate for drawing a border. Thankfully, FX and its CSS-focused skinning has gone with a different mechanism (primarily most FX components are outlined using successive fills - optimized in implementation to avoid overdrawing - rather than using strokes based on mistaken assumptions about where the line is drawn). In particular, the line in that example g.drawRect(0,0,w-1,h-1) technically occurs at the following coordinates: outer part of outline goes from 0.0-0.5,0.0-0.5 to w-1+0.5,h-1+0.5 (i.e. -0.5,-0.5 to w-0.5,h-0.5) inner part of outline goes from 0.0+0.5,0.0+0.5 to w-1-0.5,h-1-0.5 (i.e. +0.5,+0.5 to w-1.5,h-1.5) At a high enough scale you can see the stroke starting to separate from the fill on the right and bottom edges where the closest it gets to the edge is 0.5 scaled coordiantes. That rounds to 0 for 1:1 and with the biasing from STROKE_CONTROL, but at higher resolutions it becomes a non-zero number of pixels. Even at 1:1 scale if you follow our filling rules explicitly (which would require setting STROKE_CONTROL to PURE) then that would fill the rows at y=-1 and y=h-2 and the columns at x=-1 and x=w-2, which is not what you want at all. Setting STROKE_CONTROL on allows us to bias the location of the stroke a little and it ends up filling the correct pixels as a side effect (though STROKE_CONTROL is meant to achieve consistency in strokes, it also ends up shifting the line by enough that the fill rules choose different pixels in this case). The STROKE_CONTROL=on version of the path is assumed to be (0.25,0.25,w-0.75,h-0.75) because we snap all coordinates in a stroke-controlled non-AA path to the nearest location that is 0.25,0.25 within a pixel. This snapping to a consistent sub-pixel location biasing at 0.25 was chosen because line widths grow more evenly at that offset, but it offsets the outline enough so that the outline considered for filling becomes: outer part of outline goes from 0.25-0.5,0.25-0.5 to 0.25+w-1+0.5,0.25+h-1+0.5 (i.e. -0.25,-0.25 to w-0.25,h-0.25) inner part of outline goes from 0.25+0.5,0.25+0.5 to 0.25+w-1-0.5,0.25+h-1-0.5 (i.e. +0.75,+0.75 to w-1.25,h-1.25) which renders the rows columns at 0 and wh-1 at a 1:1 scale using our fill rules. Note that if you scale high enough you can still see separation between fill and outline, but the gap is only 0.25 scaled coordinates so it would take a scale of at least 4x to see it. The technically accurate way to render the first/last pixel/1-unit-coordinate boundary of a component would be to drawRect(0.5,0.5,w-1,h-1) (with no stroke control set) which would place the rectangle at the following coordinates: outer part of outline goes from 0.5-0.5,0.5-0.5 to 0.5+w-1+0.5,0.5+h-1+0.5 (i.e. 0,0, to w,h) inner part of outline goes form 0.5+0.5,0.5+0.5 to 0.5+w-1-0.5,0.5+h-1-0.5 (i.e. 1,1 to w-1,h-1) which completely encloses the first/last row/column of pixels on a 1:1 coordinate system and accurately covers the first/last N pixels in any arbitrary N-scaled coordinate system. The rounding for scales like 1.5 still might not work out the way you wanted, but at least the exact geometry is consistent with respect to the placement of pixels. With AA you will get a consistent border all around if w,h are snapped to a pixel size, but with non-AA then rounding error might lead to an extra pixel on one pair of sides. I haven't done the analysis to see how the above technique would be affected by STROKE_CONTROL because really what you are looking for is to render the a consistent edge around the component and so successive fills as is done with most of our CSS skinning files in FX is a better solution overall. There are just too many considerations in filling to make it worthwhile for simple rectangular regions... ...jim On 10/4/16 1:46 PM, Anton Tarasov wrote: > On 10/4/2016 11:30 PM, Jim Graham wrote: >> I wasn't familiar with the test code for this particular case. Is it in a bug report somewhere? > Jim, I'm re-attaching it (it was in my first e-mail). > > Thanks, > Anton. > >> >> ...jim >> >> On 10/4/16 1:01 PM, Anton Tarasov wrote: >>> Also, the problem with primitives rendering (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is >>> still there. But it seems to relate to line-thikness (border-thickness) rounding inaccuracy. What we can do with >>> that?... > From james.graham at oracle.com Thu Oct 6 21:21:48 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 6 Oct 2016 14:21:48 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <44A09AC9-77C5-4E44-83F9-8AA26D7AF1AC@jetbrains.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <879e1396-a8ff-b260-cf99-1c574400ec56@oracle.com> <44A09AC9-77C5-4E44-83F9-8AA26D7AF1AC@jetbrains.com> Message-ID: Yes, most likely. It involves making sure that the origin of the viewport is always an even multiple of pixels, then the copyArea will match up with the repainting. The damage repair messages here have already pointed out how to deal with making sure the repaints are on integer coordinates, the only tricky part is that there is no floating point copyArea method (copyArea used to not allow copying with anything other than a translation, but we fixed that for Mac, but the fix really only works for integer scales and, while it does do something sane for non-integer scales, it doesn't really provide the caller full precision for controlling which pixels are copied). To do a pixel-exact copyArea you would need to undo the transform, calculate the scaled pixel locations yourself, then do a non-scaled copyArea and then restore the transform (or do the operation on a copy of the graphics)... ...jim On 10/6/16 3:11 AM, Anton Tarasov wrote: > Hi all, > > On 04 Oct 2016, at 23:28, Jim Graham wrote: >> >> On 10/4/16 1:01 PM, Anton Tarasov wrote: >>> Anyway, I roughly tried your approach mentioned in the previous e-mail, but forcing RM to paint via offscreen >>> BufferedImage, not volatile (just for a quick check). >>> It solved the shift issue of the demo listed in 8162350, which is cool. It also solved the traces of InternalFrame and >>> menu in SwingSet2. Scrolling still traces (I suppose it should be resolved in JViewport/blitting). >>> Also, the problem with primitives rendering (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is >>> still there. But it seems to relate to line-thikness (border-thickness) rounding inaccuracy. What we can do with that?... >> >> Yes, blitting is a separate, but related case where pixel-exactness matters. When we scroll a pane we need to scroll it by a precise number of pixels and then paint the newly visible information at a precise pixel location. Solving this aspect might require events to have higher precision data available. >> >> We should probably take detailed conversations about the solutions to the bug reports? > > > What do you think, is it possible to address the mentioned issues in jdk9, not deferring them? The new HiDPI support will affect all the users having fractional scale screens... > > Thanks, > Anton. > From Sergey.Bylokhov at oracle.com Fri Oct 7 00:59:57 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 7 Oct 2016 03:59:57 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <879e1396-a8ff-b260-cf99-1c574400ec56@oracle.com> <44A09AC9-77C5-4E44-83F9-8AA26D7AF1AC@jetbrains.com> Message-ID: <3ab2b74f-df00-ab2c-80c0-a3a6f84a639d@oracle.com> Hi, Jim. Can you please clarify why the exact pixels copyarea is necessary(As well as the problem in RepaintManager) I am not sure it is clear why we need to do something in the users space in floats. I mean that all our Swing components uses int(units) as bounds, all of them uses integers as requests to paint, so everything in the shared code works in terms of units. I am not sure that it is possible to scroll using pixel-exact copyArea because we cannot use floats to scroll by this amount, otherwise we will get the situation when the component inside the scroollpane will have fractional coordinate which we cannot use via int API. On 07.10.16 0:21, Jim Graham wrote: > Yes, most likely. It involves making sure that the origin of the > viewport is always an even multiple of pixels, then the copyArea will > match up with the repainting. The damage repair messages here have > already pointed out how to deal with making sure the repaints are on > integer coordinates, the only tricky part is that there is no floating > point copyArea method (copyArea used to not allow copying with anything > other than a translation, but we fixed that for Mac, but the fix really > only works for integer scales and, while it does do something sane for > non-integer scales, it doesn't really provide the caller full precision > for controlling which pixels are copied). To do a pixel-exact copyArea > you would need to undo the transform, calculate the scaled pixel > locations yourself, then do a non-scaled copyArea and then restore the > transform (or do the operation on a copy of the graphics)... > > ...jim > > On 10/6/16 3:11 AM, Anton Tarasov wrote: >> Hi all, >> >> On 04 Oct 2016, at 23:28, Jim Graham wrote: >>> >>> On 10/4/16 1:01 PM, Anton Tarasov wrote: >>>> Anyway, I roughly tried your approach mentioned in the previous >>>> e-mail, but forcing RM to paint via offscreen >>>> BufferedImage, not volatile (just for a quick check). >>>> It solved the shift issue of the demo listed in 8162350, which is >>>> cool. It also solved the traces of InternalFrame and >>>> menu in SwingSet2. Scrolling still traces (I suppose it should be >>>> resolved in JViewport/blitting). >>>> Also, the problem with primitives rendering >>>> (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) >>>> is >>>> still there. But it seems to relate to line-thikness >>>> (border-thickness) rounding inaccuracy. What we can do with that?... >>> >>> Yes, blitting is a separate, but related case where pixel-exactness >>> matters. When we scroll a pane we need to scroll it by a precise >>> number of pixels and then paint the newly visible information at a >>> precise pixel location. Solving this aspect might require events to >>> have higher precision data available. >>> >>> We should probably take detailed conversations about the solutions to >>> the bug reports? >> >> >> What do you think, is it possible to address the mentioned issues in >> jdk9, not deferring them? The new HiDPI support will affect all the >> users having fractional scale screens... >> >> Thanks, >> Anton. >> -- Best regards, Sergey. From jayathirth.d.v at oracle.com Fri Oct 7 08:48:40 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 7 Oct 2016 01:48:40 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods Message-ID: Hi, Please review the following fix in JDK9 at your convenience: Bug : https://bugs.openjdk.java.net/browse/JDK-8167281 Webrev : http://cr.openjdk.java.net/~jdv/8167281/webrev.00/ Issue : IIONodeList.item(index) and IIOMetadataNode. getElementsByTagName(tag) are not following specification properly. Root cause : . IIOMetadataNode .getElementsByTagName(tag) returns empty list for special input value "*" and IIONodeList.item(index)throws IndexOutOfBoundsException for index equal to length of NodeList. Solution : IIOMetadataNode .getElementsByTagName(tag) should match all tags for special input value "*" and IIONodeList.item(index) should return null if input index is equals to length of NodeList. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Oct 7 13:18:24 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 7 Oct 2016 16:18:24 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales Message-ID: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> Hello. Please review the fix for jdk9. This is bug which was found when the fractional scale is used in Swing. The problem is that if we save a usrClip as Rectangle2D then we incorrectly intersect it with device clip. The problem is in the RectangularShape.getBounds() method, see more details: http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html So getBounds() produces the bigger Rectangle than is necessary and our clip became bigger as well. This means that in some fractional scales such clips are overlapping. The test will test fillRect, DrawImage, DrawLine methods and validates that there are no any overlapping if we set the clip.(The gaps between touched pixels are allowed only for lines). Note that as I understand the code this fix should affect the DrawLines, because in some situations it is possible that two lines are overlapped without clip. And two other cases(fillRect, drawImage) should work without clip, but only fillRect works. It is discussed here: http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007766.html Bug: https://bugs.openjdk.java.net/browse/JDK-8167310 Webrev can be found at: http://cr.openjdk.java.net/~serb/8167310/webrev.00 -- Best regards, Sergey. From james.graham at oracle.com Fri Oct 7 21:58:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 7 Oct 2016 14:58:04 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> Message-ID: <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> That looks great. A couple of questions. Region, line 132: why are you testing for newv > coordinate? Test case: Where do you get white gaps? Is it in the line test? If so, then consider setting the line width higher (or drawing 2 lines per iteration as I mention in the last paragraph). I can illustrate this with the following: scale = 1.5 vertical line drawn with step, 0, step, SIZE covers the area: (step-0.5)*1.5, -0.5, (step+0.5)*1.5, SIZE+0.5 step*1.5-.75, ..., step*1.5+0.75 clipLoX-0.75, ..., clipHiX-0.75 Note that this will cover some pixels to the left of the clip (which should be clipped out), but it will leave a gap between the right side of the line and the right side of the clip, i.e. the next step (of about 0.75 pixels - which are likely to include a pixel center and thus leave a white pixel). At higher scales, the gap will be higher and more likely to include white pixels. A line width of 2 (actually 2*stepsize where stepsize=1 here) means that the line will cover an entire step regardless of the scale. Hopefully that will remove the need for the WHITE test in the validate method. Note that STROKE_CONTROL may come into play here as well. The above analysis is for STROKE_PURE semantics, but the normalization/biasing of STROKE_NORMALIZE might increase or decrease the chance that the above will fix the issue and may require an even larger line width. Another option without setting line width would be to draw two lines, one at step and another at step+1, which would test for gaps between adjacent lines as well as ensure that the test covers the "right half" of the line at step and the "left half" of the line at step+1... ...jim On 10/7/16 6:18 AM, Sergey Bylokhov wrote: > Hello. > > Please review the fix for jdk9. > > This is bug which was found when the fractional scale is used in Swing. The problem is that if we save a usrClip as > Rectangle2D then we incorrectly intersect it with device clip. The problem is in the RectangularShape.getBounds() > method, see more details: > http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html > > So getBounds() produces the bigger Rectangle than is necessary and our clip became bigger as well. This means that in > some fractional scales such clips are overlapping. > > The test will test fillRect, DrawImage, DrawLine methods and validates that there are no any overlapping if we set the > clip.(The gaps between touched pixels are allowed only for lines). > > Note that as I understand the code this fix should affect the DrawLines, because in some situations it is possible that > two lines are overlapped without clip. And two other cases(fillRect, drawImage) should work without clip, but only > fillRect works. It is discussed here: > http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007766.html > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167310 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8167310/webrev.00 > From james.graham at oracle.com Fri Oct 7 22:41:30 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 7 Oct 2016 15:41:30 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <3ab2b74f-df00-ab2c-80c0-a3a6f84a639d@oracle.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <879e1396-a8ff-b260-cf99-1c574400ec56@oracle.com> <44A09AC9-77C5-4E44-83F9-8AA26D7AF1AC@jetbrains.com> <3ab2b74f-df00-ab2c-80c0-a3a6f84a639d@oracle.com> Message-ID: <92c78e03-0594-2bbd-9917-f6e7851dc7a6@oracle.com> Aren't the components inside the scrollpane located relative to the origin of the entire scrollable region? In which case, the precise location of the visible part of the view has no effect on any component bounds...? ...jim On 10/6/16 5:59 PM, Sergey Bylokhov wrote: > Hi, Jim. > Can you please clarify why the exact pixels copyarea is necessary(As well as the problem in RepaintManager) I am not > sure it is clear why we need to do something in the users space in floats. I mean that all our Swing components uses > int(units) as bounds, all of them uses integers as requests to paint, so everything in the shared code works in terms of > units. I am not sure that it is possible to scroll using pixel-exact copyArea because we cannot use floats to scroll by > this amount, otherwise we will get the situation when the component inside the scroollpane will have fractional > coordinate which we cannot use via int API. > > On 07.10.16 0:21, Jim Graham wrote: >> Yes, most likely. It involves making sure that the origin of the >> viewport is always an even multiple of pixels, then the copyArea will >> match up with the repainting. The damage repair messages here have >> already pointed out how to deal with making sure the repaints are on >> integer coordinates, the only tricky part is that there is no floating >> point copyArea method (copyArea used to not allow copying with anything >> other than a translation, but we fixed that for Mac, but the fix really >> only works for integer scales and, while it does do something sane for >> non-integer scales, it doesn't really provide the caller full precision >> for controlling which pixels are copied). To do a pixel-exact copyArea >> you would need to undo the transform, calculate the scaled pixel >> locations yourself, then do a non-scaled copyArea and then restore the >> transform (or do the operation on a copy of the graphics)... >> >> ...jim >> >> On 10/6/16 3:11 AM, Anton Tarasov wrote: >>> Hi all, >>> >>> On 04 Oct 2016, at 23:28, Jim Graham wrote: >>>> >>>> On 10/4/16 1:01 PM, Anton Tarasov wrote: >>>>> Anyway, I roughly tried your approach mentioned in the previous >>>>> e-mail, but forcing RM to paint via offscreen >>>>> BufferedImage, not volatile (just for a quick check). >>>>> It solved the shift issue of the demo listed in 8162350, which is >>>>> cool. It also solved the traces of InternalFrame and >>>>> menu in SwingSet2. Scrolling still traces (I suppose it should be >>>>> resolved in JViewport/blitting). >>>>> Also, the problem with primitives rendering >>>>> (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) >>>>> is >>>>> still there. But it seems to relate to line-thikness >>>>> (border-thickness) rounding inaccuracy. What we can do with that?... >>>> >>>> Yes, blitting is a separate, but related case where pixel-exactness >>>> matters. When we scroll a pane we need to scroll it by a precise >>>> number of pixels and then paint the newly visible information at a >>>> precise pixel location. Solving this aspect might require events to >>>> have higher precision data available. >>>> >>>> We should probably take detailed conversations about the solutions to >>>> the bug reports? >>> >>> >>> What do you think, is it possible to address the mentioned issues in >>> jdk9, not deferring them? The new HiDPI support will affect all the >>> users having fractional scale screens... >>> >>> Thanks, >>> Anton. >>> > > From james.graham at oracle.com Sat Oct 8 00:03:34 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 7 Oct 2016 17:03:34 -0700 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <92c78e03-0594-2bbd-9917-f6e7851dc7a6@oracle.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <879e1396-a8ff-b260-cf99-1c574400ec56@oracle.com> <44A09AC9-77C5-4E44-83F9-8AA26D7AF1AC@jetbrains.com> <3ab2b74f-df00-ab2c-80c0-a3a6f84a639d@oracle.com> <92c78e03-0594-2bbd-9917-f6e7851dc7a6@oracle.com> Message-ID: <0a965991-da09-c519-1ed5-9a1e9ca268f3@oracle.com> One issue is that the JViewport lastPaintPosition is exposed to subclasses and is an integer location. It is also exposed to all apps via getViewPosition() and getViewRect(). That will conflict with indicating the exact location of the pixel-precise scroll position. It's not clear how these will be used by subclasses and apps, or whether they can be implemented as approximations (ViewRect() could be the smallest integer rectangle that encloses the real view bounds, and the position could be the closest integer location to where the true pixel origin is). One way to fix repainting issues is to disable copyArea optimizations if there is a scale. FX has had a limitation like this until we fix our math, but our scrolling is entirely a hidden implementation detail. Given that JViewport exposes the backbuffer and provides convenience methods for computing the blits needed to scroll, it gets a little dicey unless the scroll mode is considered just a hint. ...jim On 10/7/16 3:41 PM, Jim Graham wrote: > Aren't the components inside the scrollpane located relative to the origin of the entire scrollable region? In which > case, the precise location of the visible part of the view has no effect on any component bounds...? > > ...jim > > On 10/6/16 5:59 PM, Sergey Bylokhov wrote: >> Hi, Jim. >> Can you please clarify why the exact pixels copyarea is necessary(As well as the problem in RepaintManager) I am not >> sure it is clear why we need to do something in the users space in floats. I mean that all our Swing components uses >> int(units) as bounds, all of them uses integers as requests to paint, so everything in the shared code works in terms of >> units. I am not sure that it is possible to scroll using pixel-exact copyArea because we cannot use floats to scroll by >> this amount, otherwise we will get the situation when the component inside the scroollpane will have fractional >> coordinate which we cannot use via int API. >> >> On 07.10.16 0:21, Jim Graham wrote: >>> Yes, most likely. It involves making sure that the origin of the >>> viewport is always an even multiple of pixels, then the copyArea will >>> match up with the repainting. The damage repair messages here have >>> already pointed out how to deal with making sure the repaints are on >>> integer coordinates, the only tricky part is that there is no floating >>> point copyArea method (copyArea used to not allow copying with anything >>> other than a translation, but we fixed that for Mac, but the fix really >>> only works for integer scales and, while it does do something sane for >>> non-integer scales, it doesn't really provide the caller full precision >>> for controlling which pixels are copied). To do a pixel-exact copyArea >>> you would need to undo the transform, calculate the scaled pixel >>> locations yourself, then do a non-scaled copyArea and then restore the >>> transform (or do the operation on a copy of the graphics)... >>> >>> ...jim >>> >>> On 10/6/16 3:11 AM, Anton Tarasov wrote: >>>> Hi all, >>>> >>>> On 04 Oct 2016, at 23:28, Jim Graham wrote: >>>>> >>>>> On 10/4/16 1:01 PM, Anton Tarasov wrote: >>>>>> Anyway, I roughly tried your approach mentioned in the previous >>>>>> e-mail, but forcing RM to paint via offscreen >>>>>> BufferedImage, not volatile (just for a quick check). >>>>>> It solved the shift issue of the demo listed in 8162350, which is >>>>>> cool. It also solved the traces of InternalFrame and >>>>>> menu in SwingSet2. Scrolling still traces (I suppose it should be >>>>>> resolved in JViewport/blitting). >>>>>> Also, the problem with primitives rendering >>>>>> (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) >>>>>> is >>>>>> still there. But it seems to relate to line-thikness >>>>>> (border-thickness) rounding inaccuracy. What we can do with that?... >>>>> >>>>> Yes, blitting is a separate, but related case where pixel-exactness >>>>> matters. When we scroll a pane we need to scroll it by a precise >>>>> number of pixels and then paint the newly visible information at a >>>>> precise pixel location. Solving this aspect might require events to >>>>> have higher precision data available. >>>>> >>>>> We should probably take detailed conversations about the solutions to >>>>> the bug reports? >>>> >>>> >>>> What do you think, is it possible to address the mentioned issues in >>>> jdk9, not deferring them? The new HiDPI support will affect all the >>>> users having fractional scale screens... >>>> >>>> Thanks, >>>> Anton. >>>> >> >> From Sergey.Bylokhov at oracle.com Sat Oct 8 21:15:47 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 9 Oct 2016 00:15:47 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> Message-ID: <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> On 08.10.16 0:58, Jim Graham wrote: > That looks great. A couple of questions. An updated version and a comments inline: http://cr.openjdk.java.net/~serb/8167310/webrev.01 > > Region, line 132: why are you testing for newv > coordinate? That was an attempt to catch an overflow like in case of int/longs. This is an unnecessary for double type, the code is removed and a spec of the method is also updated. > Test case: > > Where do you get white gaps? Is it in the line test? If so, then > consider setting the line width higher (or drawing 2 lines per iteration > as I mention in the last paragraph). I can illustrate this with the > following: Yes, it was in the lines. In the new version I changed the line width to 6. This value will fill the whole clip in all tested scales[0.1 - 4]. I did not use two lines because I use "srcover+transparentColor" and two lines can produce one more color after overlapping. > Note that this will cover some pixels to the left of the clip (which > should be clipped out), but it will leave a gap between the right side > of the line and the right side of the clip, i.e. the next step (of about > 0.75 pixels - which are likely to include a pixel center and thus leave > a white pixel). At higher scales, the gap will be higher and more > likely to include white pixels. > > A line width of 2 (actually 2*stepsize where stepsize=1 here) means that > the line will cover an entire step regardless of the scale. Hopefully > that will remove the need for the WHITE test in the validate method. > > Note that STROKE_CONTROL may come into play here as well. The above > analysis is for STROKE_PURE semantics, but the normalization/biasing of > STROKE_NORMALIZE might increase or decrease the chance that the above > will fix the issue and may require an even larger line width. > > Another option without setting line width would be to draw two lines, > one at step and another at step+1, which would test for gaps between > adjacent lines as well as ensure that the test covers the "right half" > of the line at step and the "left half" of the line at step+1... > > ...jim > > On 10/7/16 6:18 AM, Sergey Bylokhov wrote: >> Hello. >> >> Please review the fix for jdk9. >> >> This is bug which was found when the fractional scale is used in >> Swing. The problem is that if we save a usrClip as >> Rectangle2D then we incorrectly intersect it with device clip. The >> problem is in the RectangularShape.getBounds() >> method, see more details: >> http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html >> >> So getBounds() produces the bigger Rectangle than is necessary and our >> clip became bigger as well. This means that in >> some fractional scales such clips are overlapping. >> >> The test will test fillRect, DrawImage, DrawLine methods and validates >> that there are no any overlapping if we set the >> clip.(The gaps between touched pixels are allowed only for lines). >> >> Note that as I understand the code this fix should affect the >> DrawLines, because in some situations it is possible that >> two lines are overlapped without clip. And two other cases(fillRect, >> drawImage) should work without clip, but only >> fillRect works. It is discussed here: >> http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007766.html >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8167310 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8167310/webrev.00 >> -- Best regards, Sergey. From james.graham at oracle.com Mon Oct 10 18:31:45 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Oct 2016 11:31:45 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> Message-ID: Hi Sergey, Comments inline... On 10/8/16 2:15 PM, Sergey Bylokhov wrote: > On 08.10.16 0:58, Jim Graham wrote: >> That looks great. A couple of questions. > > An updated version and a comments inline: > http://cr.openjdk.java.net/~serb/8167310/webrev.01 > >> Test case: >> >> Where do you get white gaps? Is it in the line test? If so, then >> consider setting the line width higher (or drawing 2 lines per iteration >> as I mention in the last paragraph). I can illustrate this with the >> following: > > Yes, it was in the lines. In the new version I changed the line width to 6. This value will fill the whole clip in all > tested scales[0.1 - 4]. > I did not use two lines because I use "srcover+transparentColor" and two lines can produce one more color after > overlapping. OK, but you only need a line width of 2.0 to cover the gap regardless of scale. Line width scales in user space so larger scales scale up the line width along with the clip region being rendered. With STROKE_CONTROL on, 2.0 is plenty because the line is normalized (though I'm not sure the test should assume that). WITH STROKE_PURE, 2.0 is precisely exactly the right amount. Round-off error might theoretically bite us, so maybe 2.01 just to be safe. Other comments... In the drawImage case in the test, is there a reason to stretch the image to MAX_INT size? Isn't (img,0,0,null) enough? The issue with the MAX_INT arguments is that this then becomes not only a test of clipping, but a test for how our image scaling handles huge scales that might overflow. Those should be tested independently if we fear there is a problem with image scaling. Also, This line in the test case: 161 if (rgb != goldRGB && rgb != GREEN.getRGB() 162 && rgb != RED.getRGB()) { Will give us a pass on the test as long as we made the same mistake for both the rect clip and the shape clip. I think you want "(rgb != goldRGB) || (rgb != GREEN && rgb != RED)"...? ...jim From Sergey.Bylokhov at oracle.com Mon Oct 10 18:55:00 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Oct 2016 21:55:00 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> Message-ID: <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> On 10.10.16 21:31, Jim Graham wrote: > OK, but you only need a line width of 2.0 to cover the gap regardless of > scale. Line width scales in user space so larger scales scale up the > line width along with the clip region being rendered. With > STROKE_CONTROL on, 2.0 is plenty because the line is normalized (though > I'm not sure the test should assume that). WITH STROKE_PURE, 2.0 is > precisely exactly the right amount. Round-off error might theoretically > bite us, so maybe 2.01 just to be safe. When I tried to use w=2/3/4/5 I got a situation when no lines are drawn to the image. I guess to paint something we need to cover at least half of the pixel, this is not the case when line is w=2 and small scale is used. > In the drawImage case in the test, is there a reason to stretch the > image to MAX_INT size? Isn't (img,0,0,null) enough? The issue with the > MAX_INT arguments is that this then becomes not only a test of clipping, > but a test for how our image scaling handles huge scales that might > overflow. Those should be tested independently if we fear there is a > problem with image scaling. This is extreme case which I tried to test, intersect the clip + the scale on graphics + the scale from drawImage, since this huge coordinates also can affect the clip, if intersection will be done incorrectly. > > Also, This line in the test case: > > 161 if (rgb != goldRGB && rgb != GREEN.getRGB() > 162 && rgb != RED.getRGB()) { > > Will give us a pass on the test as long as we made the same mistake for > both the rect clip and the shape clip. I think you want "(rgb != > goldRGB) || (rgb != GREEN && rgb != RED)"...? Correct, I will update the test. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Oct 10 19:04:51 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Oct 2016 22:04:51 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> Message-ID: <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> On 10.10.16 21:55, Sergey Bylokhov wrote: >> Will give us a pass on the test as long as we made the same mistake for >> both the rect clip and the shape clip. I think you want "(rgb != >> goldRGB) || (rgb != GREEN && rgb != RED)"...? > > Correct, I will update the test. surprisingly but it is produce the different results.... And I think that the clip which is set via Shape is shifted, because the first and last fillRects cover only the half of expected area. But in case of clip=rectangle all fillRects produce the same areas. -- Best regards, Sergey. From james.graham at oracle.com Mon Oct 10 19:18:46 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Oct 2016 12:18:46 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> Message-ID: <4df7b81f-289b-a31d-01bd-cf7511391a13@oracle.com> On 10/10/16 11:55 AM, Sergey Bylokhov wrote: > On 10.10.16 21:31, Jim Graham wrote: >> OK, but you only need a line width of 2.0 to cover the gap regardless of >> scale. Line width scales in user space so larger scales scale up the >> line width along with the clip region being rendered. With >> STROKE_CONTROL on, 2.0 is plenty because the line is normalized (though >> I'm not sure the test should assume that). WITH STROKE_PURE, 2.0 is >> precisely exactly the right amount. Round-off error might theoretically >> bite us, so maybe 2.01 just to be safe. > > When I tried to use w=2/3/4/5 I got a situation when no lines are drawn to the image. I guess to paint something we need > to cover at least half of the pixel, this is not the case when line is w=2 and small scale is used. I think I see the problem. With STROKE_NORMALIZE and a very tiny scale and a small line width you will not reach the center of a pixel from the x,y=0.25 offset that our implementation normalizes lines to. At .1 scale you'd need to cover .25 units to reach that pixel center so you'd need a larger line width. Since only half of the line happens on either side of the line, a line width of 5 at .1 scale only draws .25 on either side and even though that reaches the pixel center, it doesn't light up the pixel center because that would be the right (or bottom) side of the fillable area and a pixel is not rendered if its center falls on the right or bottom edge of a fillable region, so you would need to go to 6 to see something at .1 scale. If you turn off NORMALIZE and use PURE, then the line would track along with the clip location. I'm not sure why you are testing NORMALIZE behavior since the NORMALIZE behavior is not a formal spec since there are several ways to achieve its goals. The way we implement it 6 is enough for the lines to appear at .1 scale, but someone else might decide that normalizing lines to the pixel edges is better for some reason and then you'd need to have a line width of 11 to light up the pixels. Note that we use 0.5,0.5 for AA rendering because its needs are different, so our own implementation isn't even consistent about the bias used for NORMALIZE (though since you aren't testing AA, you will only encounter our 0.25 bias). If you switch to PURE then 2 (or 2.01 to be safe) would suffice... ...jim From Sergey.Bylokhov at oracle.com Mon Oct 10 19:26:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Oct 2016 22:26:54 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> Message-ID: On 10.10.16 22:04, Sergey Bylokhov wrote: > On 10.10.16 21:55, Sergey Bylokhov wrote: >>> Will give us a pass on the test as long as we made the same mistake for >>> both the rect clip and the shape clip. I think you want "(rgb != >>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >> >> Correct, I will update the test. > > surprisingly but it is produce the different results.... And I think > that the clip which is set via Shape is shifted, because the first and > last fillRects cover only the half of expected area. But in case of > clip=rectangle all fillRects produce the same areas. It was solved by stroke=PURE, but I am not sure why fillRect(when clip is set via Shape) is affected by this hint. Is it ok? -- Best regards, Sergey. From james.graham at oracle.com Mon Oct 10 19:29:49 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Oct 2016 12:29:49 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> Message-ID: <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> That does sound like a problem. Does it do the same thing with new Path2D(Rectangle)? The Area class does some processing on the path and it would be nice to eliminate that as a potential source of this problem. I don't have a buildable JDK9 repo right now that I can fire off some quick tests on so I'll have to look at this later... ...jim On 10/10/16 12:04 PM, Sergey Bylokhov wrote: > On 10.10.16 21:55, Sergey Bylokhov wrote: >>> Will give us a pass on the test as long as we made the same mistake for >>> both the rect clip and the shape clip. I think you want "(rgb != >>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >> >> Correct, I will update the test. > > surprisingly but it is produce the different results.... And I think that the clip which is set via Shape is shifted, > because the first and last fillRects cover only the half of expected area. But in case of clip=rectangle all fillRects > produce the same areas. > > From james.graham at oracle.com Mon Oct 10 19:34:37 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Oct 2016 12:34:37 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> Message-ID: Yes, we do bias both. So, the code we just added doesn't match the biasing that is performed by the fill operations, we should probably make it be the same. You can see that it computes a bias boolean when it calls getFillSSI(), but the bias is applied natively in the native ShapeSpanIterator code... ...jim On 10/10/16 12:26 PM, Sergey Bylokhov wrote: > On 10.10.16 22:04, Sergey Bylokhov wrote: >> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>> Will give us a pass on the test as long as we made the same mistake for >>>> both the rect clip and the shape clip. I think you want "(rgb != >>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>> >>> Correct, I will update the test. >> >> surprisingly but it is produce the different results.... And I think >> that the clip which is set via Shape is shifted, because the first and >> last fillRects cover only the half of expected area. But in case of >> clip=rectangle all fillRects produce the same areas. > > It was solved by stroke=PURE, but I am not sure why fillRect(when clip is set via Shape) is affected by this hint. Is it > ok? > > From Sergey.Bylokhov at oracle.com Mon Oct 10 19:45:03 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Oct 2016 22:45:03 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> Message-ID: An updated version: http://cr.openjdk.java.net/~serb/8167310/webrev.03 - STROKE_PURE is used in the test, the line width is set to 2.01. This also fixed the difference between clips(Shape vs Rectangle). - The if statement is changed as suggested. The additional questions: - In the current fix we change behavior of the clip. Before the fix if we set the clip to the nearest areas they can overlaps in the destination. Should we change the drawImage as well? Currently if I draw image to the nearest areas in the user space, the images can overlap in the destination(so the actual result in destination depends on what image was painted first). - Should the clip be affected by the stroke(if it was set by the shape)? Right now if the clip was set by the shape it will produce different result than if it was set via rectangle. On 10.10.16 22:29, Jim Graham wrote: > That does sound like a problem. Does it do the same thing with new > Path2D(Rectangle)? The Area class does some processing on the path and > it would be nice to eliminate that as a potential source of this > problem. I don't have a buildable JDK9 repo right now that I can fire > off some quick tests on so I'll have to look at this later... > > ...jim > > On 10/10/16 12:04 PM, Sergey Bylokhov wrote: >> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>> Will give us a pass on the test as long as we made the same mistake for >>>> both the rect clip and the shape clip. I think you want "(rgb != >>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>> >>> Correct, I will update the test. >> >> surprisingly but it is produce the different results.... And I think >> that the clip which is set via Shape is shifted, >> because the first and last fillRects cover only the half of expected >> area. But in case of clip=rectangle all fillRects >> produce the same areas. >> >> -- Best regards, Sergey. From james.graham at oracle.com Mon Oct 10 20:34:34 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Oct 2016 13:34:34 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> Message-ID: <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> [CC'ing Phil in case he has some suggestions for how the API should work...] Responding just to additional questions in this email... On 10/10/16 12:45 PM, Sergey Bylokhov wrote: > The additional questions: > - In the current fix we change behavior of the clip. Before the fix if we set the clip to the nearest areas they can > overlaps in the destination. Should we change the drawImage as well? Currently if I draw image to the nearest areas in > the user space, the images can overlap in the destination(so the actual result in destination depends on what image was > painted first). Yes, I think adjacent drawImage requests should not overlap. We should look into this separately. > - Should the clip be affected by the stroke(if it was set by the shape)? Right now if the clip was set by the shape it > will produce different result than if it was set via rectangle. I think we could have the clip never be affected by STROKE_NORMALIZE. That might make sense because the NORMALIZE code is meant to deal with aesthetic issues, not rendering math issues. We'd have to add a getClipSSI() method that hard-codes the "adjust" boolean to "false" to do that, but that is an easy fix. The question is then that would meant that setClip(Shape) and fill(Shape) might disagree, though. This would argue that we should have it affected by the normalization. This is also a fairly easy fix, you could have LoopPipe have a method that would return the appropriate Rectangle representing which pixels are covered for a given Rectangle2D depending on the normalize parameters. On the other hand, we normalize differently for AA and non-AA. Calling getFillSSI() on LoopPipe basically performs normalization only for non-AA fills. Arguably, though, clipping produces non-AA results in that it chooses whole pixels to include or exclude. This might mean that it should never follow AA normalization. But, it also points out the silliness of normalizing to match the results of fill when it can never do that for AA mode. (Potentially we could add an AA-clip mode, but the implementation of that would require capturing every rendering operation to an intermediate buffer and then pixel-filtering it through a mask created by AA-filling the clip shape - we do that in FX, but it would require major surgery to add that to the SG2D pipeline so I don't think we would ever consider that at this stage.) Any of those solutions are fairly easy to fix (except adding an AA clipping mode), but the question is which is more useful and/or surprises the developers the least. So we have the current case: setClip(integers or int-Rectangle) => pure coverage setClip(other shape) => non-AA normalized coverage If we decide that clip should normalize always to non-AA parameters because it is an intrinsically non-AA type of operation then we have to fix the setClip(integer rectangle) code which isn't hard. If we decide that clip should normalize to the current AA parameters then it's basically the same, but we need to find a way to query the right objects to perform the AA according to their chosen bias. LoopPipe/ShapeSpanIterator appear to own non-AA normalization and I think AA normalization is hidden behind the TileGenerator API somewhere that Ductus/Pisces/Marlin all implement. If we decide that clip should not normalize then we only have to fix setClip(other shape) and it's just a question of hard-coding the adjust boolean in the call to instantiate the ShapeSpanIterator. Phil? ...jim From james.graham at oracle.com Mon Oct 10 20:42:46 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Oct 2016 13:42:46 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> Message-ID: <39f92c44-2419-4f95-2846-4d78d28d6511@oracle.com> Can we also not use MAX_INT for the drawImage test case? Either have the drawImage follow the clip around or choose an appropriate non-limit size to cover the worst case scale with some margin for error... ...jim On 10/10/16 12:45 PM, Sergey Bylokhov wrote: > An updated version: > http://cr.openjdk.java.net/~serb/8167310/webrev.03 > - STROKE_PURE is used in the test, the line width is set to 2.01. This also fixed the difference between clips(Shape vs > Rectangle). > - The if statement is changed as suggested. > > The additional questions: > - In the current fix we change behavior of the clip. Before the fix if we set the clip to the nearest areas they can > overlaps in the destination. Should we change the drawImage as well? Currently if I draw image to the nearest areas in > the user space, the images can overlap in the destination(so the actual result in destination depends on what image was > painted first). > - Should the clip be affected by the stroke(if it was set by the shape)? Right now if the clip was set by the shape it > will produce different result than if it was set via rectangle. > > On 10.10.16 22:29, Jim Graham wrote: >> That does sound like a problem. Does it do the same thing with new >> Path2D(Rectangle)? The Area class does some processing on the path and >> it would be nice to eliminate that as a potential source of this >> problem. I don't have a buildable JDK9 repo right now that I can fire >> off some quick tests on so I'll have to look at this later... >> >> ...jim >> >> On 10/10/16 12:04 PM, Sergey Bylokhov wrote: >>> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>>> Will give us a pass on the test as long as we made the same mistake for >>>>> both the rect clip and the shape clip. I think you want "(rgb != >>>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>>> >>>> Correct, I will update the test. >>> >>> surprisingly but it is produce the different results.... And I think >>> that the clip which is set via Shape is shifted, >>> because the first and last fillRects cover only the half of expected >>> area. But in case of clip=rectangle all fillRects >>> produce the same areas. >>> >>> > > From philip.race at oracle.com Mon Oct 10 22:23:53 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 10 Oct 2016 15:23:53 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> Message-ID: <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> On 10/10/2016 01:34 PM, Jim Graham wrote: > [CC'ing Phil in case he has some suggestions for how the API should > work...] > > Responding just to additional questions in this email... > > On 10/10/16 12:45 PM, Sergey Bylokhov wrote: >> The additional questions: >> - In the current fix we change behavior of the clip. Before the fix >> if we set the clip to the nearest areas they can >> overlaps in the destination. Should we change the drawImage as well? >> Currently if I draw image to the nearest areas in >> the user space, the images can overlap in the destination(so the >> actual result in destination depends on what image was >> painted first). > > Yes, I think adjacent drawImage requests should not overlap. We > should look into this separately. So previously, overlapping of the clip bounds ensured adjacent images were not drawn over-lapped .. but with this fix they might be ? > >> - Should the clip be affected by the stroke(if it was set by the >> shape)? Right now if the clip was set by the shape it >> will produce different result than if it was set via rectangle. > > I think we could have the clip never be affected by STROKE_NORMALIZE. > That might make sense because the NORMALIZE code is meant to deal with > aesthetic issues, not rendering math issues. We'd have to add a > getClipSSI() method that hard-codes the "adjust" boolean to "false" to > do that, but that is an easy fix. > > The question is then that would meant that setClip(Shape) and > fill(Shape) might disagree, though. This would argue that we should > have it affected by the normalization. This is also a fairly easy > fix, you could have LoopPipe have a method that would return the > appropriate Rectangle representing which pixels are covered for a > given Rectangle2D depending on the normalize parameters. > > On the other hand, we normalize differently for AA and non-AA. Calling > getFillSSI() on LoopPipe basically performs normalization only for > non-AA fills. Arguably, though, clipping produces non-AA results in > that it chooses whole pixels to include or exclude. This might mean > that it should never follow AA normalization. That last sentence sounds like the right answer in principle but I don't know if we'll be unpleasantly surprised by some consequence of "... that setClip(Shape) and fill(Shape) might disagree .." -phil. > But, it also points out the silliness of normalizing to match the > results of fill when it can never do that for AA mode. (Potentially > we could add an AA-clip mode, but the implementation of that would > require capturing every rendering operation to an intermediate buffer > and then pixel-filtering it through a mask created by AA-filling the > clip shape - we do that in FX, but it would require major surgery to > add that to the SG2D pipeline so I don't think we would ever consider > that at this stage.) > > Any of those solutions are fairly easy to fix (except adding an AA > clipping mode), but the question is which is more useful and/or > surprises the developers the least. > > So we have the current case: > > setClip(integers or int-Rectangle) => pure coverage > setClip(other shape) => non-AA normalized coverage > > If we decide that clip should normalize always to non-AA parameters > because it is an intrinsically non-AA type of operation then we have > to fix the setClip(integer rectangle) code which isn't hard. > > If we decide that clip should normalize to the current AA parameters > then it's basically the same, but we need to find a way to query the > right objects to perform the AA according to their chosen bias. > LoopPipe/ShapeSpanIterator appear to own non-AA normalization and I > think AA normalization is hidden behind the TileGenerator API > somewhere that Ductus/Pisces/Marlin all implement. > > If we decide that clip should not normalize then we only have to fix > setClip(other shape) and it's just a question of hard-coding the > adjust boolean in the call to instantiate the ShapeSpanIterator. > > Phil? > > ...jim From Sergey.Bylokhov at oracle.com Mon Oct 10 22:53:34 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Oct 2016 01:53:34 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> Message-ID: On 11.10.16 1:23, Phil Race wrote: >> Yes, I think adjacent drawImage requests should not overlap. We >> should look into this separately. > > So previously, overlapping of the clip bounds ensured adjacent images > were not drawn > over-lapped .. but with this fix they might be ? The fix change only behavior of the rectangle clip. So using the setClip we can prevent overlaping of the images. But i think that even without clip such images should not overlap. >> On the other hand, we normalize differently for AA and non-AA. Calling >> getFillSSI() on LoopPipe basically performs normalization only for >> non-AA fills. Arguably, though, clipping produces non-AA results in >> that it chooses whole pixels to include or exclude. This might mean >> that it should never follow AA normalization. > > That last sentence sounds like the right answer in principle but I don't > know if we'll be unpleasantly surprised > by some consequence of "... that setClip(Shape) and fill(Shape) might > disagree .." I just tested fillRect vs fill(RectShape), and both work differently in some cases as well-=((. So we have a few similar methods which works differently(even if VALUE_STROKE_PURE is set), which became visible on fractional(1.5) scales.... - setClip(Rectangle) - setClip(Shape) - fillRect(Rectangle) - fill(Shape) - DrawImage(Rectangle) -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Oct 10 23:37:40 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Oct 2016 02:37:40 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <39f92c44-2419-4f95-2846-4d78d28d6511@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39f92c44-2419-4f95-2846-4d78d28d6511@oracle.com> Message-ID: <4508e71f-9bf0-6f3f-8c15-d3cd64d760e8@oracle.com> On 10.10.16 23:42, Jim Graham wrote: > Can we also not use MAX_INT for the drawImage test case? Either have > the drawImage follow the clip around or choose an appropriate non-limit > size to cover the worst case scale with some margin for error... Something like this? http://cr.openjdk.java.net/~serb/8167310/webrev.04 > On 10/10/16 12:45 PM, Sergey Bylokhov wrote: >> An updated version: >> http://cr.openjdk.java.net/~serb/8167310/webrev.03 >> - STROKE_PURE is used in the test, the line width is set to 2.01. >> This also fixed the difference between clips(Shape vs >> Rectangle). >> - The if statement is changed as suggested. >> >> The additional questions: >> - In the current fix we change behavior of the clip. Before the fix >> if we set the clip to the nearest areas they can >> overlaps in the destination. Should we change the drawImage as well? >> Currently if I draw image to the nearest areas in >> the user space, the images can overlap in the destination(so the >> actual result in destination depends on what image was >> painted first). >> - Should the clip be affected by the stroke(if it was set by the >> shape)? Right now if the clip was set by the shape it >> will produce different result than if it was set via rectangle. >> >> On 10.10.16 22:29, Jim Graham wrote: >>> That does sound like a problem. Does it do the same thing with new >>> Path2D(Rectangle)? The Area class does some processing on the path and >>> it would be nice to eliminate that as a potential source of this >>> problem. I don't have a buildable JDK9 repo right now that I can fire >>> off some quick tests on so I'll have to look at this later... >>> >>> ...jim >>> >>> On 10/10/16 12:04 PM, Sergey Bylokhov wrote: >>>> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>>>> Will give us a pass on the test as long as we made the same >>>>>> mistake for >>>>>> both the rect clip and the shape clip. I think you want "(rgb != >>>>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>>>> >>>>> Correct, I will update the test. >>>> >>>> surprisingly but it is produce the different results.... And I think >>>> that the clip which is set via Shape is shifted, >>>> because the first and last fillRects cover only the half of expected >>>> area. But in case of clip=rectangle all fillRects >>>> produce the same areas. >>>> >>>> >> >> -- Best regards, Sergey. From james.graham at oracle.com Tue Oct 11 18:32:55 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 11 Oct 2016 11:32:55 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> Message-ID: <734d9113-0c14-15ed-2c6c-e0a139065cfd@oracle.com> On 10/10/16 3:53 PM, Sergey Bylokhov wrote: > On 11.10.16 1:23, Phil Race wrote: >>> Yes, I think adjacent drawImage requests should not overlap. We >>> should look into this separately. >> >> So previously, overlapping of the clip bounds ensured adjacent images >> were not drawn >> over-lapped .. but with this fix they might be ? > > The fix change only behavior of the rectangle clip. So using the setClip we can prevent overlaping of the images. But i > think that even without clip such images should not overlap. I'm pretty sure that setClip(x,y,w,h) would ensure adjacency (no overlaps and no gaps) with another call to itself with adjacent parameters. And setClip(RectShape) would also ensure proper adjacency with itself. But, I think we had cases before this fix where setClip(x,y,w,h) could violate proper adjacency with setClip(RectShape). This fix addresses most of that, particularly it works if we have STROKE_PURE. I believe that it still has issues with STROKE_NORMALIZE, though, because one of them honors it and the other doesn't. So, we need to have them both honor the STROKE_CONTROL in the same way. >>> On the other hand, we normalize differently for AA and non-AA. Calling >>> getFillSSI() on LoopPipe basically performs normalization only for >>> non-AA fills. Arguably, though, clipping produces non-AA results in >>> that it chooses whole pixels to include or exclude. This might mean >>> that it should never follow AA normalization. >> >> That last sentence sounds like the right answer in principle but I don't >> know if we'll be unpleasantly surprised >> by some consequence of "... that setClip(Shape) and fill(Shape) might >> disagree .." > > I just tested fillRect vs fill(RectShape), and both work differently in some cases as well-=((. > So we have a few similar methods which works differently(even if VALUE_STROKE_PURE is set), which became visible on > fractional(1.5) scales.... > - setClip(Rectangle) > - setClip(Shape) > - fillRect(Rectangle) > - fill(Shape) > - DrawImage(Rectangle) I'd like to see which cases cause differences. The main one that I can see by a brief examination of the code is the case of non-integer translations (but no scale). I think we end up using the simplified FillRect primitives in the case of a non-integer translate, and that can cause a difference in effect. We could fix SurfaceData's validation to not use the primitive pipeline unless the translation is integer, but that could cost performance for that case. I'm not sure how often a non-integer translation with no other transform elements (i.e. scale) occurs, though. We could teach the FillRect primitive (or its caller) to adjust for the STROKE_CONTROL more properly in the case of a non-integer translation, but I'm not sure how often that will come into play and benefit us. Also, this might be fixable in the code that comes up with sg2d.transXY, which probably doesn't take STROKE hint into account... ...jim From james.graham at oracle.com Tue Oct 11 18:54:10 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 11 Oct 2016 11:54:10 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> Message-ID: <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> On 10/10/16 3:23 PM, Phil Race wrote: > That last sentence sounds like the right answer in principle but I don't know if we'll be unpleasantly surprised > by some consequence of "... that setClip(Shape) and fill(Shape) might disagree .." > > -phil. As I was thinking more about this last night we have additional issues to consider. Our rasterization rules bend a bit under STROKE_CONTROL and they do so differently for AA and non-AA. Really STROKE_CONTROL was a bandaid for the fact that the suddenly specific rasterization rules we created with the 2D API didn't necessarily match what developers had been used to and so we'd need some time for them to adjust. In particular, a common misunderstanding is that "drawLine(X,0,X,h)" would fill in all of the pixels in the X column, but in AA this would not work right as it would fill half of (coverage-wise 50% blending) the pixels to the right of X and half of the pixels to the left of X and look fuzzy. Similarly, exact insideness rules meant that even with non-AA and a line width of 1, technically the outline for that "line" would suggest that the pixels in the column to the left of X would be drawn. In retrospect, we should have been advising developers to wean themselves off of STROKE_NORMALIZE adjustments from the release of Java 2, but we dropped that ball. :( To be fair, though, these issues had been common in dealing with other rendering systems, like Postscript - but how many developers have ever written Postscript code themselves? Now with JavaFX we no longer have STROKE_CONTROL at all and we honor the strict rasterization rules that Java2D should be honoring under STROKE_PURE and so developers must learn how to be more selective in how the render things from their first exposure to FX. So, the ins and outs of dealing with the specific rasterization rules (things like where to center lines, and manually snapping to pixels because "ints" don't do it pseudo-automatically for you) should be becoming part of the developer experience with FX. I'm not sure how much that will help in Swing/AWT when Java2D has had NORMALIZE rules as default for a couple of decades. The rules for STROKE_NORMALIZE were created so that fills and strokes would match and be non-surprising for both AA and non-AA modes, but the rules needed were different for the 2 modes. Having different rules was fine because nobody would expect someone to draw a shape with non-AA and then fill it with AA or vice versa. It is very much expected that the AA hint would stay the same for both a fill and a draw of a shape. But, will the AA hint (or even the STROKE hint) stay the same for both the setting of a clip shape and the rendering of items in it? How often is clip(someShape) followed by draw(sameShape) or fill(sameShape)? Would a developer believe that the hints would affect the clip and so they would do the clip adjustment first and then set all of their "rendering hints"? (Note that these are called "RenderingHints", though if I were to come up with a clip-specific hint I would have no qualms adding it to the bag of hints in the RH class...) Additionally, for AA rendering, there is no such thing as "setClip(someShape)" and "fill(sameShape)" being identical no matter how much we predict which rules they may want because clips are inherently non-AA and so the fuzzy pixels along the boundary of an AA shape will be randomly clipped or included. When all is said and done I feel (not very strongly) it would be best to have clipping remain unaffected by the biasing of STROKE hints, but part of that is driven by the fact that I think it can be fixed with a couple of lines of code in SG2D/LoopPipe... ...jim From Sergey.Bylokhov at oracle.com Tue Oct 11 19:13:38 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 11 Oct 2016 22:13:38 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> Message-ID: <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> On 11.10.16 21:54, Jim Graham wrote: > Additionally, for AA rendering, there is no such thing as > "setClip(someShape)" and "fill(sameShape)" being identical no matter how > much we predict which rules they may want because clips are inherently > non-AA and so the fuzzy pixels along the boundary of an AA shape will be > randomly clipped or included. > > When all is said and done I feel (not very strongly) it would be best to > have clipping remain unaffected by the biasing of STROKE hints, but part > of that is driven by the fact that I think it can be fixed with a couple > of lines of code in SG2D/LoopPipe... I guess a bottom line is that it is require an additional investigation. I am not exactly sure, but my expectation is that fillRect(x,y,w,h)/drawImage(x,y,w,h) + setClip(x,y,w,h) should work in a similar way(covers the same pixels). And the question should this behavior be exactly the same as fill(RectShape) + setClip(RectShape) is unclear (I am not sure is it a critical issue or not) Right now I tried to fix overlapping, which produce visible artifacts and were considered as a bugs. The next issue which I would like to fix is a overlapping of drawImage(). -- Best regards, Sergey. From james.graham at oracle.com Tue Oct 11 19:49:00 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 11 Oct 2016 12:49:00 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> Message-ID: <14712409-7fe5-16d7-5214-440fc65d5bf9@oracle.com> On 10/11/16 12:13 PM, Sergey Bylokhov wrote: > On 11.10.16 21:54, Jim Graham wrote: >> Additionally, for AA rendering, there is no such thing as >> "setClip(someShape)" and "fill(sameShape)" being identical no matter how >> much we predict which rules they may want because clips are inherently >> non-AA and so the fuzzy pixels along the boundary of an AA shape will be >> randomly clipped or included. >> >> When all is said and done I feel (not very strongly) it would be best to >> have clipping remain unaffected by the biasing of STROKE hints, but part >> of that is driven by the fact that I think it can be fixed with a couple >> of lines of code in SG2D/LoopPipe... > > I guess a bottom line is that it is require an additional investigation. I am not exactly sure, but my expectation is > that fillRect(x,y,w,h)/drawImage(x,y,w,h) + setClip(x,y,w,h) should work in a similar way(covers the same pixels). And > the question should this behavior be exactly the same as fill(RectShape) + setClip(RectShape) is unclear (I am not sure > is it a critical issue or not) In STROKE_PURE, setClip/fillRect/drawImage(x,y,w,h) should all hit the same pixels. I think we currently have a bug with drawImage() that needs to be investigated further, though. The fact that it overlaps with itself is problematic and likely an indication that it won't match fillRect() either. Under STROKE_NORMALIZE, fillRect() and fill(Rect) are affected due to their relationship to drawRect()/fill(Rect). It's not clear if it should be identical to clipRect() and clip(Rect), though as I don't know where we'd have developers relying on that. In particular, damage repair would usually involve clip(dmgxywh) followed by fill(compxywh) and so they wouldn't necessarily need to match. drawImage() brings up additional questions. For now I think we can ignore this issue for this fix, but I still have a question on the fix which I'll ask in response to webrev.04. We should file the "clipRect() vs clip(RectShape)" bug for follow-on work. > Right now I tried to fix overlapping, which produce visible artifacts and were considered as a bugs. The next issue > which I would like to fix is a overlapping of drawImage(). Yes, that bears investigation... ...jim From james.graham at oracle.com Tue Oct 11 20:10:51 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 11 Oct 2016 13:10:51 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <4508e71f-9bf0-6f3f-8c15-d3cd64d760e8@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39f92c44-2419-4f95-2846-4d78d28d6511@oracle.com> <4508e71f-9bf0-6f3f-8c15-d3cd64d760e8@oracle.com> Message-ID: <769c1f08-cd44-9442-d1fd-1696e2a299a4@oracle.com> One last thing. In the clipRound() method you mention that NaN evaluates to 0. I assume that is just an observation that we'd end up in the "(int) ceil()" case and the cast returns a 0. In the case of a path we omit NaN coordinates, which means skipping segments in a path until they become sane again. That would likely turn a rectangle into a triangle if it happened in a shape, but in a Rectangle object the NaN ends up affecting more than one corner (minX is the coordinate of 2 corners, maxX is the coordinate for 2 corners, same for Y) and it degenerates further into an empty shape in all cases. For example: (x, y, w, h) 10, 10, NaN, 20 path is 10,10 => NaN,10 => NaN,30 => 10,30 => 2 points eliminated => devolves to a vertical line => no pixels included 10, 10, 20, NaN path is 10,10 => 30,10 => 30,NaN => 10,NaN => 2 points, devolves NaN, 10, 20, 20 path is NaN,10 => NaN,10 => NaN,30 => NaN,30 => no points left => completely degenerate 10, NaN, 20, 20 path is 10,NaN => 30,NaN => 30,NaN => 10,NaN => no points, degenerate In the case of NaN in X and Y, the clipRound() method would end up returning 0 for both min and max of X or Y which would hopefully produce an empty region when we do the intersection. In the case of NaN as a W or H, clipRound() would only produce a 0 for maxX or maxY, but the min would still be computed correctly. I guess this could technically be considered an empty shape in practice since we tend to use Regions to only encompass pixels in a non-negative space, so it is fine in practice, but if we ever use translated Regions for some sort of use (what about shaped components which might use Region?) then 0 for maxX or maxY might be paired with a negative value for minX or minY and end up with a non-empty Region in the negative coordinates (and potentially translated later to positive coordinates and encompass some pixels on a destination drawable). All of those would (should?) return a completely empty region if we rasterized the shape, so we should set an empty clip if we get a NaN in any coordinate... ...jim On 10/10/16 4:37 PM, Sergey Bylokhov wrote: > On 10.10.16 23:42, Jim Graham wrote: >> Can we also not use MAX_INT for the drawImage test case? Either have >> the drawImage follow the clip around or choose an appropriate non-limit >> size to cover the worst case scale with some margin for error... > > Something like this? > http://cr.openjdk.java.net/~serb/8167310/webrev.04 > > >> On 10/10/16 12:45 PM, Sergey Bylokhov wrote: >>> An updated version: >>> http://cr.openjdk.java.net/~serb/8167310/webrev.03 >>> - STROKE_PURE is used in the test, the line width is set to 2.01. >>> This also fixed the difference between clips(Shape vs >>> Rectangle). >>> - The if statement is changed as suggested. >>> >>> The additional questions: >>> - In the current fix we change behavior of the clip. Before the fix >>> if we set the clip to the nearest areas they can >>> overlaps in the destination. Should we change the drawImage as well? >>> Currently if I draw image to the nearest areas in >>> the user space, the images can overlap in the destination(so the >>> actual result in destination depends on what image was >>> painted first). >>> - Should the clip be affected by the stroke(if it was set by the >>> shape)? Right now if the clip was set by the shape it >>> will produce different result than if it was set via rectangle. >>> >>> On 10.10.16 22:29, Jim Graham wrote: >>>> That does sound like a problem. Does it do the same thing with new >>>> Path2D(Rectangle)? The Area class does some processing on the path and >>>> it would be nice to eliminate that as a potential source of this >>>> problem. I don't have a buildable JDK9 repo right now that I can fire >>>> off some quick tests on so I'll have to look at this later... >>>> >>>> ...jim >>>> >>>> On 10/10/16 12:04 PM, Sergey Bylokhov wrote: >>>>> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>>>>> Will give us a pass on the test as long as we made the same >>>>>>> mistake for >>>>>>> both the rect clip and the shape clip. I think you want "(rgb != >>>>>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>>>>> >>>>>> Correct, I will update the test. >>>>> >>>>> surprisingly but it is produce the different results.... And I think >>>>> that the clip which is set via Shape is shifted, >>>>> because the first and last fillRects cover only the half of expected >>>>> area. But in case of clip=rectangle all fillRects >>>>> produce the same areas. >>>>> >>>>> >>> >>> > > From james.graham at oracle.com Tue Oct 11 20:12:21 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 11 Oct 2016 13:12:21 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <4508e71f-9bf0-6f3f-8c15-d3cd64d760e8@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39f92c44-2419-4f95-2846-4d78d28d6511@oracle.com> <4508e71f-9bf0-6f3f-8c15-d3cd64d760e8@oracle.com> Message-ID: <428c5e29-8c80-8115-b0de-5351c30e85eb@oracle.com> Also, is it worth having a protective test for Rectangle in the intersect(Rectangle2D) method to avoid all of the double math when the rectangle was already an integer one? ...jim On 10/10/16 4:37 PM, Sergey Bylokhov wrote: > On 10.10.16 23:42, Jim Graham wrote: >> Can we also not use MAX_INT for the drawImage test case? Either have >> the drawImage follow the clip around or choose an appropriate non-limit >> size to cover the worst case scale with some margin for error... > > Something like this? > http://cr.openjdk.java.net/~serb/8167310/webrev.04 > > >> On 10/10/16 12:45 PM, Sergey Bylokhov wrote: >>> An updated version: >>> http://cr.openjdk.java.net/~serb/8167310/webrev.03 >>> - STROKE_PURE is used in the test, the line width is set to 2.01. >>> This also fixed the difference between clips(Shape vs >>> Rectangle). >>> - The if statement is changed as suggested. >>> >>> The additional questions: >>> - In the current fix we change behavior of the clip. Before the fix >>> if we set the clip to the nearest areas they can >>> overlaps in the destination. Should we change the drawImage as well? >>> Currently if I draw image to the nearest areas in >>> the user space, the images can overlap in the destination(so the >>> actual result in destination depends on what image was >>> painted first). >>> - Should the clip be affected by the stroke(if it was set by the >>> shape)? Right now if the clip was set by the shape it >>> will produce different result than if it was set via rectangle. >>> >>> On 10.10.16 22:29, Jim Graham wrote: >>>> That does sound like a problem. Does it do the same thing with new >>>> Path2D(Rectangle)? The Area class does some processing on the path and >>>> it would be nice to eliminate that as a potential source of this >>>> problem. I don't have a buildable JDK9 repo right now that I can fire >>>> off some quick tests on so I'll have to look at this later... >>>> >>>> ...jim >>>> >>>> On 10/10/16 12:04 PM, Sergey Bylokhov wrote: >>>>> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>>>>> Will give us a pass on the test as long as we made the same >>>>>>> mistake for >>>>>>> both the rect clip and the shape clip. I think you want "(rgb != >>>>>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>>>>> >>>>>> Correct, I will update the test. >>>>> >>>>> surprisingly but it is produce the different results.... And I think >>>>> that the clip which is set via Shape is shifted, >>>>> because the first and last fillRects cover only the half of expected >>>>> area. But in case of clip=rectangle all fillRects >>>>> produce the same areas. >>>>> >>>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Tue Oct 11 23:32:30 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Oct 2016 02:32:30 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <428c5e29-8c80-8115-b0de-5351c30e85eb@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39f92c44-2419-4f95-2846-4d78d28d6511@oracle.com> <4508e71f-9bf0-6f3f-8c15-d3cd64d760e8@oracle.com> <428c5e29-8c80-8115-b0de-5351c30e85eb@oracle.com> Message-ID: <1851b9ed-f383-026b-e019-6aab0ea0b407@oracle.com> On 11.10.16 23:12, Jim Graham wrote: > Also, is it worth having a protective test for Rectangle in the > intersect(Rectangle2D) method to avoid all of the double math when the > rectangle was already an integer one? Yes, this code can be moved from SunGraphics2D: http://cr.openjdk.java.net/~serb/8167310/webrev.05 + isNaN checks were added > > ...jim > > On 10/10/16 4:37 PM, Sergey Bylokhov wrote: >> On 10.10.16 23:42, Jim Graham wrote: >>> Can we also not use MAX_INT for the drawImage test case? Either have >>> the drawImage follow the clip around or choose an appropriate non-limit >>> size to cover the worst case scale with some margin for error... >> >> Something like this? >> http://cr.openjdk.java.net/~serb/8167310/webrev.04 >> >> >>> On 10/10/16 12:45 PM, Sergey Bylokhov wrote: >>>> An updated version: >>>> http://cr.openjdk.java.net/~serb/8167310/webrev.03 >>>> - STROKE_PURE is used in the test, the line width is set to 2.01. >>>> This also fixed the difference between clips(Shape vs >>>> Rectangle). >>>> - The if statement is changed as suggested. >>>> >>>> The additional questions: >>>> - In the current fix we change behavior of the clip. Before the fix >>>> if we set the clip to the nearest areas they can >>>> overlaps in the destination. Should we change the drawImage as well? >>>> Currently if I draw image to the nearest areas in >>>> the user space, the images can overlap in the destination(so the >>>> actual result in destination depends on what image was >>>> painted first). >>>> - Should the clip be affected by the stroke(if it was set by the >>>> shape)? Right now if the clip was set by the shape it >>>> will produce different result than if it was set via rectangle. >>>> >>>> On 10.10.16 22:29, Jim Graham wrote: >>>>> That does sound like a problem. Does it do the same thing with new >>>>> Path2D(Rectangle)? The Area class does some processing on the path >>>>> and >>>>> it would be nice to eliminate that as a potential source of this >>>>> problem. I don't have a buildable JDK9 repo right now that I can fire >>>>> off some quick tests on so I'll have to look at this later... >>>>> >>>>> ...jim >>>>> >>>>> On 10/10/16 12:04 PM, Sergey Bylokhov wrote: >>>>>> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>>>>>> Will give us a pass on the test as long as we made the same >>>>>>>> mistake for >>>>>>>> both the rect clip and the shape clip. I think you want "(rgb != >>>>>>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>>>>>> >>>>>>> Correct, I will update the test. >>>>>> >>>>>> surprisingly but it is produce the different results.... And I think >>>>>> that the clip which is set via Shape is shifted, >>>>>> because the first and last fillRects cover only the half of expected >>>>>> area. But in case of clip=rectangle all fillRects >>>>>> produce the same areas. >>>>>> >>>>>> >>>> >>>> >> >> -- Best regards, Sergey. From james.graham at oracle.com Wed Oct 12 02:09:37 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 11 Oct 2016 19:09:37 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <1851b9ed-f383-026b-e019-6aab0ea0b407@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39f92c44-2419-4f95-2846-4d78d28d6511@oracle.com> <4508e71f-9bf0-6f3f-8c15-d3cd64d760e8@oracle.com> <428c5e29-8c80-8115-b0de-5351c30e85eb@oracle.com> <1851b9ed-f383-026b-e019-6aab0ea0b407@oracle.com> Message-ID: <37369ff8-068a-494c-2e60-5012f8685004@oracle.com> That looks good. +1 ...jim On 10/11/16 4:32 PM, Sergey Bylokhov wrote: > On 11.10.16 23:12, Jim Graham wrote: >> Also, is it worth having a protective test for Rectangle in the >> intersect(Rectangle2D) method to avoid all of the double math when the >> rectangle was already an integer one? > > Yes, this code can be moved from SunGraphics2D: > http://cr.openjdk.java.net/~serb/8167310/webrev.05 > + isNaN checks were added > >> >> ...jim >> >> On 10/10/16 4:37 PM, Sergey Bylokhov wrote: >>> On 10.10.16 23:42, Jim Graham wrote: >>>> Can we also not use MAX_INT for the drawImage test case? Either have >>>> the drawImage follow the clip around or choose an appropriate non-limit >>>> size to cover the worst case scale with some margin for error... >>> >>> Something like this? >>> http://cr.openjdk.java.net/~serb/8167310/webrev.04 >>> >>> >>>> On 10/10/16 12:45 PM, Sergey Bylokhov wrote: >>>>> An updated version: >>>>> http://cr.openjdk.java.net/~serb/8167310/webrev.03 >>>>> - STROKE_PURE is used in the test, the line width is set to 2.01. >>>>> This also fixed the difference between clips(Shape vs >>>>> Rectangle). >>>>> - The if statement is changed as suggested. >>>>> >>>>> The additional questions: >>>>> - In the current fix we change behavior of the clip. Before the fix >>>>> if we set the clip to the nearest areas they can >>>>> overlaps in the destination. Should we change the drawImage as well? >>>>> Currently if I draw image to the nearest areas in >>>>> the user space, the images can overlap in the destination(so the >>>>> actual result in destination depends on what image was >>>>> painted first). >>>>> - Should the clip be affected by the stroke(if it was set by the >>>>> shape)? Right now if the clip was set by the shape it >>>>> will produce different result than if it was set via rectangle. >>>>> >>>>> On 10.10.16 22:29, Jim Graham wrote: >>>>>> That does sound like a problem. Does it do the same thing with new >>>>>> Path2D(Rectangle)? The Area class does some processing on the path >>>>>> and >>>>>> it would be nice to eliminate that as a potential source of this >>>>>> problem. I don't have a buildable JDK9 repo right now that I can fire >>>>>> off some quick tests on so I'll have to look at this later... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 10/10/16 12:04 PM, Sergey Bylokhov wrote: >>>>>>> On 10.10.16 21:55, Sergey Bylokhov wrote: >>>>>>>>> Will give us a pass on the test as long as we made the same >>>>>>>>> mistake for >>>>>>>>> both the rect clip and the shape clip. I think you want "(rgb != >>>>>>>>> goldRGB) || (rgb != GREEN && rgb != RED)"...? >>>>>>>> >>>>>>>> Correct, I will update the test. >>>>>>> >>>>>>> surprisingly but it is produce the different results.... And I think >>>>>>> that the clip which is set via Shape is shifted, >>>>>>> because the first and last fillRects cover only the half of expected >>>>>>> area. But in case of clip=rectangle all fillRects >>>>>>> produce the same areas. >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Wed Oct 12 15:04:54 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Oct 2016 18:04:54 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice In-Reply-To: <9b21239f-651d-4c00-8a3b-2fe7cc68b147@default> References: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> <079b9aab-a737-4149-a6d3-d83c95e42dc2@default> <9b21239f-651d-4c00-8a3b-2fe7cc68b147@default> Message-ID: Looks fine. On 06.10.16 11:19, Jayathirth D V wrote: > Hi Phil, > > > > As discussed offline, I have updated test case to include check for > duplication of compression types for all ImageIO plugins. > > > > Please review the updated webrev at your convenience : > > http://cr.openjdk.java.net/~jdv/6294607/webrev.01/ > > > > Thanks, > > Jay > > > > *From:*Jayathirth D V > *Sent:* Wednesday, October 05, 2016 12:23 PM > *To:* Philip Race; 2d-dev > *Subject:* RE: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns > the same compression type twice > > > > Hi Phil, > > > > I have verified all plugins only GIF has this duplication problem. > > > > Thanks, > > Jay > > > > *From:*Phil Race > *Sent:* Tuesday, October 04, 2016 9:54 PM > *To:* Jayathirth D V; 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns > the same compression type twice > > > > This seems fine to me. Perhaps the test could be reworked to > look for any plugin that reports a duplicate compression type ? > That may be more useful as a test .. > > Is this the only plugin that exhibits such duplication ? > > -phil. > > On 10/04/2016 04:39 AM, Jayathirth D V wrote: > > Hi, > > > > Please review the following fix in JDK9 at your convenience: > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-6294607 > > > > Webrev : http://cr.openjdk.java.net/~jdv/6294607/webrev.00/ > > > > > Issue : When we call ImageWriteParam.getCompressionTypes() for GIF > it returns two compression types ?LZW? & ?lzw?. > > > > Root cause : Basically we support only LZW compression for GIF. In > ImageWriteParam, there are many places in specification where we > mention about multiple compression types. In case of GIF, since it > returns same compression type twice it would be misleading. > > > > Solution : Update GIFImageWriter to return only one compression type > string. > > > > Thanks, > > Jay > > > > > -- Best regards, Sergey. From philip.race at oracle.com Wed Oct 12 16:58:29 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Oct 2016 09:58:29 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods In-Reply-To: References: Message-ID: <12368946-58c8-bcdb-350b-ee2bc9aa7095@oracle.com> Looks fine to me. -phil. On 10/07/2016 01:48 AM, Jayathirth D V wrote: > > Hi, > > Please review the following fix in JDK9 at your convenience: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8167281 > > Webrev : http://cr.openjdk.java.net/~jdv/8167281/webrev.00/ > > > Issue : IIONodeList.item(index) and IIOMetadataNode. > getElementsByTagName(tag) are not following specification properly. > > Root cause : . IIOMetadataNode .getElementsByTagName(tag) returns > empty list for special input value ?*? and > IIONodeList.item(index)throws IndexOutOfBoundsException for index > equal to length of NodeList. > > Solution : IIOMetadataNode .getElementsByTagName(tag) should match all > tags for special input value ?*? and IIONodeList.item(index) should > return null if input index is equals to length of NodeList. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Oct 12 16:59:20 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Oct 2016 09:59:20 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice In-Reply-To: References: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> <079b9aab-a737-4149-a6d3-d83c95e42dc2@default> <9b21239f-651d-4c00-8a3b-2fe7cc68b147@default> Message-ID: +1 -phil. On 10/12/2016 08:04 AM, Sergey Bylokhov wrote: > Looks fine. > > On 06.10.16 11:19, Jayathirth D V wrote: >> Hi Phil, >> >> >> >> As discussed offline, I have updated test case to include check for >> duplication of compression types for all ImageIO plugins. >> >> >> >> Please review the updated webrev at your convenience : >> >> http://cr.openjdk.java.net/~jdv/6294607/webrev.01/ >> >> >> >> Thanks, >> >> Jay >> >> >> >> *From:*Jayathirth D V >> *Sent:* Wednesday, October 05, 2016 12:23 PM >> *To:* Philip Race; 2d-dev >> *Subject:* RE: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns >> the same compression type twice >> >> >> >> Hi Phil, >> >> >> >> I have verified all plugins only GIF has this duplication problem. >> >> >> >> Thanks, >> >> Jay >> >> >> >> *From:*Phil Race >> *Sent:* Tuesday, October 04, 2016 9:54 PM >> *To:* Jayathirth D V; 2d-dev >> *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns >> the same compression type twice >> >> >> >> This seems fine to me. Perhaps the test could be reworked to >> look for any plugin that reports a duplicate compression type ? >> That may be more useful as a test .. >> >> Is this the only plugin that exhibits such duplication ? >> >> -phil. >> >> On 10/04/2016 04:39 AM, Jayathirth D V wrote: >> >> Hi, >> >> >> >> Please review the following fix in JDK9 at your convenience: >> >> >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-6294607 >> >> >> >> Webrev : http://cr.openjdk.java.net/~jdv/6294607/webrev.00/ >> >> >> >> >> Issue : When we call ImageWriteParam.getCompressionTypes() for GIF >> it returns two compression types ?LZW? & ?lzw?. >> >> >> >> Root cause : Basically we support only LZW compression for GIF. In >> ImageWriteParam, there are many places in specification where we >> mention about multiple compression types. In case of GIF, since it >> returns same compression type twice it would be misleading. >> >> >> >> Solution : Update GIFImageWriter to return only one compression type >> string. >> >> >> >> Thanks, >> >> Jay >> >> >> >> >> > > From prasanta.sadhukhan at oracle.com Wed Oct 12 17:04:37 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 12 Oct 2016 22:34:37 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: 8167291:[TEST_BUG] javax/print/attribute/Services_getDocFl.java Message-ID: <57FE6D25.9070508@oracle.com> Hi All, Please review a small test bug fix to make sure postscript support variable is reset before new flavor postscript support is tested, so that if one service supports PS but a next one doesn't, it would not fail. Bug: https://bugs.openjdk.java.net/browse/JDK-8167291 hg diff test/javax/print/attribute/Services_getDocFl.java diff -r 58224e71ea72 test/javax/print/attribute/Services_getDocFl.java --- a/test/javax/print/attribute/Services_getDocFl.java Thu Sep 01 12:22:59 2016 -0700 +++ b/test/javax/print/attribute/Services_getDocFl.java Wed Oct 12 22:30:06 2016 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -28,7 +28,7 @@ /* * @test - * @bug 4901243 8040139 + * @bug 4901243 8040139 8167291 * @summary JPG, GIF, and PNG DocFlavors (URL) should be supported if Postscript is supported. * @run main Services_getDocFl */ @@ -58,6 +58,7 @@ pngImagesSupported = false; gifImagesSupported = false; jpgImagesSupported = false; + psSupported = false; for (int j=0; j References: <57FE6D25.9070508@oracle.com> Message-ID: +1 -phil. On 10/12/2016 10:04 AM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a small test bug fix to make sure postscript support > variable is reset before new flavor postscript support is tested, so > that if one service supports PS but a next one doesn't, it would not > fail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167291 > > hg diff test/javax/print/attribute/Services_getDocFl.java > diff -r 58224e71ea72 test/javax/print/attribute/Services_getDocFl.java > --- a/test/javax/print/attribute/Services_getDocFl.java Thu Sep 01 > 12:22:59 2016 -0700 > +++ b/test/javax/print/attribute/Services_getDocFl.java Wed Oct 12 > 22:30:06 2016 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2015, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -28,7 +28,7 @@ > > /* > * @test > - * @bug 4901243 8040139 > + * @bug 4901243 8040139 8167291 > * @summary JPG, GIF, and PNG DocFlavors (URL) should be supported if > Postscript is supported. > * @run main Services_getDocFl > */ > @@ -58,6 +58,7 @@ > pngImagesSupported = false; > gifImagesSupported = false; > jpgImagesSupported = false; > + psSupported = false; > for (int j=0; j System.out.println(flavors[j]); > > Regards > Prasanta From philip.race at oracle.com Wed Oct 12 17:32:59 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Oct 2016 10:32:59 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font always displays as regular - no bold or oblique. In-Reply-To: <2acc9e8c-6d34-912f-0859-bcc2284b7d98@oracle.com> References: <57F58745.7000601@oracle.com> <2acc9e8c-6d34-912f-0859-bcc2284b7d98@oracle.com> Message-ID: <64a24f7d-8fa3-a5c3-611f-8f4123e23e67@oracle.com> I haven't had any feed back on this. Any way here is my latest proposal which goes the more succinct route but tries to make it clear that logical fonts are affected. Can I get a "+1" from someone ? * Glyphs may not always be rendered with the requested properties (e.g, font * and style) due to platform limitations such as the absence of suitable * platform fonts to implement a logical font. *

BTW an update on the OSX issue that started this. It is looking very much like a platform renderer behaviour in that for Times Bold non-AA size 12 looks like Regular but size 13 (where we do all the same things) looks Bold. So an OS X oddity (or bug). At first it looked like its always the even sizes since 14 is also regular .. but then it turns out 16 looks bold (and different than 16 plain). So no obvious pattern. -phil. On 10/06/2016 09:52 AM, Phil Race wrote: > I've also had a suggestion to be more succinct and just add one line : > "Glyphs may not always be rendered with the requested properties (e.g, > font and style) > due to platform limitations such as absence of certain fonts". > > I'd be OK with either my wording or the above .. > > -phil. > > On 10/05/2016 04:05 PM, Philip Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8166034 >> >> Non-AA fonts aren't always being bolded on OS X. >> FWIW I believe this is in part a platform (OS) bug since it is >> terribly inconsistent >> across fonts and in some cases even sizes. >> >> So we need to look into why but it definitely isn't something that >> calls for changing the font used by the Motif L&F as proposed here >> http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006732.html >> >> >> And it calls out something I've seen a few times recently and I've >> documented some examples in the bug report. >> So we need to explain in the java.awt.Font spec. that sometimes >> we are beholden to the limits of the platform. >> >> Investigating specific issues then become quality bugs .. but not >> conformance ones. >> >> Added class description text below :- >> >> -phil. >> >> diff --git a/src/java.desktop/share/classes/java/awt/Font.java >> b/src/java.desktop/share/classes/java/awt/Font.java >> --- a/src/java.desktop/share/classes/java/awt/Font.java >> +++ b/src/java.desktop/share/classes/java/awt/Font.java >> @@ -154,6 +154,13 @@ >> * associated with a font face, each differing in size, style, >> transform >> * and font features. >> *

>> + * The visual rendering of all, or part of, one logical font >> vis-a-vis another >> + * may not always be different where there are limited suitable >> fonts available. >> + * The same is true for one style vis-a-vis another. This is generally >> + * due to one form or another of platform limitation or behavior. >> + * In the absence of such limitations a compliant implementation >> + * will render glyphs which exhibit the requested properties. >> + *

>> * The {@link GraphicsEnvironment#getAllFonts() getAllFonts} method >> * of the {@code GraphicsEnvironment} class returns an >> * array of all font faces available in the system. These font faces >> are > From Sergey.Bylokhov at oracle.com Wed Oct 12 17:41:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Oct 2016 20:41:43 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font always displays as regular - no bold or oblique. In-Reply-To: <64a24f7d-8fa3-a5c3-611f-8f4123e23e67@oracle.com> References: <57F58745.7000601@oracle.com> <2acc9e8c-6d34-912f-0859-bcc2284b7d98@oracle.com> <64a24f7d-8fa3-a5c3-611f-8f4123e23e67@oracle.com> Message-ID: On 12.10.16 20:32, Phil Race wrote: > Any way here is my latest proposal which goes the more succinct route but > tries to make it clear that logical fonts are affected. > Can I get a "+1" from someone ? > > * Glyphs may not always be rendered with the requested properties (e.g, > font > * and style) due to platform limitations such as the absence of suitable > * platform fonts to implement a logical font. > *

+1 > > > BTW an update on the OSX issue that started this. > It is looking very much like a platform renderer behaviour in that > for Times Bold non-AA size 12 looks like Regular but size 13 (where we do > all the same things) looks Bold. So an OS X oddity (or bug). > At first it looked like its always the even sizes since 14 is also > regular .. > but then it turns out 16 looks bold (and different than 16 plain). > So no obvious pattern. > > -phil. > > On 10/06/2016 09:52 AM, Phil Race wrote: >> I've also had a suggestion to be more succinct and just add one line : >> "Glyphs may not always be rendered with the requested properties (e.g, >> font and style) >> due to platform limitations such as absence of certain fonts". >> >> I'd be OK with either my wording or the above .. >> >> -phil. >> >> On 10/05/2016 04:05 PM, Philip Race wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8166034 >>> >>> Non-AA fonts aren't always being bolded on OS X. >>> FWIW I believe this is in part a platform (OS) bug since it is >>> terribly inconsistent >>> across fonts and in some cases even sizes. >>> >>> So we need to look into why but it definitely isn't something that >>> calls for changing the font used by the Motif L&F as proposed here >>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006732.html >>> >>> >>> And it calls out something I've seen a few times recently and I've >>> documented some examples in the bug report. >>> So we need to explain in the java.awt.Font spec. that sometimes >>> we are beholden to the limits of the platform. >>> >>> Investigating specific issues then become quality bugs .. but not >>> conformance ones. >>> >>> Added class description text below :- >>> >>> -phil. >>> >>> diff --git a/src/java.desktop/share/classes/java/awt/Font.java >>> b/src/java.desktop/share/classes/java/awt/Font.java >>> --- a/src/java.desktop/share/classes/java/awt/Font.java >>> +++ b/src/java.desktop/share/classes/java/awt/Font.java >>> @@ -154,6 +154,13 @@ >>> * associated with a font face, each differing in size, style, >>> transform >>> * and font features. >>> *

>>> + * The visual rendering of all, or part of, one logical font >>> vis-a-vis another >>> + * may not always be different where there are limited suitable >>> fonts available. >>> + * The same is true for one style vis-a-vis another. This is generally >>> + * due to one form or another of platform limitation or behavior. >>> + * In the absence of such limitations a compliant implementation >>> + * will render glyphs which exhibit the requested properties. >>> + *

>>> * The {@link GraphicsEnvironment#getAllFonts() getAllFonts} method >>> * of the {@code GraphicsEnvironment} class returns an >>> * array of all font faces available in the system. These font faces >>> are >> > -- Best regards, Sergey. From brian.burkhalter at oracle.com Wed Oct 12 18:14:27 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 12 Oct 2016 11:14:27 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same compression type twice In-Reply-To: References: <05b7e614-48ed-4a01-9649-1d1f9cb9d90a@default> <079b9aab-a737-4149-a6d3-d83c95e42dc2@default> <9b21239f-651d-4c00-8a3b-2fe7cc68b147@default> Message-ID: <11F6E212-5400-41C5-8639-8CF7B3E353C5@oracle.com> +2 Brian On Oct 12, 2016, at 9:59 AM, Phil Race wrote: > +1 > > -phil. > > On 10/12/2016 08:04 AM, Sergey Bylokhov wrote: >> Looks fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Oct 12 20:06:24 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 12 Oct 2016 13:06:24 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10 Message-ID: <57FE97C0.6010809@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8089573 Webrev : http://cr.openjdk.java.net/~prr/8089573/ See the bug for some images showing the problem of scrambled text when printing. Although only JavaFX is affected the solution is entirely on the JDK side. JavaFX looks up some UI "system" fonts via special API calls and these are fonts that are not otherwise enumerated by CoreText. JavaFX expects JDK to be able to access these fonts but it cannot. We need to make the same API calls on JDK. The exact fonts returned vary by MacOS release so it seems hard to create a JDK regression test but on the FX side it is seen instantly if you print a UI control as the text is messed up due to incorrect glyph ids. I intend to backport this to 8u and I've verified this does fix it on 8u too .. Also both 8 & 9 build successfully with JPRT. -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Thu Oct 13 02:05:21 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 12 Oct 2016 19:05:21 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <14712409-7fe5-16d7-5214-440fc65d5bf9@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> <14712409-7fe5-16d7-5214-440fc65d5bf9@oracle.com> Message-ID: On 10/11/16 12:49 PM, Jim Graham wrote: >> Right now I tried to fix overlapping, which produce visible artifacts and were considered as a bugs. The next issue >> which I would like to fix is a overlapping of drawImage(). > > Yes, that bears investigation... I looked into it and the issue is basically floating point bit error. Basically, in the test program we don't use a ScaledBlit because we don't have one defined for the combination of (IntArgb, SrcOver, IntArgb), since our ScaledBlit implementations are all for opaque images. The loop macros can't even create a non-opaque ScaledBlit without a bit of work. So, we end up in TransformHelper where we perform the blit by doing an inverse transform on the graphics transform and then use that to map back from destination pixels to the source pixels. The issue here is that with a scale of 1.5, the forward transform is a nice IEEE-floating-point spec compatible bit pattern, but inverting it gives a scale of 2/3s which doesn't have an exact IEEE representation. The result is that it marches through the image and the very last edge of that image maps to 10.5 which is an exact center of the pixel. If the math were perfect then we'd back-transform that coordinate into the source image and get 7.0 and that would be "past the right edge of the image" and we'd bail at that point. But, we back-transform it and get 6.99999 and we think "OK, this pixel just squeaks by and gets one last sample of the image before we fall off the edge of the image". But, this should not happen with 1:1 image copies. And it shouldn't happen when we have a ScaledBlit function since that uses more exact math without inverting the scale, but I haven't written a test case to verify that. And, it shouldn't happen with integer scales and scales where we don't have a situation of an image mapping to exactly (pixel+0.5). But, I don't think we can improve the pixel accuracy of our inverse transforms to handle this exact case without a lot of work... ...jim From prahalad.kumar.narayanan at oracle.com Thu Oct 13 06:20:14 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 12 Oct 2016 23:20:14 -0700 (PDT) Subject: [OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font Message-ID: +1 The wordings that mention: " ... absence of suitable platform fonts to implement a logical font ", is more appropriate. Thanks Have a good day Prahalad N. ------------------------------ Message: 4 Date: Wed, 12 Oct 2016 10:32:59 -0700 From: Phil Race To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] RFR: 8166034: [macosx] Non-AA Serif font always displays as regular - no bold or oblique. Message-ID: <64a24f7d-8fa3-a5c3-611f-8f4123e23e67 at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed I haven't had any feed back on this. Any way here is my latest proposal which goes the more succinct route but tries to make it clear that logical fonts are affected. Can I get a "+1" from someone ? * Glyphs may not always be rendered with the requested properties (e.g, font * and style) due to platform limitations such as the absence of suitable * platform fonts to implement a logical font. *

BTW an update on the OSX issue that started this. It is looking very much like a platform renderer behaviour in that for Times Bold non-AA size 12 looks like Regular but size 13 (where we do all the same things) looks Bold. So an OS X oddity (or bug). At first it looked like its always the even sizes since 14 is also regular .. but then it turns out 16 looks bold (and different than 16 plain). So no obvious pattern. -phil. On 10/06/2016 09:52 AM, Phil Race wrote: > I've also had a suggestion to be more succinct and just add one line : > "Glyphs may not always be rendered with the requested properties (e.g, > font and style) > due to platform limitations such as absence of certain fonts". > > I'd be OK with either my wording or the above .. > > -phil. > > On 10/05/2016 04:05 PM, Philip Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8166034 >> >> Non-AA fonts aren't always being bolded on OS X. >> FWIW I believe this is in part a platform (OS) bug since it is >> terribly inconsistent >> across fonts and in some cases even sizes. >> >> So we need to look into why but it definitely isn't something that >> calls for changing the font used by the Motif L&F as proposed here >> http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006732.html >> >> >> And it calls out something I've seen a few times recently and I've >> documented some examples in the bug report. >> So we need to explain in the java.awt.Font spec. that sometimes >> we are beholden to the limits of the platform. >> >> Investigating specific issues then become quality bugs .. but not >> conformance ones. >> >> Added class description text below :- >> >> -phil. >> >> diff --git a/src/java.desktop/share/classes/java/awt/Font.java >> b/src/java.desktop/share/classes/java/awt/Font.java >> --- a/src/java.desktop/share/classes/java/awt/Font.java >> +++ b/src/java.desktop/share/classes/java/awt/Font.java >> @@ -154,6 +154,13 @@ >> * associated with a font face, each differing in size, style, >> transform >> * and font features. >> *

>> + * The visual rendering of all, or part of, one logical font >> vis-a-vis another >> + * may not always be different where there are limited suitable >> fonts available. >> + * The same is true for one style vis-a-vis another. This is generally >> + * due to one form or another of platform limitation or behavior. >> + * In the absence of such limitations a compliant implementation >> + * will render glyphs which exhibit the requested properties. >> + *

>> * The {@link GraphicsEnvironment#getAllFonts() getAllFonts} method >> * of the {@code GraphicsEnvironment} class returns an >> * array of all font faces available in the system. These font faces >> are > From bourges.laurent at gmail.com Thu Oct 13 19:22:47 2016 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 13 Oct 2016 21:22:47 +0200 Subject: [OpenJDK 2D-Dev] Marlin vs OpenPisces In-Reply-To: References: Message-ID: Hi, I looked at openpisces enhancements in compare to pisces I forked in 2013.6 and noticed at least 2 important changes: - Dasher initialization: handle too small phase - Stroker: new cases for parallel directions between control points in quad / cubic curve subdivision I plan to upgrade Marlin in jdk9 to integrate those improvements. Is there OpenJFX bugs and tests to reproduce those complex situations ? Do you know other changes I should look at ? PS: this work is more a backport of bug fixes than enhancements to be accepted in jdk9, isn't it ? Thanks for your feedback, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Oct 13 20:05:48 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Oct 2016 13:05:48 -0700 Subject: [OpenJDK 2D-Dev] Marlin vs OpenPisces In-Reply-To: References: Message-ID: <335e449d-056b-2cfc-110a-5c9e86355406@oracle.com> On 10/13/2016 12:22 PM, Laurent Bourg?s wrote: > > Hi, > > I looked at openpisces enhancements in compare to pisces I forked in > 2013.6 and noticed at least 2 important changes: > - Dasher initialization: handle too small phase > - Stroker: new cases for parallel directions between control points > in quad / cubic curve subdivision > > I plan to upgrade Marlin in jdk9 to integrate those improvements. > Is there OpenJFX bugs and tests to reproduce those complex situations ? > Between FX having multiple source code restructuring, open-sourcing losing history and a change from not always using bug ids in the commit through a change in bug system .. and no strict requirements about regression tests it might be challenging to identify the bugs under which such changes were made. Maybe Jim can help a bit since he may have made or at least reviewed those changes. -phil. > Do you know other changes I should look at ? > > PS: this work is more a backport of bug fixes than enhancements to be > accepted in jdk9, isn't it ? > I think it is still acceptable for 9. -phil. > Thanks for your feedback, > Laurent > From james.graham at oracle.com Thu Oct 13 20:24:32 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Oct 2016 13:24:32 -0700 Subject: [OpenJDK 2D-Dev] Marlin vs OpenPisces In-Reply-To: <335e449d-056b-2cfc-110a-5c9e86355406@oracle.com> References: <335e449d-056b-2cfc-110a-5c9e86355406@oracle.com> Message-ID: <550948ec-09ca-99bb-501c-dc684500c480@oracle.com> I'm trying to track down the old history after a lot of file moves, but here is what I have so far: (Note that some of these only apply when we use it in non-AA mode where we set the number of subpixel samples to 1x1) https://bugs.openjdk.java.net/browse/JDK-8092682 (non-AA: changing BND constants) https://bugs.openjdk.java.net/browse/JDK-8094493 (needed for non-AA, but applicable to AA) https://bugs.openjdk.java.net/browse/JDK-8094313 (first attempt to use for both AA/non-AA) https://bugs.openjdk.java.net/browse/JDK-8088013 (fixed, then backed out, replaced by 8094313) https://bugs.openjdk.java.net/browse/JDK-8097787 (likely the dash fixes you noted below) https://bugs.openjdk.java.net/browse/JDK-8119693 (AIOOB in dash array growth) At that point, the files were moved from another repo during a huge open-sourcing effort so I'll need a little more digging to find further history. Also, I don't think there is any history for "changes that were made when we ported it from the JDK". I don't think there were any "bug fixes" during that work for the initial commit, though, so we can probably assume that the change logs (when I can find the pre-open-source list) were the sum total of all of the bug fixes... ...jim On 10/13/16 1:05 PM, Phil Race wrote: > > > On 10/13/2016 12:22 PM, Laurent Bourg?s wrote: >> >> Hi, >> >> I looked at openpisces enhancements in compare to pisces I forked in 2013.6 and noticed at least 2 important changes: >> - Dasher initialization: handle too small phase >> - Stroker: new cases for parallel directions between control points in quad / cubic curve subdivision >> >> I plan to upgrade Marlin in jdk9 to integrate those improvements. >> Is there OpenJFX bugs and tests to reproduce those complex situations ? >> > > Between FX having multiple source code restructuring, open-sourcing losing history and > a change from not always using bug ids in the commit through a change in > bug system .. and no strict requirements about regression tests it might be > challenging to identify the bugs under which such changes were made. > Maybe Jim can help a bit since he may have made or at least reviewed those changes. > > -phil. > >> Do you know other changes I should look at ? >> >> PS: this work is more a backport of bug fixes than enhancements to be accepted in jdk9, isn't it ? >> > > I think it is still acceptable for 9. > > -phil. > >> Thanks for your feedback, >> Laurent >> > From james.graham at oracle.com Thu Oct 13 21:06:02 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Oct 2016 14:06:02 -0700 Subject: [OpenJDK 2D-Dev] Marlin vs OpenPisces In-Reply-To: <550948ec-09ca-99bb-501c-dc684500c480@oracle.com> References: <335e449d-056b-2cfc-110a-5c9e86355406@oracle.com> <550948ec-09ca-99bb-501c-dc684500c480@oracle.com> Message-ID: Most of the pre-open-source changes are superseded by a single commit with the synopsis "Incorporate the latest pisces improvements from OpenJDK" and the associated bug (which is marked confidential because this code was not open-sourced at that time) says "Hey, Denis Lila did a whole lot of work on OpenPisces, we should integrate that into our Pisces!", so I think most of the work prior to the bugs I point out below was already visible in the version of Pisces that you started from in OpenJDK. The only bug fixing that seemed to occur after those "update from JDK" changesets was to fix "leaks", but the associated bug was more about transient garbage than true leaks and most of it was dealt with by reusing renderers and alpha arrays, but you've already dug through that in your early Marlin->FX investigations. So, I think the below list is reasonably comprehensive... ...jim On 10/13/16 1:24 PM, Jim Graham wrote: > I'm trying to track down the old history after a lot of file moves, but here is what I have so far: > > (Note that some of these only apply when we use it in non-AA mode where we set the number of subpixel samples to 1x1) > > https://bugs.openjdk.java.net/browse/JDK-8092682 (non-AA: changing BND constants) > https://bugs.openjdk.java.net/browse/JDK-8094493 (needed for non-AA, but applicable to AA) > https://bugs.openjdk.java.net/browse/JDK-8094313 (first attempt to use for both AA/non-AA) > https://bugs.openjdk.java.net/browse/JDK-8088013 (fixed, then backed out, replaced by 8094313) > https://bugs.openjdk.java.net/browse/JDK-8097787 (likely the dash fixes you noted below) > https://bugs.openjdk.java.net/browse/JDK-8119693 (AIOOB in dash array growth) > > At that point, the files were moved from another repo during a huge open-sourcing effort so I'll need a little more > digging to find further history. > > Also, I don't think there is any history for "changes that were made when we ported it from the JDK". I don't think > there were any "bug fixes" during that work for the initial commit, though, so we can probably assume that the change > logs (when I can find the pre-open-source list) were the sum total of all of the bug fixes... > > ...jim > > On 10/13/16 1:05 PM, Phil Race wrote: >> >> >> On 10/13/2016 12:22 PM, Laurent Bourg?s wrote: >>> >>> Hi, >>> >>> I looked at openpisces enhancements in compare to pisces I forked in 2013.6 and noticed at least 2 important changes: >>> - Dasher initialization: handle too small phase >>> - Stroker: new cases for parallel directions between control points in quad / cubic curve subdivision >>> >>> I plan to upgrade Marlin in jdk9 to integrate those improvements. >>> Is there OpenJFX bugs and tests to reproduce those complex situations ? >>> >> >> Between FX having multiple source code restructuring, open-sourcing losing history and >> a change from not always using bug ids in the commit through a change in >> bug system .. and no strict requirements about regression tests it might be >> challenging to identify the bugs under which such changes were made. >> Maybe Jim can help a bit since he may have made or at least reviewed those changes. >> >> -phil. >> >>> Do you know other changes I should look at ? >>> >>> PS: this work is more a backport of bug fixes than enhancements to be accepted in jdk9, isn't it ? >>> >> >> I think it is still acceptable for 9. >> >> -phil. >> >>> Thanks for your feedback, >>> Laurent >>> >> From prahalad.kumar.narayanan at oracle.com Fri Oct 14 06:18:35 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 13 Oct 2016 23:18:35 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods In-Reply-To: <8ee6b32a-8fb8-4a27-a07a-e82f33d83449@default> References: <12368946-58c8-bcdb-350b-ee2bc9aa7095@oracle.com> <8ee6b32a-8fb8-4a27-a07a-e82f33d83449@default> Message-ID: <22445bcf-1589-4eac-9d26-b1c17a71b884@default> The change looks good. +1 - Prahalad N. >From: Phil Race >Sent: Wednesday, October 12, 2016 10:28 PM >To: Jayathirth D V; 2d-dev >Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods > >Looks fine to me. > >-phil. > >>On 10/07/2016 01:48 AM, Jayathirth D V wrote: >>Hi, >>? >>Please review the following fix in JDK9 at your convenience: >>? >>Bug : https://bugs.openjdk.java.net/browse/JDK-8167281 >>? >>Webrev : http://cr.openjdk.java.net/~jdv/8167281/webrev.00/ >>? >>Issue : IIONodeList.item(index) and IIOMetadataNode. getElementsByTagName(tag) are not following specification properly. >>? >>Root cause : . IIOMetadataNode .getElementsByTagName(tag) returns empty list for special input value "*" and IIONodeList.item(index)throws IndexOutOfBoundsException for index >>equal to length of NodeList. >>? >>Solution : IIOMetadataNode .getElementsByTagName(tag) should match all tags for special input value "*" and IIONodeList.item(index) should return null if input index is equals to >>length >of NodeList. >>? >>Thanks, >>Jay From prahalad.kumar.narayanan at oracle.com Fri Oct 14 10:38:09 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Fri, 14 Oct 2016 03:38:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8165212 VolatileImage should not be compatible with GraphicsConfiguration which transform is changed Message-ID: <4d989226-9ef4-4d19-8e49-3f7fc2ba0c98@default> Hello Everyone Good day to you. Request your time in reviewing the fix for- Bug : JDK-8165212 Title : VolatileImage should not be compatible with GraphicsConfiguration which transform is changed Description on the bug- . As per the bug, Volatile Image's graphics configuration is not updated when the host machine display's DPI is changed at runtime (while still running the java app). In addition, the method contentsLost() does not return true when display's DPI is modified. . It is important to note that, the issue is not reproducible with D3D/OpenGL backend. It is reproducible with non-accelerated Volatile Image. Root Cause . A callback method- displayChanged() in VolatileSurfaceManager.java is invoked when display's settings (DPI) is modified. . The callback method, currently, updates the graphics configuration only for Accelerated volatile image. Graphics configuration is not updated for non-accelerated system memory based VolatileImage. . Until recently, there wasn't any need for updating graphics configuration for non-accelerated volatileImage. However, Win 8.1 and above provide feature to dynamically update the DPI setting (without requiring for log-off/ log-in), which causes the current bug. Bug Fix . First, the callback method is modified to update graphics configuration for non-accelerated volatile image also. . An update to graphics configuration might require re-creation of the surface. Especially, when the scale factor is increased. Hence the system memory based backupSurface is re-created here. . The above change is followed by change to Validate() API, so that the backup surface re-creation in displayChanged() method, correctly returns IMAGE_RESTORED from validate() API. This way, the code flow for non-accelerated Volatile Images behaves just the same way as accelerated volatile images. . Approximately 81 Jtreg test cases (that contained VolatileImage) were run on win7, linux, and osx. No new regressions have been found after the modification. . In addition, a manual test case has been provided to ensure the proper functioning of the fix Kindly review the changes and provide your suggestions Review link: http://cr.openjdk.java.net/~pnarayanan/8165212/webrev.00/ Thank you for your time in review Have a good day Prahalad N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Oct 16 16:09:29 2016 From: philip.race at oracle.com (Philip Race) Date: Sun, 16 Oct 2016 09:09:29 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10 In-Reply-To: <57FE97C0.6010809@oracle.com> References: <57FE97C0.6010809@oracle.com> Message-ID: <5803A639.9000607@oracle.com> Anyone ? I'd like to get this backported to 8u this week so it can the 8u122 release which will enter RDP2 soon http://openjdk.java.net/projects/jdk8u/releases/8u122.html Although I have failed to find any email documenting the exact date the freeze is usually a week earlier than the RDP date so it could be as early as a week from now .. -phil. On 10/12/16, 1:06 PM, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8089573 > Webrev : http://cr.openjdk.java.net/~prr/8089573/ > > See the bug for some images showing the problem of scrambled text > when printing. > > Although only > JavaFX is affected the solution is entirely on the JDK side. > > JavaFX looks up some UI "system" fonts via special API calls and these > are fonts > that are not otherwise enumerated by CoreText. > JavaFX expects JDK to be able to access these fonts but it cannot. > We need to make the same API calls on JDK. > The exact fonts returned vary by MacOS release so it seems hard to > create a JDK regression > test but on the FX side it is seen instantly if you print a UI control > as the text is messed up > due to incorrect glyph ids. > > I intend to backport this to 8u and I've verified this does fix it on > 8u too .. > > Also both 8 & 9 build successfully with JPRT. > > -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Sun Oct 16 19:02:25 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sun, 16 Oct 2016 22:02:25 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10 In-Reply-To: <5803A639.9000607@oracle.com> References: <57FE97C0.6010809@oracle.com> <5803A639.9000607@oracle.com> Message-ID: I guess you could reorder the calls for CFRelease(font); and CFRelease(desc); so the desc gets released first in two locations under family == NULL and name == NULL. Just for the sake of consistency. Other than that, +1. Vadim On 16.10.2016 19:09, Philip Race wrote: > Anyone ? I'd like to get this backported to 8u this week so it > can the 8u122 release which will enter RDP2 soon > > http://openjdk.java.net/projects/jdk8u/releases/8u122.html > > Although I have failed to find any email documenting the exact date > the freeze is usually a week earlier than the RDP date so it could > be as early as a week from now .. > > -phil. > > On 10/12/16, 1:06 PM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8089573 >> Webrev : http://cr.openjdk.java.net/~prr/8089573/ >> >> See the bug for some images showing the problem of scrambled text >> when printing. >> >> Although only >> JavaFX is affected the solution is entirely on the JDK side. >> >> JavaFX looks up some UI "system" fonts via special API calls and >> these are fonts >> that are not otherwise enumerated by CoreText. >> JavaFX expects JDK to be able to access these fonts but it cannot. >> We need to make the same API calls on JDK. >> The exact fonts returned vary by MacOS release so it seems hard to >> create a JDK regression >> test but on the FX side it is seen instantly if you print a UI >> control as the text is messed up >> due to incorrect glyph ids. >> >> I intend to backport this to 8u and I've verified this does fix it on >> 8u too .. >> >> Also both 8 & 9 build successfully with JPRT. >> >> -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Oct 17 07:42:35 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 17 Oct 2016 00:42:35 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods In-Reply-To: <22445bcf-1589-4eac-9d26-b1c17a71b884@default> References: <12368946-58c8-bcdb-350b-ee2bc9aa7095@oracle.com> <8ee6b32a-8fb8-4a27-a07a-e82f33d83449@default> <22445bcf-1589-4eac-9d26-b1c17a71b884@default> Message-ID: <24a22501-4404-43db-9539-a5ca595a7335@default> Hi Phil & Prahalad, FYI. There was trailing space at line 885. I have removed the trailing space and checked in following webrev : http://cr.openjdk.java.net/~jdv/8167281/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, October 14, 2016 11:49 AM To: Jayathirth D V; Ajit Ghaisas; 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods The change looks good. +1 - Prahalad N. >From: Phil Race >Sent: Wednesday, October 12, 2016 10:28 PM >To: Jayathirth D V; 2d-dev >Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods > >Looks fine to me. > >-phil. > >>On 10/07/2016 01:48 AM, Jayathirth D V wrote: >>Hi, >>? >>Please review the following fix in JDK9 at your convenience: >>? >>Bug : https://bugs.openjdk.java.net/browse/JDK-8167281 >>? >>Webrev : http://cr.openjdk.java.net/~jdv/8167281/webrev.00/ >>? >>Issue : IIONodeList.item(index) and IIOMetadataNode. getElementsByTagName(tag) are not following specification properly. >>? >>Root cause : . IIOMetadataNode .getElementsByTagName(tag) returns empty list for special input value "*" and IIONodeList.item(index)throws IndexOutOfBoundsException for index >>equal to length of NodeList. >>? >>Solution : IIOMetadataNode .getElementsByTagName(tag) should match all tags for special input value "*" and IIONodeList.item(index) should return null if input index is equals to >>length >of NodeList. >>? >>Thanks, >>Jay From anton.tarasov at jetbrains.com Mon Oct 17 10:03:35 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Mon, 17 Oct 2016 13:03:35 +0300 Subject: [OpenJDK 2D-Dev] HiDPI support issues on Windows In-Reply-To: <18f1b0a7-1c08-f7d1-74da-14fc99e5c156@oracle.com> References: <8aedb1ba-f4cc-c4cc-0f0d-659bbbfab47d@jetbrains.com> <9520bad6-03d6-c035-4c60-760fe590e63e@oracle.com> <61d867c9-faf6-76f2-e46f-95db023be1e1@jetbrains.com> <07758c1e-876b-525c-edb3-f9ef3f663994@oracle.com> <18f1b0a7-1c08-f7d1-74da-14fc99e5c156@oracle.com> Message-ID: Thanks a lot, Jim! This sheds light on the subject and really sounds promising. Anton. On 10/6/2016 9:31 PM, Jim Graham wrote: > Ah, I see. > > There are a lot of mistaken assumptions in the rendering there. It's > not just line thickness, it is assumptions about stroke control and > positioning of strokes. > > The biggest issue seems to be that developers (including our own > internal Swing developers who heard this lecture from me decades ago, > but ignored it because it was inconvenient and not yet relevant at the > time) who use the integer-based draw commands assume that their lines > are centered on the pixel that they are naming. In other words "if I > draw a line along x=5 then I am telling the system to fill all the > pixels with an X coordinate of 5", but that is not what that drawing > request is asking for. The coordinates are at pixel edges and it is > an artifact of our fill/stroke rules and stroke control hinting that > has made this work out at 1:1 scaling. As soon as you scale you can > see the issues. We used to only scale for printing, but now we are > starting to scale for the screen. > > g.drawRect(0,0,w-1,h-1) is a completely disfunctional way to outline a > component with any settings other than 1:1 coordinates and > STROKE_CONTROL on. I've been mentioning this for years (going on > decades now), but Swing was addicted to that boilerplate for drawing a > border. Thankfully, FX and its CSS-focused skinning has gone with a > different mechanism (primarily most FX components are outlined using > successive fills - optimized in implementation to avoid overdrawing - > rather than using strokes based on mistaken assumptions about where > the line is drawn). > > In particular, the line in that example g.drawRect(0,0,w-1,h-1) > technically occurs at the following coordinates: > > outer part of outline goes from 0.0-0.5,0.0-0.5 to w-1+0.5,h-1+0.5 > (i.e. -0.5,-0.5 to w-0.5,h-0.5) > inner part of outline goes from 0.0+0.5,0.0+0.5 to w-1-0.5,h-1-0.5 > (i.e. +0.5,+0.5 to w-1.5,h-1.5) > > At a high enough scale you can see the stroke starting to separate > from the fill on the right and bottom edges where the closest it gets > to the edge is 0.5 scaled coordiantes. That rounds to 0 for 1:1 and > with the biasing from STROKE_CONTROL, but at higher resolutions it > becomes a non-zero number of pixels. > > Even at 1:1 scale if you follow our filling rules explicitly (which > would require setting STROKE_CONTROL to PURE) then that would fill the > rows at y=-1 and y=h-2 and the columns at x=-1 and x=w-2, which is not > what you want at all. Setting STROKE_CONTROL on allows us to bias the > location of the stroke a little and it ends up filling the correct > pixels as a side effect (though STROKE_CONTROL is meant to achieve > consistency in strokes, it also ends up shifting the line by enough > that the fill rules choose different pixels in this case). The > STROKE_CONTROL=on version of the path is assumed to be > (0.25,0.25,w-0.75,h-0.75) because we snap all coordinates in a > stroke-controlled non-AA path to the nearest location that is > 0.25,0.25 within a pixel. This snapping to a consistent sub-pixel > location biasing at 0.25 was chosen because line widths grow more > evenly at that offset, but it offsets the outline enough so that the > outline considered for filling becomes: > > outer part of outline goes from 0.25-0.5,0.25-0.5 to > 0.25+w-1+0.5,0.25+h-1+0.5 > (i.e. -0.25,-0.25 to w-0.25,h-0.25) > inner part of outline goes from 0.25+0.5,0.25+0.5 to > 0.25+w-1-0.5,0.25+h-1-0.5 > (i.e. +0.75,+0.75 to w-1.25,h-1.25) > > which renders the rows columns at 0 and wh-1 at a 1:1 scale using our > fill rules. Note that if you scale high enough you can still see > separation between fill and outline, but the gap is only 0.25 scaled > coordinates so it would take a scale of at least 4x to see it. > > The technically accurate way to render the first/last > pixel/1-unit-coordinate boundary of a component would be to > drawRect(0.5,0.5,w-1,h-1) (with no stroke control set) which would > place the rectangle at the following coordinates: > > outer part of outline goes from 0.5-0.5,0.5-0.5 to > 0.5+w-1+0.5,0.5+h-1+0.5 > (i.e. 0,0, to w,h) > inner part of outline goes form 0.5+0.5,0.5+0.5 to > 0.5+w-1-0.5,0.5+h-1-0.5 > (i.e. 1,1 to w-1,h-1) > > which completely encloses the first/last row/column of pixels on a 1:1 > coordinate system and accurately covers the first/last N pixels in any > arbitrary N-scaled coordinate system. The rounding for scales like > 1.5 still might not work out the way you wanted, but at least the > exact geometry is consistent with respect to the placement of pixels. > With AA you will get a consistent border all around if w,h are snapped > to a pixel size, but with non-AA then rounding error might lead to an > extra pixel on one pair of sides. I haven't done the analysis to see > how the above technique would be affected by STROKE_CONTROL because > really what you are looking for is to render the a consistent edge > around the component and so successive fills as is done with most of > our CSS skinning files in FX is a better solution overall. There are > just too many considerations in filling to make it worthwhile for > simple rectangular regions... > > ...jim > > On 10/4/16 1:46 PM, Anton Tarasov wrote: >> On 10/4/2016 11:30 PM, Jim Graham wrote: >>> I wasn't familiar with the test code for this particular case. Is >>> it in a bug report somewhere? >> Jim, I'm re-attaching it (it was in my first e-mail). >> >> Thanks, >> Anton. >> >>> >>> ...jim >>> >>> On 10/4/16 1:01 PM, Anton Tarasov wrote: >>>> Also, the problem with primitives rendering >>>> (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) >>>> is >>>> still there. But it seems to relate to line-thikness >>>> (border-thickness) rounding inaccuracy. What we can do with >>>> that?... >> From Sergey.Bylokhov at oracle.com Mon Oct 17 12:32:03 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 17 Oct 2016 15:32:03 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10 In-Reply-To: References: <57FE97C0.6010809@oracle.com> <5803A639.9000607@oracle.com> Message-ID: <14e1e5d9-aff6-a571-c4a7-472a17d08bd1@oracle.com> Looks fine. I am not only sure about the difference in the variable names: "name" VS "face". On 16.10.16 22:02, Vadim Pakhnushev wrote: > I guess you could reorder the calls for CFRelease(font); and > CFRelease(desc); so the desc gets released first in two locations under > family == NULL and name == NULL. > Just for the sake of consistency. > Other than that, +1. > > Vadim > > On 16.10.2016 19:09, Philip Race wrote: >> Anyone ? I'd like to get this backported to 8u this week so it >> can the 8u122 release which will enter RDP2 soon >> >> http://openjdk.java.net/projects/jdk8u/releases/8u122.html >> >> Although I have failed to find any email documenting the exact date >> the freeze is usually a week earlier than the RDP date so it could >> be as early as a week from now .. >> >> -phil. >> >> On 10/12/16, 1:06 PM, Philip Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8089573 >>> Webrev : http://cr.openjdk.java.net/~prr/8089573/ >>> >>> See the bug for some images showing the problem of scrambled text >>> when printing. >>> >>> Although only >>> JavaFX is affected the solution is entirely on the JDK side. >>> >>> JavaFX looks up some UI "system" fonts via special API calls and >>> these are fonts >>> that are not otherwise enumerated by CoreText. >>> JavaFX expects JDK to be able to access these fonts but it cannot. >>> We need to make the same API calls on JDK. >>> The exact fonts returned vary by MacOS release so it seems hard to >>> create a JDK regression >>> test but on the FX side it is seen instantly if you print a UI >>> control as the text is messed up >>> due to incorrect glyph ids. >>> >>> I intend to backport this to 8u and I've verified this does fix it on >>> 8u too .. >>> >>> Also both 8 & 9 build successfully with JPRT. >>> >>> -phil. > -- Best regards, Sergey. From philip.race at oracle.com Mon Oct 17 20:56:57 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 17 Oct 2016 13:56:57 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10 In-Reply-To: References: <57FE97C0.6010809@oracle.com> <5803A639.9000607@oracle.com> Message-ID: <58053B19.6050402@oracle.com> Harmless either way but I have committed as you suggest. -phil. On 10/16/16, 12:02 PM, Vadim Pakhnushev wrote: > I guess you could reorder the calls for CFRelease(font); and > CFRelease(desc); so the desc gets released first in two locations > under family == NULL and name == NULL. > Just for the sake of consistency. > Other than that, +1. > > Vadim > > On 16.10.2016 19:09, Philip Race wrote: >> Anyone ? I'd like to get this backported to 8u this week so it >> can the 8u122 release which will enter RDP2 soon >> >> http://openjdk.java.net/projects/jdk8u/releases/8u122.html >> >> Although I have failed to find any email documenting the exact date >> the freeze is usually a week earlier than the RDP date so it could >> be as early as a week from now .. >> >> -phil. >> >> On 10/12/16, 1:06 PM, Philip Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8089573 >>> Webrev : http://cr.openjdk.java.net/~prr/8089573/ >>> >>> See the bug for some images showing the problem of scrambled text >>> when printing. >>> >>> Although only >>> JavaFX is affected the solution is entirely on the JDK side. >>> >>> JavaFX looks up some UI "system" fonts via special API calls and >>> these are fonts >>> that are not otherwise enumerated by CoreText. >>> JavaFX expects JDK to be able to access these fonts but it cannot. >>> We need to make the same API calls on JDK. >>> The exact fonts returned vary by MacOS release so it seems hard to >>> create a JDK regression >>> test but on the FX side it is seen instantly if you print a UI >>> control as the text is messed up >>> due to incorrect glyph ids. >>> >>> I intend to backport this to 8u and I've verified this does fix it >>> on 8u too .. >>> >>> Also both 8 & 9 build successfully with JPRT. >>> >>> -phil. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 17 20:57:04 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 17 Oct 2016 13:57:04 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8089573: [macosx] Incorrect char to glyph mapping printing on OSX 10.10 In-Reply-To: <14e1e5d9-aff6-a571-c4a7-472a17d08bd1@oracle.com> References: <57FE97C0.6010809@oracle.com> <5803A639.9000607@oracle.com> <14e1e5d9-aff6-a571-c4a7-472a17d08bd1@oracle.com> Message-ID: <58053B20.3000906@oracle.com> On 10/17/16, 5:32 AM, Sergey Bylokhov wrote: > Looks fine. > I am not only sure about the difference in the variable names: "name" > VS "face". Our code - and API - tends to use "name" or "full name" -phil. > > On 16.10.16 22:02, Vadim Pakhnushev wrote: >> I guess you could reorder the calls for CFRelease(font); and >> CFRelease(desc); so the desc gets released first in two locations under >> family == NULL and name == NULL. >> Just for the sake of consistency. >> Other than that, +1. >> >> Vadim >> >> On 16.10.2016 19:09, Philip Race wrote: >>> Anyone ? I'd like to get this backported to 8u this week so it >>> can the 8u122 release which will enter RDP2 soon >>> >>> http://openjdk.java.net/projects/jdk8u/releases/8u122.html >>> >>> Although I have failed to find any email documenting the exact date >>> the freeze is usually a week earlier than the RDP date so it could >>> be as early as a week from now .. >>> >>> -phil. >>> >>> On 10/12/16, 1:06 PM, Philip Race wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8089573 >>>> Webrev : http://cr.openjdk.java.net/~prr/8089573/ >>>> >>>> See the bug for some images showing the problem of scrambled text >>>> when printing. >>>> >>>> Although only >>>> JavaFX is affected the solution is entirely on the JDK side. >>>> >>>> JavaFX looks up some UI "system" fonts via special API calls and >>>> these are fonts >>>> that are not otherwise enumerated by CoreText. >>>> JavaFX expects JDK to be able to access these fonts but it cannot. >>>> We need to make the same API calls on JDK. >>>> The exact fonts returned vary by MacOS release so it seems hard to >>>> create a JDK regression >>>> test but on the FX side it is seen instantly if you print a UI >>>> control as the text is messed up >>>> due to incorrect glyph ids. >>>> >>>> I intend to backport this to 8u and I've verified this does fix it on >>>> 8u too .. >>>> >>>> Also both 8 & 9 build successfully with JPRT. >>>> >>>> -phil. >> > > From brian.burkhalter at oracle.com Tue Oct 18 21:24:00 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 18 Oct 2016 14:24:00 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8165981: Consider making some classes in javax.imageio.plugins.tiff final In-Reply-To: <8dd572da-d18f-1169-aec7-27bd8fb40b5d@oracle.com> References: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> <89c6eefe-bfbe-829c-8be6-2900de0cfcc0@oracle.com> <1D0E5B40-2791-47AC-AF9A-C79154325080@oracle.com> <8dd572da-d18f-1169-aec7-27bd8fb40b5d@oracle.com> Message-ID: One could potentially change all the public getters in non-final classes in javax.imageio.plugins.tiff to be final as in http://cr.openjdk.java.net/~bpb/8165981/webrev.01/ or go even further and additionally refactor TIFFDirectory to be an interface implemented by the internal TIFFIFD class. In the interest of mitigating to an extent the difficulty encountered by any users potentially migrating from the original JAI Image I/O Tools package, I would however be more in favor of keeping the original proposal in this thread http://cr.openjdk.java.net/~bpb/8165981/webrev.00/ wherein only TIFFField and TIFFImageReadParam are made final. Thanks, Brian On Oct 4, 2016, at 4:13 PM, Sergey Bylokhov wrote: > Probably some methods can be made final also (at least setters and getters)? > because it always a problem when we validate something in the setter(constructor), but the user returns something unspecified from the overriden getter. > > On 03.10.16 22:51, Brian Burkhalter wrote: >> Good point. I think TIFFIFD needs to be a subclass therefore lets leave >> TIFFDirectory as is. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Oct 18 23:02:09 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 18 Oct 2016 16:02:09 -0700 Subject: [OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: <57B4A83C.709@oracle.com> References: <7E7ACA58-AA5C-4352-979C-638993C8B7DF@oracle.com> <57B4A83C.709@oracle.com> Message-ID: <04743DB7-2698-41A9-95DC-80AE9FBADCE2@oracle.com> It seems that there might be in effect three scenarios worth considering: A) Ignore all metadata (ignoreMetadata [1] is true) No metadata would be read except that required to read the image itself. This is related to another issue [2]. It is debatable whether any such essential metadata should be propagated to the ImageMetadata despite ignoreMetadata?s being true. B) Ignore only metadata unknown to the TIFFImageReadParam (ignoreMetadata is false) Only metadata essential to reading the image or corresponding to TIFFTags present in the union of TIFFTagSets set on the TIFFImageReadParam would be read. Similarly to scenario (A), it is be debatable whether metadata essential to reading the image should be propagated to the ImageMetadata if there is no corresponding tag in the union of known TIFFTagSets. Note that the absence of a provided TIFFImageReadParam implies that the default TIFFTagSets delineated in the class description of TIFFImageReadParam [3] would be recognized. C) Do not ignore any metadata (ignoreMetadata is false) All metadata would be read including that corresponding to TIFFTags not present in the union of TIFFTagSets set on the TIFFImageReadParam. The foregoing set of scenarios would allow the blanket disabling of reading metadata as intended by [1], while retaining the ability to have fine-grained control over which fields are read as intended by the original TIFF plugin code [4]. In order to distinguish between scenarios (B) and (C) an extra setting, e.g., ?ignoreUnknownTags? on the TIFFImageReadParam would be required, and any other pertinent API documentation updated, including [4]. Brian [1] http://download.java.net/java/jdk9/docs/api/javax/imageio/ImageReader.html#ignoreMetadata [2] https://bugs.openjdk.java.net/browse/JDK-8164750 [3] http://download.java.net/java/jdk9/docs/api/javax/imageio/plugins/tiff/TIFFImageReadParam.html [4] http://download.java.net/java/jdk9/docs/api/javax/imageio/metadata/doc-files/tiff_metadata.html#MetadataIssuesRead On Aug 17, 2016, at 11:09 AM, Phil Race wrote: > That all seems fine (for the case of ignoreMetaData == true). > > But there may be still a bug - of some kind - uncovered by this test. > The submitter has this case : > > ignore = false: > EXIF: true > Fax : true > GPS : true > > which means that all metadata is being read .. as is the default per the docs > on the TIFF package description. But I am wondering what the effect setting of > > param.removeAllowedTagSet(FaxTIFFTagSet.getInstance()); > > should have been in this case. > A strict reading of the spec. makes it sound like it only has any effect > when you specify ignoreMetadata == true but I don't see the point > of the API in that case, since you are already ignoring metadata, unless > it is just a matter of being more clear to the reader that the latitude > it has to read metadata anyway regardless should be tempered by > this additional call. > > But is there not also value in being able to remove the tag from > the allowed set in the ignoreMetadata == false case ? > > That seemed to be the gist of the text here :- > >In cases where the IFD includes fields which contain > > large amounts of data this could be very inefficient. > > Which fields are loaded may be controlled by setting > >which TIFF tags the reader is allowed to recognize and whether it is ignoring metadata. > > eg .. "I want all metadata except Fax" .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Oct 19 23:35:58 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 19 Oct 2016 16:35:58 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8168364: [macosx] Delete unused class NSPrintinfo Message-ID: <5808035E.70607@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8168364 webrev : http://cr.openjdk.java.net/~prr/8168364/ NSPrintInfo is an Attribute so it can presumably be stuffed in an AttributeSet. Apart from being inaccessible to apps and unused it is not a good idea. It was perhaps once used to (re-?)initialise fNSPrintInfo .. and that needs to be synchronized it seems. I fixed the one other unsynchronised use of that as well as deleting the unused code. -phil. From prasanta.sadhukhan at oracle.com Thu Oct 20 08:10:59 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 20 Oct 2016 13:40:59 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8040635: [macosx] Printing a shape filled with a texture doesn't work under Mac OS X Message-ID: <58087C13.9040302@oracle.com> Hi All, Please review a fix for osx printing where it is seen that TexturePaint pattern is not getting printed. Bug: https://bugs.openjdk.java.net/browse/JDK-8040635 webrev: http://cr.openjdk.java.net/~psadhukhan/8040635/webrev.00/ The issue was because TexturePaint Evaluate function in native QuartzSurfaceData.m uses LockImage() function to access texture buffered image. In LockImage(), it accesses image data by checking javaImageInfo[sun_java2d_OSXOffScreenSurfaceData_kImageStolenIndex] and javaImageInfo[sun_java2d_OSXOffScreenSurfaceData_kNeedToSyncFromJavaPixelsIndex] and this variable "kImageStolenIndex" and "kNeedToSyncFromJavaPixelsIndex" are set in OSXOffScreenSurfaceData but OSXSurfaceData uses BufImgSurfaceData.createData which does not set this variables resulting in crash when it tries to access data buffer with wrong unset index. Proposed fix is to use OSXOffscreenSurfaceData where the variables, accessed by native, are set properly. Regards Prasanta From prasanta.sadhukhan at oracle.com Thu Oct 20 09:22:52 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 20 Oct 2016 14:52:52 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <57EAD86B.2010006@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> Message-ID: <58088CEC.1010804@oracle.com> Hi Phil, I have modified the webrev to support REFLECT and REPEAT albeit via raster path and not via Quartz api, as Quartz cannot handle REPEAT/REFLECT. http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ Have tested with different fractions, stops, color. Regards Prasanta On 9/28/2016 2:06 AM, Philip Race wrote: > Hi, > > LinearGradientPaint has three options as to how it is extended beyond > the end point > > https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html > > > So far as I can see this code (and perhaps quartz) can only handle > NO_CYCLE .. > > If REFLECT or REPEAT are specified and Quartz can't handle it we will > need to > fall back to the raster path. > > I think it would be helpful to extend the test with examples that use > these and > also more than just the two colours .. add a variant that tries more > like 4 ... > > -phil. > > On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9 where it is seen that >> LinearGradientPaint is not getting printed on osx. >> The below webrev is only for LinearGradientPaint >> and RadialGradientPaint will be handled separately. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >> >> Issue was LinearGradientPaint is not handled in osx from jdk7 >> onwards. It handles simple GradientPaint. >> Code is added as per >> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >> >> >> to use "CGGradientRef" quartz datatype to support LinearGradientPaint. >> CGGradientRef is used compared to CGShadingRef because it is >> mentioned in CGGradientRef, i is "Easy to define more than two >> locations and colors." as we set 2 or more colors and 2 or more >> fractions in LinearGradientPaint. >> >> Regards >> Prasanta >> From Sergey.Bylokhov at oracle.com Thu Oct 20 10:52:26 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 20 Oct 2016 13:52:26 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8168364: [macosx] Delete unused class NSPrintinfo In-Reply-To: <5808035E.70607@oracle.com> References: <5808035E.70607@oracle.com> Message-ID: Looks fine. On 20.10.16 2:35, Philip Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8168364 > webrev : http://cr.openjdk.java.net/~prr/8168364/ > > NSPrintInfo is an Attribute so it can presumably be stuffed in an > AttributeSet. > Apart from being inaccessible to apps and unused it is not a good idea. > It was perhaps once used to (re-?)initialise fNSPrintInfo .. and that > needs to > be synchronized it seems. I fixed the one other unsynchronised use of that > as well as deleting the unused code. > > -phil. -- Best regards, Sergey. From philip.race at oracle.com Thu Oct 20 16:01:19 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Oct 2016 09:01:19 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <58088CEC.1010804@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> Message-ID: Leaving aside the tests, the webrev here looks to be the one proposed for the TexturePaint bug. Did you get things mixed up ? -phil. On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: > Hi Phil, > > I have modified the webrev to support REFLECT and REPEAT albeit via > raster path and not via Quartz api, as Quartz cannot handle > REPEAT/REFLECT. > http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ > > Have tested with different fractions, stops, color. > > Regards > Prasanta > On 9/28/2016 2:06 AM, Philip Race wrote: >> Hi, >> >> LinearGradientPaint has three options as to how it is extended beyond >> the end point >> >> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >> >> >> So far as I can see this code (and perhaps quartz) can only handle >> NO_CYCLE .. >> >> If REFLECT or REPEAT are specified and Quartz can't handle it we will >> need to >> fall back to the raster path. >> >> I think it would be helpful to extend the test with examples that use >> these and >> also more than just the two colours .. add a variant that tries more >> like 4 ... >> >> -phil. >> >> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9 where it is seen that >>> LinearGradientPaint is not getting printed on osx. >>> The below webrev is only for LinearGradientPaint >>> and RadialGradientPaint will be handled separately. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>> >>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>> onwards. It handles simple GradientPaint. >>> Code is added as per >>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>> >>> >>> to use "CGGradientRef" quartz datatype to support LinearGradientPaint. >>> CGGradientRef is used compared to CGShadingRef because it is >>> mentioned in CGGradientRef, i is "Easy to define more than two >>> locations and colors." as we set 2 or more colors and 2 or more >>> fractions in LinearGradientPaint. >>> >>> Regards >>> Prasanta >>> > From philip.race at oracle.com Thu Oct 20 20:12:39 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Oct 2016 13:12:39 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8168288: Dubious FontMetrics values from NullFontScaler Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8168288 Webrev: http://cr.openjdk.java.net/~prr/8168288/ Fixes some bizarre values you get for the "null" scaler as used when we find we can't use the font. More info in the bug report. -phil. From prasanta.sadhukhan at oracle.com Fri Oct 21 04:40:36 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 21 Oct 2016 10:10:36 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> Message-ID: <58099C44.90609@oracle.com> No, this webrev supports LinearGradient/RadialGradient for all 3 options. The fix seems to be almost same as in TexturePaint but in a different else block in OSXSurfaceData.java. Regards Prasanta On 10/20/2016 9:31 PM, Phil Race wrote: > Leaving aside the tests, the webrev here looks to be the one proposed > for the TexturePaint bug. Did you get things mixed up ? > > -phil. > > On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >> Hi Phil, >> >> I have modified the webrev to support REFLECT and REPEAT albeit via >> raster path and not via Quartz api, as Quartz cannot handle >> REPEAT/REFLECT. >> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >> >> Have tested with different fractions, stops, color. >> >> Regards >> Prasanta >> On 9/28/2016 2:06 AM, Philip Race wrote: >>> Hi, >>> >>> LinearGradientPaint has three options as to how it is extended >>> beyond the end point >>> >>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>> >>> >>> So far as I can see this code (and perhaps quartz) can only handle >>> NO_CYCLE .. >>> >>> If REFLECT or REPEAT are specified and Quartz can't handle it we >>> will need to >>> fall back to the raster path. >>> >>> I think it would be helpful to extend the test with examples that >>> use these and >>> also more than just the two colours .. add a variant that tries more >>> like 4 ... >>> >>> -phil. >>> >>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for jdk9 where it is seen that >>>> LinearGradientPaint is not getting printed on osx. >>>> The below webrev is only for LinearGradientPaint >>>> and RadialGradientPaint will be handled separately. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>> >>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>> onwards. It handles simple GradientPaint. >>>> Code is added as per >>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>> >>>> >>>> to use "CGGradientRef" quartz datatype to support LinearGradientPaint. >>>> CGGradientRef is used compared to CGShadingRef because it is >>>> mentioned in CGGradientRef, i is "Easy to define more than two >>>> locations and colors." as we set 2 or more colors and 2 or more >>>> fractions in LinearGradientPaint. >>>> >>>> Regards >>>> Prasanta >>>> >> > From brian.burkhalter at oracle.com Fri Oct 21 19:18:44 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Oct 2016 12:18:44 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168498: ExifGPSTagSet and ExifTIFFTagSet should use string literals for String constants Message-ID: <65B6017C-9E5B-44BD-B372-CE8F2B169766@oracle.com> Please review this trivial change at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8168498 Patch: [1] Thanks, Brian [1] diff --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java @@ -55,9 +55,7 @@ * * @see #TAG_GPS_VERSION_ID */ - public static final String GPS_VERSION_2_2 = - new String(new byte[] { '2', '2', '0', '0' }, - StandardCharsets.US_ASCII); + public static final String GPS_VERSION_2_2 = "" + '2' + '2' + '0' + '0'; --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java @@ -71,9 +71,7 @@ * * @see #TAG_EXIF_VERSION */ - public static final String EXIF_VERSION_2_1 = - new String(new byte[] { '0', '2', '1', '0' }, - StandardCharsets.US_ASCII); + public static final String EXIF_VERSION_2_1 = "" + '0' + '2' + '1' + '0'; /** * A value to be used with the "ExifVersion" tag to indicate Exif version @@ -82,9 +80,7 @@ * * @see #TAG_EXIF_VERSION */ - public static final String EXIF_VERSION_2_2 = - new String(new byte[] { '0', '2', '2', '0' }, - StandardCharsets.US_ASCII); + public static final String EXIF_VERSION_2_2 = "" + '0' + '2' + '2' + '0'; -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 21 19:22:15 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Oct 2016 12:22:15 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8168288: Dubious FontMetrics values from NullFontScaler In-Reply-To: References: Message-ID: <3DA8CB4A-6947-4C91-8D69-671CB6CDE14C@oracle.com> This looks OK to me. Brian On Oct 20, 2016, at 1:12 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8168288 > Webrev: http://cr.openjdk.java.net/~prr/8168288/ > > Fixes some bizarre values you get for the "null" scaler as used > when we find we can't use the font. > > More info in the bug report. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 21 20:11:11 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Oct 2016 13:11:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8165981: Consider making some classes in javax.imageio.plugins.tiff final In-Reply-To: References: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> <89c6eefe-bfbe-829c-8be6-2900de0cfcc0@oracle.com> <1D0E5B40-2791-47AC-AF9A-C79154325080@oracle.com> <8dd572da-d18f-1169-aec7-27bd8fb40b5d@oracle.com> Message-ID: <2375AA01-4530-4CF8-8443-9547CE0753D2@oracle.com> Barring objections to the contrary I am inclined to go with webrev.00. There is no precedent in the public javax.imageio.plugins classes for making getters and the like final. Note also that BMPImageWriteParam, JPEGImageReadParam, and JPEGImageWriteParam and not final either. Thanks, Brian On Oct 18, 2016, at 2:24 PM, Brian Burkhalter wrote: > One could potentially change all the public getters in non-final classes in javax.imageio.plugins.tiff to be final as in > > http://cr.openjdk.java.net/~bpb/8165981/webrev.01/ > > or go even further and additionally refactor TIFFDirectory to be an interface implemented by the internal TIFFIFD class. In the interest of mitigating to an extent the difficulty encountered by any users potentially migrating from the original JAI Image I/O Tools package, I would however be more in favor of keeping the original proposal in this thread > > http://cr.openjdk.java.net/~bpb/8165981/webrev.00/ > > wherein only TIFFField and TIFFImageReadParam are made final. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 21 20:42:43 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 21 Oct 2016 13:42:43 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF Message-ID: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> Please review this api-doc-only change to the javax.imageio package summary: Issue: https://bugs.openjdk.java.net/browse/JDK-8168367 Patch: http://cr.openjdk.java.net/~bpb/8168367/webrev.00/ Javadoc: http://cr.openjdk.java.net/~bpb/8168367/javadoc.00/package-summary.html In the package-summary.html linked above, only the table following "All implementations of javax.imageio provide the following standard image format plug-ins:? has changed. It has been reordered to be alphabetical by format name and a row for TIFF has been added. Thanks, Brian From philip.race at oracle.com Fri Oct 21 23:20:45 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 21 Oct 2016 16:20:45 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <58099C44.90609@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> Message-ID: <580AA2CD.6000703@oracle.com> Well it is confusing since in particular this exact change is in both webrevs :- http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.html One thing that I think seems less ideal about this fix, at least for the Gradient case is that it is creating an image which shows pixelisation effects when I zoom in using Preview .. I don't think the previous code showed those effects so it may be you want a hybrid, using the original code when you can. That probably is not an issue for TexturePaint .. -phil On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: > No, this webrev supports LinearGradient/RadialGradient for all 3 > options. The fix seems to be almost same as in TexturePaint but in a > different else block in OSXSurfaceData.java. > > Regards > Prasanta > On 10/20/2016 9:31 PM, Phil Race wrote: >> Leaving aside the tests, the webrev here looks to be the one proposed >> for the TexturePaint bug. Did you get things mixed up ? >> >> -phil. >> >> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>> Hi Phil, >>> >>> I have modified the webrev to support REFLECT and REPEAT albeit via >>> raster path and not via Quartz api, as Quartz cannot handle >>> REPEAT/REFLECT. >>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>> >>> Have tested with different fractions, stops, color. >>> >>> Regards >>> Prasanta >>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>> Hi, >>>> >>>> LinearGradientPaint has three options as to how it is extended >>>> beyond the end point >>>> >>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>>> >>>> >>>> So far as I can see this code (and perhaps quartz) can only handle >>>> NO_CYCLE .. >>>> >>>> If REFLECT or REPEAT are specified and Quartz can't handle it we >>>> will need to >>>> fall back to the raster path. >>>> >>>> I think it would be helpful to extend the test with examples that >>>> use these and >>>> also more than just the two colours .. add a variant that tries >>>> more like 4 ... >>>> >>>> -phil. >>>> >>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for jdk9 where it is seen that >>>>> LinearGradientPaint is not getting printed on osx. >>>>> The below webrev is only for LinearGradientPaint >>>>> and RadialGradientPaint will be handled separately. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>> >>>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>>> onwards. It handles simple GradientPaint. >>>>> Code is added as per >>>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>> >>>>> >>>>> to use "CGGradientRef" quartz datatype to support >>>>> LinearGradientPaint. >>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>> mentioned in CGGradientRef, i is "Easy to define more than two >>>>> locations and colors." as we set 2 or more colors and 2 or more >>>>> fractions in LinearGradientPaint. >>>>> >>>>> Regards >>>>> Prasanta >>>>> >>> >> > From prasanta.sadhukhan at oracle.com Sat Oct 22 15:58:42 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 22 Oct 2016 21:28:42 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <580AA2CD.6000703@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> <580AA2CD.6000703@oracle.com> Message-ID: <580B8CB2.0@oracle.com> On 10/22/2016 4:50 AM, Philip Race wrote: > Well it is confusing since in particular this exact change is in both > webrevs :- > http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.html > > Yes. This is same and I had to add this in both webrevs as TexturePaint patch is not yet approved. > One thing that I think seems less ideal about this fix, at least for > the Gradient case is that it is creating an image which shows > pixelisation > effects when I zoom in using Preview .. > > I don't think the previous code showed those effects so it may be you > want a hybrid, using the original code when you can. ok. I will make NO_CYCLE option to go through quartz and other REPEAT/REFLECT option to go though raster texturepaint path. Regards Prasanta > That probably is not an issue for TexturePaint .. > > -phil > > On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: >> No, this webrev supports LinearGradient/RadialGradient for all 3 >> options. The fix seems to be almost same as in TexturePaint but in a >> different else block in OSXSurfaceData.java. >> >> Regards >> Prasanta >> On 10/20/2016 9:31 PM, Phil Race wrote: >>> Leaving aside the tests, the webrev here looks to be the one proposed >>> for the TexturePaint bug. Did you get things mixed up ? >>> >>> -phil. >>> >>> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>>> Hi Phil, >>>> >>>> I have modified the webrev to support REFLECT and REPEAT albeit via >>>> raster path and not via Quartz api, as Quartz cannot handle >>>> REPEAT/REFLECT. >>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>>> >>>> Have tested with different fractions, stops, color. >>>> >>>> Regards >>>> Prasanta >>>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>>> Hi, >>>>> >>>>> LinearGradientPaint has three options as to how it is extended >>>>> beyond the end point >>>>> >>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>>>> >>>>> >>>>> So far as I can see this code (and perhaps quartz) can only handle >>>>> NO_CYCLE .. >>>>> >>>>> If REFLECT or REPEAT are specified and Quartz can't handle it we >>>>> will need to >>>>> fall back to the raster path. >>>>> >>>>> I think it would be helpful to extend the test with examples that >>>>> use these and >>>>> also more than just the two colours .. add a variant that tries >>>>> more like 4 ... >>>>> >>>>> -phil. >>>>> >>>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for jdk9 where it is seen that >>>>>> LinearGradientPaint is not getting printed on osx. >>>>>> The below webrev is only for LinearGradientPaint >>>>>> and RadialGradientPaint will be handled separately. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>>> >>>>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>>>> onwards. It handles simple GradientPaint. >>>>>> Code is added as per >>>>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>>> >>>>>> >>>>>> to use "CGGradientRef" quartz datatype to support >>>>>> LinearGradientPaint. >>>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>>> mentioned in CGGradientRef, i is "Easy to define more than two >>>>>> locations and colors." as we set 2 or more colors and 2 or more >>>>>> fractions in LinearGradientPaint. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> >>>> >>> >> From jayathirth.d.v at oracle.com Mon Oct 24 06:14:34 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sun, 23 Oct 2016 23:14:34 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> Message-ID: <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> Hi Brian, Changes are fine. I was wondering if we can provide hyperlink for BMP also which can point to http://www.digicamsoft.com/bmp/bmp.html (or other proper link which will give information regarding BMP file format). Please let me know your inputs. Thanks, Jay -----Original Message----- From: Brian Burkhalter Sent: Saturday, October 22, 2016 2:13 AM To: 2d-dev Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF Please review this api-doc-only change to the javax.imageio package summary: Issue: https://bugs.openjdk.java.net/browse/JDK-8168367 Patch: http://cr.openjdk.java.net/~bpb/8168367/webrev.00/ Javadoc: http://cr.openjdk.java.net/~bpb/8168367/javadoc.00/package-summary.html In the package-summary.html linked above, only the table following "All implementations of javax.imageio provide the following standard image format plug-ins:" has changed. It has been reordered to be alphabetical by format name and a row for TIFF has been added. Thanks, Brian From prasanta.sadhukhan at oracle.com Mon Oct 24 08:38:06 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 24 Oct 2016 14:08:06 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <580B8CB2.0@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> <580AA2CD.6000703@oracle.com> <580B8CB2.0@oracle.com> Message-ID: <580DC86E.3010902@oracle.com> Please find modified webrev with Linear/Radial Gradient NO_CYCLE option catered through quartz api and REPEAT/REFLECT option catered via raster path. http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.02/ Regards Prasanta On 10/22/2016 9:28 PM, Prasanta Sadhukhan wrote: > > > On 10/22/2016 4:50 AM, Philip Race wrote: >> Well it is confusing since in particular this exact change is in both >> webrevs :- >> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.html >> >> > Yes. This is same and I had to add this in both webrevs as > TexturePaint patch is not yet approved. >> One thing that I think seems less ideal about this fix, at least for >> the Gradient case is that it is creating an image which shows >> pixelisation >> effects when I zoom in using Preview .. >> >> I don't think the previous code showed those effects so it may be you >> want a hybrid, using the original code when you can. > ok. I will make NO_CYCLE option to go through quartz and other > REPEAT/REFLECT option to go though raster texturepaint path. > > Regards > Prasanta >> That probably is not an issue for TexturePaint .. >> >> -phil >> >> On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: >>> No, this webrev supports LinearGradient/RadialGradient for all 3 >>> options. The fix seems to be almost same as in TexturePaint but in a >>> different else block in OSXSurfaceData.java. >>> >>> Regards >>> Prasanta >>> On 10/20/2016 9:31 PM, Phil Race wrote: >>>> Leaving aside the tests, the webrev here looks to be the one proposed >>>> for the TexturePaint bug. Did you get things mixed up ? >>>> >>>> -phil. >>>> >>>> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> I have modified the webrev to support REFLECT and REPEAT albeit >>>>> via raster path and not via Quartz api, as Quartz cannot handle >>>>> REPEAT/REFLECT. >>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>>>> >>>>> Have tested with different fractions, stops, color. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>>>> Hi, >>>>>> >>>>>> LinearGradientPaint has three options as to how it is extended >>>>>> beyond the end point >>>>>> >>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>>>>> >>>>>> >>>>>> So far as I can see this code (and perhaps quartz) can only >>>>>> handle NO_CYCLE .. >>>>>> >>>>>> If REFLECT or REPEAT are specified and Quartz can't handle it we >>>>>> will need to >>>>>> fall back to the raster path. >>>>>> >>>>>> I think it would be helpful to extend the test with examples that >>>>>> use these and >>>>>> also more than just the two colours .. add a variant that tries >>>>>> more like 4 ... >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for jdk9 where it is seen that >>>>>>> LinearGradientPaint is not getting printed on osx. >>>>>>> The below webrev is only for LinearGradientPaint >>>>>>> and RadialGradientPaint will be handled separately. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>>>> >>>>>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>>>>> onwards. It handles simple GradientPaint. >>>>>>> Code is added as per >>>>>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>>>> >>>>>>> >>>>>>> to use "CGGradientRef" quartz datatype to support >>>>>>> LinearGradientPaint. >>>>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>>>> mentioned in CGGradientRef, i is "Easy to define more than two >>>>>>> locations and colors." as we set 2 or more colors and 2 or more >>>>>>> fractions in LinearGradientPaint. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> >>>>> >>>> >>> > From brian.burkhalter at oracle.com Mon Oct 24 14:52:02 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Oct 2016 07:52:02 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> Message-ID: <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> Hi Jay, I also looked for a link for BMP but did not know which would be reliable. Is that the case for the one you suggest? Also there is the Wikipedia one [1]. Thanks, Brian [1] https://en.wikipedia.org/wiki/BMP_file_format On Oct 23, 2016, at 11:14 PM, Jayathirth D V wrote: > Changes are fine. > I was wondering if we can provide hyperlink for BMP also which can point tohttp://www.digicamsoft.com/bmp/bmp.html (or other proper link which will give information regarding BMP file format). > Please let me know your inputs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Oct 24 15:04:31 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 24 Oct 2016 08:04:31 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> Message-ID: <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> Hi Brian, Yes we can point to Wikipedia link. It will serve the purpose of giving basic information related to particular file format. Thanks, Jay From: Brian Burkhalter Sent: Monday, October 24, 2016 8:22 PM To: Jayathirth D V Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF Hi Jay, I also looked for a link for BMP but did not know which would be reliable. Is that the case for the one you suggest? Also there is the Wikipedia one [1]. Thanks, Brian [1] https://en.wikipedia.org/wiki/BMP_file_format On Oct 23, 2016, at 11:14 PM, Jayathirth D V wrote: Changes are fine. I was wondering if we can provide hyperlink for BMP also which can point tohttp://www.digicamsoft.com/bmp/bmp.html (or other proper link which will give information regarding BMP file format). Please let me know your inputs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Oct 24 15:15:53 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Oct 2016 08:15:53 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> Message-ID: <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> Hi Jay, That works for me but there is no precedent for pointing to Wikipedia from JDK Java or HTML files. I wonder whether there are any guidelines on which external sites may be linked? There is also this one [1] which in turn points to Wikipedia and some other references. Thanks, Brian [1] http://www.digitalpreservation.gov/formats/fdd/fdd000189.shtml On Oct 24, 2016, at 8:04 AM, Jayathirth D V wrote: > Yes we can point to Wikipedia link. It will serve the purpose of giving basic information related to particular file format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 24 15:30:35 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 24 Oct 2016 08:30:35 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> Message-ID: <580E291B.2020302@oracle.com> Do not point to wikipedia. If we must point to external links we want to point to a specification in the most "official" place that exists .. one maintained by the owner of that spec. Strictly that even becomes a part of the SE spec. Wikipedia is not a place we'd ever want to say Java SE relies on for its spec .. -phil. On 10/24/16, 8:15 AM, Brian Burkhalter wrote: > Hi Jay, > > That works for me but there is no precedent for pointing to Wikipedia > from JDK Java or HTML files. I wonder whether there are any guidelines > on which external sites may be linked? > > There is also this one [1] which in turn points to Wikipedia and some > other references. > > Thanks, > > Brian > > [1] http://www.digitalpreservation.gov/formats/fdd/fdd000189.shtml > > On Oct 24, 2016, at 8:04 AM, Jayathirth D V > wrote: > >> Yes we can point to Wikipedia link. It will serve the purpose of >> giving basic information related to particular file format. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Oct 24 15:54:46 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Oct 2016 08:54:46 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <580E291B.2020302@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> <580E291B.2020302@oracle.com> Message-ID: <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> I suspected as much. Could be that for BMP we are out of luck as there is no ?real? specification AFAIK. Brian On Oct 24, 2016, at 8:30 AM, Philip Race wrote: > Do not point to wikipedia. > If we must point to external links we want to point to a specification in the > most "official" place that exists .. one maintained by the owner of that spec. > Strictly that even becomes a part of the SE spec. Wikipedia is not a place > we'd ever want to say Java SE relies on for its spec .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 24 15:57:07 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 24 Oct 2016 08:57:07 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> <580E291B.2020302@oracle.com> <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> Message-ID: <580E2F53.9080501@oracle.com> I've poked around the Microsoft website and didn't turn up a location I am sure we could rely on. A top-level link to microsoft.com and some words that the format was devised by Microsoft for Windows may be the best we can do. -phil. On 10/24/16, 8:54 AM, Brian Burkhalter wrote: > I suspected as much. Could be that for BMP we are out of luck as there > is no ?real? specification AFAIK. > > Brian > > On Oct 24, 2016, at 8:30 AM, Philip Race > wrote: > >> Do not point to wikipedia. >> If we must point to external links we want to point to a >> specification in the >> most "official" place that exists .. one maintained by the owner of >> that spec. >> Strictly that even becomes a part of the SE spec. Wikipedia is not a >> place >> we'd ever want to say Java SE relies on for its spec .. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Mon Oct 24 16:10:31 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 24 Oct 2016 19:10:31 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <580E2F53.9080501@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> <580E291B.2020302@oracle.com> <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> <580E2F53.9080501@oracle.com> Message-ID: My go-to place for BMP spec is https://msdn.microsoft.com/en-us/library/dd183391(v=vs.85).aspx which is where we point from JavaFX docs. Vadim On 24.10.2016 18:57, Philip Race wrote: > I've poked around the Microsoft website and didn't turn up a location > I am sure we could rely on. > > A top-level link to microsoft.com and some words that the format > was devised by Microsoft for Windows may be the best we can do. > > -phil. > > On 10/24/16, 8:54 AM, Brian Burkhalter wrote: >> I suspected as much. Could be that for BMP we are out of luck as >> there is no ?real? specification AFAIK. >> >> Brian >> >> On Oct 24, 2016, at 8:30 AM, Philip Race > > wrote: >> >>> Do not point to wikipedia. >>> If we must point to external links we want to point to a >>> specification in the >>> most "official" place that exists .. one maintained by the owner of >>> that spec. >>> Strictly that even becomes a part of the SE spec. Wikipedia is not a >>> place >>> we'd ever want to say Java SE relies on for its spec .. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 24 16:34:57 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 24 Oct 2016 09:34:57 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> <580E291B.2020302@oracle.com> <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> <580E2F53.9080501@oracle.com> Message-ID: <580E3831.3070301@oracle.com> I think I saw that one but the weird final part of the name put me off. For comparison here's how they reference the OpenType (font) spec :- https://www.microsoft.com/en-us/Typography/OpenTypeSpecification.aspx -phil. On 10/24/16, 9:10 AM, Vadim Pakhnushev wrote: > My go-to place for BMP spec is > https://msdn.microsoft.com/en-us/library/dd183391(v=vs.85).aspx which > is where we point from JavaFX docs. > > Vadim > > On 24.10.2016 18:57, Philip Race wrote: >> I've poked around the Microsoft website and didn't turn up a location >> I am sure we could rely on. >> >> A top-level link to microsoft.com and some words that the format >> was devised by Microsoft for Windows may be the best we can do. >> >> -phil. >> >> On 10/24/16, 8:54 AM, Brian Burkhalter wrote: >>> I suspected as much. Could be that for BMP we are out of luck as >>> there is no ?real? specification AFAIK. >>> >>> Brian >>> >>> On Oct 24, 2016, at 8:30 AM, Philip Race >> > wrote: >>> >>>> Do not point to wikipedia. >>>> If we must point to external links we want to point to a >>>> specification in the >>>> most "official" place that exists .. one maintained by the owner of >>>> that spec. >>>> Strictly that even becomes a part of the SE spec. Wikipedia is not >>>> a place >>>> we'd ever want to say Java SE relies on for its spec .. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Oct 24 18:35:26 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Oct 2016 11:35:26 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <580E3831.3070301@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> <580E291B.2020302@oracle.com> <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> <580E2F53.9080501@oracle.com> <580E3831.3070301@oracle.com> Message-ID: <6CE8C0E2-D95B-4351-8F7C-C13D241DE11F@oracle.com> The content of the Bitmap Storage link looks good but the hyperlink is rather strange I agree. Perhaps the BMP link issue could go under a different issue as this has nothing to do with TIFF? Brian On Oct 24, 2016, at 9:34 AM, Philip Race wrote: > I think I saw that one but the weird final part of the name put me off. > For comparison here's how they reference the OpenType (font) spec :- > > https://www.microsoft.com/en-us/Typography/OpenTypeSpecification.aspx > > -phil. > > On 10/24/16, 9:10 AM, Vadim Pakhnushev wrote: >> >> My go-to place for BMP spec ishttps://msdn.microsoft.com/en-us/library/dd183391(v=vs.85).aspx which is where we point from JavaFX docs. >> >> Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 24 18:37:48 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 24 Oct 2016 11:37:48 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8168364: [macosx] Delete unused class NSPrintinfo In-Reply-To: References: <5808035E.70607@oracle.com> Message-ID: <580E54FC.2040208@oracle.com> Can I get a 2nd reviewer on this one ? -phil. On 10/20/16, 3:52 AM, Sergey Bylokhov wrote: > Looks fine. > > On 20.10.16 2:35, Philip Race wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8168364 >> webrev : http://cr.openjdk.java.net/~prr/8168364/ >> >> NSPrintInfo is an Attribute so it can presumably be stuffed in an >> AttributeSet. >> Apart from being inaccessible to apps and unused it is not a good idea. >> It was perhaps once used to (re-?)initialise fNSPrintInfo .. and that >> needs to >> be synchronized it seems. I fixed the one other unsynchronised use of >> that >> as well as deleting the unused code. >> >> -phil. > > From philip.race at oracle.com Mon Oct 24 18:41:24 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 24 Oct 2016 11:41:24 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <6CE8C0E2-D95B-4351-8F7C-C13D241DE11F@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> <580E291B.2020302@oracle.com> <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> <580E2F53.9080501@oracle.com> <580E3831.3070301@oracle.com> <6CE8C0E2-D95B-4351-8F7C-C13D241DE11F@oracle.com> Message-ID: <580E55D4.3010401@oracle.com> +1 to that .. and +1 to the webrev. -phil. On 10/24/16, 11:35 AM, Brian Burkhalter wrote: > The content of the Bitmap Storage link looks good but the hyperlink is > rather strange I agree. Perhaps the BMP link issue could go under a > different issue as this has nothing to do with TIFF? > > Brian > > On Oct 24, 2016, at 9:34 AM, Philip Race > wrote: > >> I think I saw that one but the weird final part of the name put me off. >> For comparison here's how they reference the OpenType (font) spec :- >> >> https://www.microsoft.com/en-us/Typography/OpenTypeSpecification.aspx >> >> -phil. >> >> On 10/24/16, 9:10 AM, Vadim Pakhnushev wrote: >>> My go-to place for BMP spec >>> ishttps://msdn.microsoft.com/en-us/library/dd183391(v=vs.85).aspxwhich >>> is where we point from JavaFX docs. >>> >>> Vadim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Oct 24 18:52:26 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Oct 2016 11:52:26 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF In-Reply-To: <580E55D4.3010401@oracle.com> References: <0DEE1664-DF5D-4B7F-9D01-0AA0184AB4EA@oracle.com> <37c0b7d0-f6ca-4fbd-9a82-551cc1fc4f32@default> <75E8E39C-22DA-4605-A3A5-D2230FF1F16B@oracle.com> <5f0b2ef6-b3ab-478a-b4d5-1534403c4130@default> <385CB790-662E-4F87-9BE6-DA8639C5588B@oracle.com> <580E291B.2020302@oracle.com> <10F38BEE-AD35-478A-AFFA-96B54AC5571C@oracle.com> <580E2F53.9080501@oracle.com> <580E3831.3070301@oracle.com> <6CE8C0E2-D95B-4351-8F7C-C13D241DE11F@oracle.com> <580E55D4.3010401@oracle.com> Message-ID: <291FC440-C888-4EA0-A4E1-D7394448CE6B@oracle.com> I filed https://bugs.openjdk.java.net/browse/JDK-8168609 to track adding a format specification link for BMP. Thanks, Brian On Oct 24, 2016, at 11:41 AM, Philip Race wrote: > +1 to that .. and +1 to the webrev. > > -phil. > > On 10/24/16, 11:35 AM, Brian Burkhalter wrote: >> >> The content of the Bitmap Storage link looks good but the hyperlink is rather strange I agree. Perhaps the BMP link issue could go under a different issue as this has nothing to do with TIFF? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Oct 24 19:49:22 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 24 Oct 2016 12:49:22 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168498: ExifGPSTagSet and ExifTIFFTagSet should use string literals for String constants In-Reply-To: <65B6017C-9E5B-44BD-B372-CE8F2B169766@oracle.com> References: <65B6017C-9E5B-44BD-B372-CE8F2B169766@oracle.com> Message-ID: <0C84F95A-59C1-486C-AD6D-7A8F1C38275E@oracle.com> Updating to simply use a double-quoted string instead of a concatenation of chars. Thanks, Brian On Oct 21, 2016, at 12:18 PM, Brian Burkhalter wrote: > Please review this trivial change at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8168498 > Patch: [1] [1] diff --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java @@ -55,9 +55,7 @@ * * @see #TAG_GPS_VERSION_ID */ - public static final String GPS_VERSION_2_2 = - new String(new byte[] { '2', '2', '0', '0' }, - StandardCharsets.US_ASCII); + public static final String GPS_VERSION_2_2 = "2200"; --- a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java +++ b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java @@ -71,9 +71,7 @@ * * @see #TAG_EXIF_VERSION */ - public static final String EXIF_VERSION_2_1 = - new String(new byte[] { '0', '2', '1', '0' }, - StandardCharsets.US_ASCII); + public static final String EXIF_VERSION_2_1 = "0210"; @@ -82,9 +80,7 @@ * * @see #TAG_EXIF_VERSION */ - public static final String EXIF_VERSION_2_2 = - new String(new byte[] { '0', '2', '2', '0' }, - StandardCharsets.US_ASCII); + public static final String EXIF_VERSION_2_2 = "0220"; -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Oct 24 19:52:36 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 24 Oct 2016 12:52:36 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168498: ExifGPSTagSet and ExifTIFFTagSet should use string literals for String constants In-Reply-To: <0C84F95A-59C1-486C-AD6D-7A8F1C38275E@oracle.com> References: <65B6017C-9E5B-44BD-B372-CE8F2B169766@oracle.com> <0C84F95A-59C1-486C-AD6D-7A8F1C38275E@oracle.com> Message-ID: +1 -phil On 10/24/2016 12:49 PM, Brian Burkhalter wrote: > Updating to simply use a double-quoted string instead of a > concatenation of chars. > > Thanks, > > Brian > > On Oct 21, 2016, at 12:18 PM, Brian Burkhalter > > wrote: > >> Please review this trivial change at your convenience: >> >> Issue:https://bugs.openjdk.java.net/browse/JDK-8168498 >> Patch:[1] > > [1] diff > > --- > a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java > +++ > b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java > @@ -55,9 +55,7 @@ > * > * @see #TAG_GPS_VERSION_ID > */ > - public static final String GPS_VERSION_2_2 = > - new String(new byte[] { '2', '2', '0', '0' }, > - StandardCharsets.US_ASCII); > + public static final String GPS_VERSION_2_2 = "2200"; > > > --- > a/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java > +++ > b/src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java > @@ -71,9 +71,7 @@ > * > * @see #TAG_EXIF_VERSION > */ > - public static final String EXIF_VERSION_2_1 = > - new String(new byte[] { '0', '2', '1', '0' }, > - StandardCharsets.US_ASCII); > + public static final String EXIF_VERSION_2_1 = "0210"; > > > @@ -82,9 +80,7 @@ > * > * @see #TAG_EXIF_VERSION > */ > - public static final String EXIF_VERSION_2_2 = > - new String(new byte[] { '0', '2', '2', '0' }, > - StandardCharsets.US_ASCII); > + public static final String EXIF_VERSION_2_2 = "0220"; > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Oct 24 20:18:55 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 24 Oct 2016 23:18:55 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8168288: Dubious FontMetrics values from NullFontScaler In-Reply-To: <3DA8CB4A-6947-4C91-8D69-671CB6CDE14C@oracle.com> References: <3DA8CB4A-6947-4C91-8D69-671CB6CDE14C@oracle.com> Message-ID: +1 On 21.10.16 22:22, Brian Burkhalter wrote: > This looks OK to me. > > Brian > > On Oct 20, 2016, at 1:12 PM, Phil Race > wrote: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168288 >> Webrev: http://cr.openjdk.java.net/~prr/8168288/ >> >> Fixes some bizarre values you get for the "null" scaler as used >> when we find we can't use the font. >> >> More info in the bug report. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Oct 24 20:22:25 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 24 Oct 2016 23:22:25 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8165981: Consider making some classes in javax.imageio.plugins.tiff final In-Reply-To: <2375AA01-4530-4CF8-8443-9547CE0753D2@oracle.com> References: <2B5E42F2-8F82-4C21-98DB-A8516B7CC377@oracle.com> <89c6eefe-bfbe-829c-8be6-2900de0cfcc0@oracle.com> <1D0E5B40-2791-47AC-AF9A-C79154325080@oracle.com> <8dd572da-d18f-1169-aec7-27bd8fb40b5d@oracle.com> <2375AA01-4530-4CF8-8443-9547CE0753D2@oracle.com> Message-ID: <368623af-16a5-3654-8133-0fe4c39c20f2@oracle.com> ok +1 On 21.10.16 23:11, Brian Burkhalter wrote: > Barring objections to the contrary I am inclined to go with webrev.00. > There is no precedent in the public javax.imageio.plugins classes for > making getters and the like final. Note also that BMPImageWriteParam, > JPEGImageReadParam, and JPEGImageWriteParam and not final either. > > Thanks, > > Brian > > On Oct 18, 2016, at 2:24 PM, Brian Burkhalter > > wrote: > >> One could potentially change all the public getters in non-final >> classes in javax.imageio.plugins.tiff to be final as in >> >> http://cr.openjdk.java.net/~bpb/8165981/webrev.01/ >> >> or go even further and additionally refactor TIFFDirectory to be an >> interface implemented by the internal TIFFIFD class. In the interest >> of mitigating to an extent the difficulty encountered by any users >> potentially migrating from the original JAI Image I/O Tools package, I >> would however be more in favor of keeping the original proposal in >> this thread >> >> http://cr.openjdk.java.net/~bpb/8165981/webrev.00/ >> >> wherein only TIFFField and TIFFImageReadParam are made final. > -- Best regards, Sergey. From vadim.pakhnushev at oracle.com Tue Oct 25 05:52:10 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 25 Oct 2016 08:52:10 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8168364: [macosx] Delete unused class NSPrintinfo In-Reply-To: <580E54FC.2040208@oracle.com> References: <5808035E.70607@oracle.com> <580E54FC.2040208@oracle.com> Message-ID: <36faec21-ce5f-dce8-2925-a663b95b7b36@oracle.com> Looks good. Vadim On 24.10.2016 21:37, Philip Race wrote: > Can I get a 2nd reviewer on this one ? > > -phil. > > On 10/20/16, 3:52 AM, Sergey Bylokhov wrote: >> Looks fine. >> >> On 20.10.16 2:35, Philip Race wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8168364 >>> webrev : http://cr.openjdk.java.net/~prr/8168364/ >>> >>> NSPrintInfo is an Attribute so it can presumably be stuffed in an >>> AttributeSet. >>> Apart from being inaccessible to apps and unused it is not a good idea. >>> It was perhaps once used to (re-?)initialise fNSPrintInfo .. and that >>> needs to >>> be synchronized it seems. I fixed the one other unsynchronised use >>> of that >>> as well as deleting the unused code. >>> >>> -phil. >> >> From jayathirth.d.v at oracle.com Tue Oct 25 06:49:18 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 24 Oct 2016 23:49:18 -0700 (PDT) Subject: [OpenJDK 2D-Dev] REG : JDK-8168609 : No link to BMP specification in javax.imageio package documentation Message-ID: Hello All, I looked for Bitmap references from Microsoft and found below links : 1) Bitmap storage : https://msdn.microsoft.com/en-us/library/dd183391(v=vs.85).aspx (This is mentioned by Vadim also) 2) Bitmap Overview : https://msdn.microsoft.com/en-us/library/dd183377(v=vs.85).aspx 3) Bitmap Reference : This is subset of second link. https://msdn.microsoft.com/en-us/library/dd183388(v=vs.85).aspx 4) Bitmap basic header : https://msdn.microsoft.com/en-us/library/dd183371(v=vs.85).aspx I think 1 or 4 can be good candidate for common pointer to Bitmap information. Please let me know your inputs. Thanks, Jay From: Brian Burkhalter Sent: Tuesday, October 25, 2016 12:22 AM To: Philip Race Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8168367: Table in javax.imageio package description does not mention TIFF I filed https://bugs.openjdk.java.net/browse/JDK-8168609 to track adding a format specification link for BMP. Thanks, Brian On Oct 24, 2016, at 11:41 AM, Philip Race wrote: +1 to that .. and +1 to the webrev. -phil. On 10/24/16, 11:35 AM, Brian Burkhalter wrote: The content of the Bitmap Storage link looks good but the hyperlink is rather strange I agree. Perhaps the BMP link issue could go under a different issue as this has nothing to do with TIFF? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Oct 25 14:42:53 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 25 Oct 2016 07:42:53 -0700 Subject: [OpenJDK 2D-Dev] REG : JDK-8168609 : No link to BMP specification in javax.imageio package documentation In-Reply-To: References: Message-ID: Hi Jay, Thanks for investigating alternatives. Among them I think the first one is the best. Thanks, Brian On Oct 24, 2016, at 11:49 PM, Jayathirth D V wrote: > I looked for Bitmap references from Microsoft and found below links : > > 1) Bitmap storage :https://msdn.microsoft.com/en-us/library/dd183391(v=vs.85).aspx (This is mentioned by Vadim also) > 2) Bitmap Overview :https://msdn.microsoft.com/en-us/library/dd183377(v=vs.85).aspx > 3) Bitmap Reference : This is subset of second link. https://msdn.microsoft.com/en-us/library/dd183388(v=vs.85).aspx > 4) Bitmap basic header :https://msdn.microsoft.com/en-us/library/dd183371(v=vs.85).aspx > > I think 1 or 4 can be good candidate for common pointer to Bitmap information. > Please let me know your inputs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Oct 25 21:15:12 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 25 Oct 2016 14:15:12 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <580DC86E.3010902@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> <580AA2CD.6000703@oracle.com> <580B8CB2.0@oracle.com> <580DC86E.3010902@oracle.com> Message-ID: <580FCB60.4030706@oracle.com> Hi, This looks to work properly although I have a couple of nits and a concern that perhaps we just need to live with. * @requires (os.family == "mac") Why ? This test should be valid across OSes .. and SFAIK Mac is the only place it would fail without this fix. Both tests have this issue. I'd like the test(s) to use [something like] Point2D.Double p2 = new Point2D.Double(DIM/2.0, DIM/2.0); Otherwise the size of the shape to be filled neatly matches the span of the gradient and that can hide bugs. I am not sure how much to be concerned that the "raster" path relies on creating a custom paint whose size matches the bounds of the shape to which the paint will be applied .. 536 PaintContext context = sg2d.paint.createContext(sg2d.getDeviceColorModel(), userBounds, userBounds, sIdentityMatrix, sg2d.getRenderingHints()); 537 WritableRaster raster = (WritableRaster) (context.getRaster(userBounds.x, userBounds.y, userBounds.width, userBounds.height)); If applied to a very large shape it will need a very large image. But this seems the only way to get the gradient with the right reflect/repeat behaviour. -phil. On 10/24/16, 1:38 AM, Prasanta Sadhukhan wrote: > Please find modified webrev with Linear/Radial Gradient NO_CYCLE > option catered through quartz api and REPEAT/REFLECT option catered > via raster path. > http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.02/ > > Regards > Prasanta > On 10/22/2016 9:28 PM, Prasanta Sadhukhan wrote: >> >> >> On 10/22/2016 4:50 AM, Philip Race wrote: >>> Well it is confusing since in particular this exact change is in >>> both webrevs :- >>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.html >>> >>> >> Yes. This is same and I had to add this in both webrevs as >> TexturePaint patch is not yet approved. >>> One thing that I think seems less ideal about this fix, at least for >>> the Gradient case is that it is creating an image which shows >>> pixelisation >>> effects when I zoom in using Preview .. >>> >>> I don't think the previous code showed those effects so it may be you >>> want a hybrid, using the original code when you can. >> ok. I will make NO_CYCLE option to go through quartz and other >> REPEAT/REFLECT option to go though raster texturepaint path. >> >> Regards >> Prasanta >>> That probably is not an issue for TexturePaint .. >>> >>> -phil >>> >>> On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: >>>> No, this webrev supports LinearGradient/RadialGradient for all 3 >>>> options. The fix seems to be almost same as in TexturePaint but in >>>> a different else block in OSXSurfaceData.java. >>>> >>>> Regards >>>> Prasanta >>>> On 10/20/2016 9:31 PM, Phil Race wrote: >>>>> Leaving aside the tests, the webrev here looks to be the one proposed >>>>> for the TexturePaint bug. Did you get things mixed up ? >>>>> >>>>> -phil. >>>>> >>>>> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>>>>> Hi Phil, >>>>>> >>>>>> I have modified the webrev to support REFLECT and REPEAT albeit >>>>>> via raster path and not via Quartz api, as Quartz cannot handle >>>>>> REPEAT/REFLECT. >>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>>>>> >>>>>> Have tested with different fractions, stops, color. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>>>>> Hi, >>>>>>> >>>>>>> LinearGradientPaint has three options as to how it is extended >>>>>>> beyond the end point >>>>>>> >>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>>>>>> >>>>>>> >>>>>>> So far as I can see this code (and perhaps quartz) can only >>>>>>> handle NO_CYCLE .. >>>>>>> >>>>>>> If REFLECT or REPEAT are specified and Quartz can't handle it we >>>>>>> will need to >>>>>>> fall back to the raster path. >>>>>>> >>>>>>> I think it would be helpful to extend the test with examples >>>>>>> that use these and >>>>>>> also more than just the two colours .. add a variant that tries >>>>>>> more like 4 ... >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review a fix for jdk9 where it is seen that >>>>>>>> LinearGradientPaint is not getting printed on osx. >>>>>>>> The below webrev is only for LinearGradientPaint >>>>>>>> and RadialGradientPaint will be handled separately. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>>>>> >>>>>>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>>>>>> onwards. It handles simple GradientPaint. >>>>>>>> Code is added as per >>>>>>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>>>>> >>>>>>>> >>>>>>>> to use "CGGradientRef" quartz datatype to support >>>>>>>> LinearGradientPaint. >>>>>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>>>>> mentioned in CGGradientRef, i is "Easy to define more than two >>>>>>>> locations and colors." as we set 2 or more colors and 2 or more >>>>>>>> fractions in LinearGradientPaint. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> >>>>>> >>>>> >>>> >> > From prasanta.sadhukhan at oracle.com Wed Oct 26 06:01:28 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 26 Oct 2016 11:31:28 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <580FCB60.4030706@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> <580AA2CD.6000703@oracle.com> <580B8CB2.0@oracle.com> <580DC86E.3010902@oracle.com> <580FCB60.4030706@oracle.com> Message-ID: <7343411a-5941-c873-fd6e-d034ec616916@oracle.com> Please find the webrev with modified testcase http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.03/ Regards Prasanta On 10/26/2016 2:45 AM, Philip Race wrote: > Hi, > > This looks to work properly although I have a couple of nits and a > concern that perhaps we just need to live with. > > * @requires (os.family == "mac") > > Why ? This test should be valid across OSes .. and SFAIK Mac is the > only place it would fail without this fix. > Both tests have this issue. > > I'd like the test(s) to use [something like] > Point2D.Double p2 = new Point2D.Double(DIM/2.0, DIM/2.0); > > Otherwise the size of the shape to be filled neatly matches the span > of the gradient and that can hide bugs. > > I am not sure how much to be concerned that the "raster" path relies > on creating a custom paint whose > size matches the bounds of the shape to which the paint will be > applied .. > 536 PaintContext context = > sg2d.paint.createContext(sg2d.getDeviceColorModel(), userBounds, > userBounds, sIdentityMatrix, sg2d.getRenderingHints()); > 537 WritableRaster raster = (WritableRaster) > (context.getRaster(userBounds.x, userBounds.y, userBounds.width, > userBounds.height)); > > If applied to a very large shape it will need a very large image. > But this seems the only way to get the gradient with the right > reflect/repeat behaviour. > > -phil. > > On 10/24/16, 1:38 AM, Prasanta Sadhukhan wrote: >> Please find modified webrev with Linear/Radial Gradient NO_CYCLE >> option catered through quartz api and REPEAT/REFLECT option catered >> via raster path. >> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.02/ >> >> Regards >> Prasanta >> On 10/22/2016 9:28 PM, Prasanta Sadhukhan wrote: >>> >>> >>> On 10/22/2016 4:50 AM, Philip Race wrote: >>>> Well it is confusing since in particular this exact change is in >>>> both webrevs :- >>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.html >>>> >>>> >>> Yes. This is same and I had to add this in both webrevs as >>> TexturePaint patch is not yet approved. >>>> One thing that I think seems less ideal about this fix, at least for >>>> the Gradient case is that it is creating an image which shows >>>> pixelisation >>>> effects when I zoom in using Preview .. >>>> >>>> I don't think the previous code showed those effects so it may be you >>>> want a hybrid, using the original code when you can. >>> ok. I will make NO_CYCLE option to go through quartz and other >>> REPEAT/REFLECT option to go though raster texturepaint path. >>> >>> Regards >>> Prasanta >>>> That probably is not an issue for TexturePaint .. >>>> >>>> -phil >>>> >>>> On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: >>>>> No, this webrev supports LinearGradient/RadialGradient for all 3 >>>>> options. The fix seems to be almost same as in TexturePaint but in >>>>> a different else block in OSXSurfaceData.java. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 10/20/2016 9:31 PM, Phil Race wrote: >>>>>> Leaving aside the tests, the webrev here looks to be the one >>>>>> proposed >>>>>> for the TexturePaint bug. Did you get things mixed up ? >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi Phil, >>>>>>> >>>>>>> I have modified the webrev to support REFLECT and REPEAT albeit >>>>>>> via raster path and not via Quartz api, as Quartz cannot handle >>>>>>> REPEAT/REFLECT. >>>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>>>>>> >>>>>>> Have tested with different fractions, stops, color. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> LinearGradientPaint has three options as to how it is extended >>>>>>>> beyond the end point >>>>>>>> >>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>>>>>>> >>>>>>>> >>>>>>>> So far as I can see this code (and perhaps quartz) can only >>>>>>>> handle NO_CYCLE .. >>>>>>>> >>>>>>>> If REFLECT or REPEAT are specified and Quartz can't handle it >>>>>>>> we will need to >>>>>>>> fall back to the raster path. >>>>>>>> >>>>>>>> I think it would be helpful to extend the test with examples >>>>>>>> that use these and >>>>>>>> also more than just the two colours .. add a variant that tries >>>>>>>> more like 4 ... >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review a fix for jdk9 where it is seen that >>>>>>>>> LinearGradientPaint is not getting printed on osx. >>>>>>>>> The below webrev is only for LinearGradientPaint >>>>>>>>> and RadialGradientPaint will be handled separately. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>>>>>> >>>>>>>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>>>>>>> onwards. It handles simple GradientPaint. >>>>>>>>> Code is added as per >>>>>>>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>>>>>> >>>>>>>>> >>>>>>>>> to use "CGGradientRef" quartz datatype to support >>>>>>>>> LinearGradientPaint. >>>>>>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>>>>>> mentioned in CGGradientRef, i is "Easy to define more than >>>>>>>>> two locations and colors." as we set 2 or more colors and 2 or >>>>>>>>> more fractions in LinearGradientPaint. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> From jayathirth.d.v at oracle.com Wed Oct 26 07:09:41 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 26 Oct 2016 00:09:41 -0700 (PDT) Subject: [OpenJDK 2D-Dev] REG : JDK-8168609 : No link to BMP specification in javax.imageio package documentation In-Reply-To: References: Message-ID: <6da9e08d-5bb8-458a-952b-0beafe72d980@default> Hi Brian, Thanks for your input. I will make changes and include the first hyperlink. Thanks, Jay From: Brian Burkhalter Sent: Tuesday, October 25, 2016 8:13 PM To: Jayathirth D V Cc: Philip Race; 2d-dev Subject: Re: REG : JDK-8168609 : No link to BMP specification in javax.imageio package documentation Hi Jay, Thanks for investigating alternatives. Among them I think the first one is the best. Thanks, Brian On Oct 24, 2016, at 11:49 PM, Jayathirth D V wrote: I looked for Bitmap references from Microsoft and found below links : 1) Bitmap storage :https://msdn.microsoft.com/en-us/library/dd183391(v=vs.85).aspx (This is mentioned by Vadim also) 2) Bitmap Overview :https://msdn.microsoft.com/en-us/library/dd183377(v=vs.85).aspx 3) Bitmap Reference : This is subset of second link. https://msdn.microsoft.com/en-us/library/dd183388(v=vs.85).aspx 4) Bitmap basic header :https://msdn.microsoft.com/en-us/library/dd183371(v=vs.85).aspx I think 1 or 4 can be good candidate for common pointer to Bitmap information. Please let me know your inputs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Oct 26 07:20:44 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 26 Oct 2016 00:20:44 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168609: No link to BMP specification in javax.imageio package documentation Message-ID: <2c1653f0-0ed6-4a26-b699-c0d3853b6363@default> Hello All, Please review the following api-doc-only change to the javax.imageio package summary in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8168609 Webrev : http://cr.openjdk.java.net/~jdv/8168609/webrev.00/ Javadoc with change : http://cr.openjdk.java.net/~jdv/8168609/javadoc.00/package.html Issue : In the table following "All implementations of javax.imageio provide the following standard image format plug-ins:" all image formats have hyperlink which points to common information related to that particular format except BMP. Solution : Added standard link from Microsoft which gives information regarding how Bitmap as a file is stored. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batrak at jetbrains.com Wed Oct 26 13:28:58 2016 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Wed, 26 Oct 2016 16:28:58 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] Make automatic font substitution on macOS work for surrogate pairs Message-ID: Hello, I'd like to propose a patch to make automatic font substitution on macOS work for surrogate pairs. I have a Contributor status via agreement signed by JetBrains, hope someone can sponsor the patch. Currently, if requested font cannot render a Unicode character represented by a surrogate pair, no substitution is performed - Font.canDisplay will return false, and the character will be rendered as a 'missing' glyph. This behaviour doesn't violate any specification, but it looks like it can be easily improved, as underlying OS framework used under the hood does support surrogate pairs. The proposed change consists of two parts. First part is adjusting the code in CoreTextSupport.m to handle surrogate pairs while performing char-to-glyph mapping, by encoding non-displayable surrogate pairs using negative values of the codepoint, similar to how non-displayable BMP characters are encoded. Second part is fixing the rendering code (in CGGlyphImages.m), where wrong type was used to pass character values around, so that code for surrogate pairs handling, already present there, could work. I didn't include a test for this change, as it would depend on OS-specific font fallback mechanism and fonts installed, but I can create one that will work on a latest version of macOS with default fonts, if needed. Webrev for the fix is available at http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.00/ (kindly posted by my colleague, having access to cr.openjdk.java.net). To my knowledge, there's no ticket in OpenJDK issue tracker for the proposed enhancement. I can submit it via http://bugs.java.com/, if that's an obstacle. Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Oct 26 15:13:59 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 26 Oct 2016 08:13:59 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168609: No link to BMP specification in javax.imageio package documentation In-Reply-To: <2c1653f0-0ed6-4a26-b699-c0d3853b6363@default> References: <2c1653f0-0ed6-4a26-b699-c0d3853b6363@default> Message-ID: <1375CA02-3E2D-402A-A095-F42A15D7BFE8@oracle.com> Hi Jay, Note that [1] use the same link minus the version number [2]. I wonder whether it would be better to do that? Also I noticed that I forgot to update the copyright year when I checked in the same file yesterday so you might want to update it now. Thanks, Brian [1] http://www.digitalpreservation.gov/formats/fdd/fdd000189.shtml [2] https://msdn.microsoft.com/en-us/library/dd183391.aspx On Oct 26, 2016, at 12:20 AM, Jayathirth D V wrote: > Please review the following api-doc-only change to the javax.imageio package summary in JDK9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8168609 > Webrev : http://cr.openjdk.java.net/~jdv/8168609/webrev.00/ > Javadoc with change : http://cr.openjdk.java.net/~jdv/8168609/javadoc.00/package.html > > Issue : In the table following "All implementations of javax.imageio provide the following standard image format plug-ins:? all image formats have hyperlink which points to common information related to that particular format except BMP. > Solution : Added standard link from Microsoft which gives information regarding how Bitmap as a file is stored. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Oct 26 15:43:43 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 26 Oct 2016 08:43:43 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <7343411a-5941-c873-fd6e-d034ec616916@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> <580AA2CD.6000703@oracle.com> <580B8CB2.0@oracle.com> <580DC86E.3010902@oracle.com> <580FCB60.4030706@oracle.com> <7343411a-5941-c873-fd6e-d034ec616916@oracle.com> Message-ID: <5810CF2F.7080704@oracle.com> +1 -phil. On 10/25/16, 11:01 PM, Prasanta Sadhukhan wrote: > Please find the webrev with modified testcase > > http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.03/ > > Regards > Prasanta > On 10/26/2016 2:45 AM, Philip Race wrote: >> Hi, >> >> This looks to work properly although I have a couple of nits and a >> concern that perhaps we just need to live with. >> >> * @requires (os.family == "mac") >> >> Why ? This test should be valid across OSes .. and SFAIK Mac is the >> only place it would fail without this fix. >> Both tests have this issue. >> >> I'd like the test(s) to use [something like] >> Point2D.Double p2 = new Point2D.Double(DIM/2.0, DIM/2.0); >> >> Otherwise the size of the shape to be filled neatly matches the span >> of the gradient and that can hide bugs. >> >> I am not sure how much to be concerned that the "raster" path relies >> on creating a custom paint whose >> size matches the bounds of the shape to which the paint will be >> applied .. >> 536 PaintContext context = >> sg2d.paint.createContext(sg2d.getDeviceColorModel(), userBounds, >> userBounds, sIdentityMatrix, sg2d.getRenderingHints()); >> 537 WritableRaster raster = (WritableRaster) >> (context.getRaster(userBounds.x, userBounds.y, userBounds.width, >> userBounds.height)); >> >> If applied to a very large shape it will need a very large image. >> But this seems the only way to get the gradient with the right >> reflect/repeat behaviour. >> >> -phil. >> >> On 10/24/16, 1:38 AM, Prasanta Sadhukhan wrote: >>> Please find modified webrev with Linear/Radial Gradient NO_CYCLE >>> option catered through quartz api and REPEAT/REFLECT option catered >>> via raster path. >>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 10/22/2016 9:28 PM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> On 10/22/2016 4:50 AM, Philip Race wrote: >>>>> Well it is confusing since in particular this exact change is in >>>>> both webrevs :- >>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.html >>>>> >>>>> >>>> Yes. This is same and I had to add this in both webrevs as >>>> TexturePaint patch is not yet approved. >>>>> One thing that I think seems less ideal about this fix, at least for >>>>> the Gradient case is that it is creating an image which shows >>>>> pixelisation >>>>> effects when I zoom in using Preview .. >>>>> >>>>> I don't think the previous code showed those effects so it may be you >>>>> want a hybrid, using the original code when you can. >>>> ok. I will make NO_CYCLE option to go through quartz and other >>>> REPEAT/REFLECT option to go though raster texturepaint path. >>>> >>>> Regards >>>> Prasanta >>>>> That probably is not an issue for TexturePaint .. >>>>> >>>>> -phil >>>>> >>>>> On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: >>>>>> No, this webrev supports LinearGradient/RadialGradient for all 3 >>>>>> options. The fix seems to be almost same as in TexturePaint but >>>>>> in a different else block in OSXSurfaceData.java. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 10/20/2016 9:31 PM, Phil Race wrote: >>>>>>> Leaving aside the tests, the webrev here looks to be the one >>>>>>> proposed >>>>>>> for the TexturePaint bug. Did you get things mixed up ? >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> I have modified the webrev to support REFLECT and REPEAT albeit >>>>>>>> via raster path and not via Quartz api, as Quartz cannot handle >>>>>>>> REPEAT/REFLECT. >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>>>>>>> >>>>>>>> Have tested with different fractions, stops, color. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> LinearGradientPaint has three options as to how it is extended >>>>>>>>> beyond the end point >>>>>>>>> >>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>>>>>>>> >>>>>>>>> >>>>>>>>> So far as I can see this code (and perhaps quartz) can only >>>>>>>>> handle NO_CYCLE .. >>>>>>>>> >>>>>>>>> If REFLECT or REPEAT are specified and Quartz can't handle it >>>>>>>>> we will need to >>>>>>>>> fall back to the raster path. >>>>>>>>> >>>>>>>>> I think it would be helpful to extend the test with examples >>>>>>>>> that use these and >>>>>>>>> also more than just the two colours .. add a variant that >>>>>>>>> tries more like 4 ... >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for jdk9 where it is seen that >>>>>>>>>> LinearGradientPaint is not getting printed on osx. >>>>>>>>>> The below webrev is only for LinearGradientPaint >>>>>>>>>> and RadialGradientPaint will be handled separately. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>>>>>>> >>>>>>>>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>>>>>>>> onwards. It handles simple GradientPaint. >>>>>>>>>> Code is added as per >>>>>>>>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> to use "CGGradientRef" quartz datatype to support >>>>>>>>>> LinearGradientPaint. >>>>>>>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>>>>>>> mentioned in CGGradientRef, i is "Easy to define more than >>>>>>>>>> two locations and colors." as we set 2 or more colors and 2 >>>>>>>>>> or more fractions in LinearGradientPaint. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> > From brian.burkhalter at oracle.com Wed Oct 26 20:05:39 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 26 Oct 2016 13:05:39 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8164750: TIFF reading fails when ignoring metadata with BaselineTIFFTagSet removed Message-ID: <06829A48-EE85-48B8-B48F-8782C40FD183@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8164750 Patch: http://cr.openjdk.java.net/~bpb/8164750/webrev.00/ Currently if ignoreMetadata == true and the set of allowed TIFFTagSets does not contain the BaselineTIFFTagSet instance then image reading will fail as fields essential to reading and interpreting the data will be ignored. Thanks, Brian From philip.race at oracle.com Wed Oct 26 23:17:50 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 26 Oct 2016 16:17:50 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] Make automatic font substitution on macOS work for surrogate pairs In-Reply-To: References: Message-ID: <5811399E.8080003@oracle.com> Hi, I can file a bug on this if I can't find one. If you can email me the test it will help even if it is not checked in. -phil. On 10/26/16, 6:28 AM, Dmitry Batrak wrote: > Hello, > > I'd like to propose a patch to make automatic font substitution on > macOS work for surrogate pairs. > I have a Contributor status via agreement signed by JetBrains, hope > someone can sponsor the patch. > > Currently, if requested font cannot render a Unicode character > represented by a surrogate pair, > no substitution is performed - Font.canDisplay will return false, and > the character will be > rendered as a 'missing' glyph. This behaviour doesn't violate any > specification, but it looks like > it can be easily improved, as underlying OS framework used under the > hood does support surrogate pairs. > > The proposed change consists of two parts. First part is adjusting the > code in CoreTextSupport.m > to handle surrogate pairs while performing char-to-glyph mapping, by > encoding non-displayable > surrogate pairs using negative values of the codepoint, similar to how > non-displayable BMP characters > are encoded. Second part is fixing the rendering code (in > CGGlyphImages.m), where wrong type was used > to pass character values around, so that code for surrogate pairs > handling, already present there, > could work. > > I didn't include a test for this change, as it would depend on > OS-specific font fallback mechanism > and fonts installed, but I can create one that will work on a latest > version of macOS with default > fonts, if needed. > > Webrev for the fix is available at > http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.00/ > > (kindly posted by my colleague, having access to cr.openjdk.java.net > ). > > To my knowledge, there's no ticket in OpenJDK issue tracker for the > proposed enhancement. > I can submit it via http://bugs.java.com/, if that's an obstacle. > > Best regards, > Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Oct 27 07:08:47 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 27 Oct 2016 00:08:47 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168609: No link to BMP specification in javax.imageio package documentation In-Reply-To: <1375CA02-3E2D-402A-A095-F42A15D7BFE8@oracle.com> References: <2c1653f0-0ed6-4a26-b699-c0d3853b6363@default> <1375CA02-3E2D-402A-A095-F42A15D7BFE8@oracle.com> Message-ID: Hi Brian, Thanks for your inputs. I have updated the webrev to include updated hyperlink and copyright year. Please review it at your convenience: Webrev : http://cr.openjdk.java.net/~jdv/8168609/webrev.01/ Javadoc with change : http://cr.openjdk.java.net/~jdv/8168609/javadoc.01/package.html Thanks, Jay From: Brian Burkhalter Sent: Wednesday, October 26, 2016 8:44 PM To: Jayathirth D V Cc: Philip Race; Vadim Pakhnushev; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8168609: No link to BMP specification in javax.imageio package documentation Hi Jay, Note that [1] use the same link minus the version number [2]. I wonder whether it would be better to do that? Also I noticed that I forgot to update the copyright year when I checked in the same file yesterday so you might want to update it now. Thanks, Brian [1] http://www.digitalpreservation.gov/formats/fdd/fdd000189.shtml [2] https://msdn.microsoft.com/en-us/library/dd183391.aspx On Oct 26, 2016, at 12:20 AM, Jayathirth D V wrote: Please review the following api-doc-only change to the javax.imageio package summary in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8168609 Webrev : http://cr.openjdk.java.net/~jdv/8168609/webrev.00/ Javadoc with change : http://cr.openjdk.java.net/~jdv/8168609/javadoc.00/package.html Issue : In the table following "All implementations of javax.imageio provide the following standard image format plug-ins:" all image formats have hyperlink which points to common information related to that particular format except BMP. Solution : Added standard link from Microsoft which gives information regarding how Bitmap as a file is stored. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Oct 27 08:07:54 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 27 Oct 2016 13:37:54 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8040635: [macosx] Printing a shape filled with a texture doesn't work under Mac OS X In-Reply-To: <58087C13.9040302@oracle.com> References: <58087C13.9040302@oracle.com> Message-ID: Modified webrev after removal of @requires from testcase http://cr.openjdk.java.net/~psadhukhan/8040635/webrev.01/ Regards Prasanta On 10/20/2016 1:40 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for osx printing where it is seen that > TexturePaint pattern is not getting printed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8040635 > webrev: http://cr.openjdk.java.net/~psadhukhan/8040635/webrev.00/ > > The issue was because TexturePaint Evaluate function in native > QuartzSurfaceData.m uses LockImage() function to access texture > buffered image. > In LockImage(), it accesses image data by checking > javaImageInfo[sun_java2d_OSXOffScreenSurfaceData_kImageStolenIndex] and > javaImageInfo[sun_java2d_OSXOffScreenSurfaceData_kNeedToSyncFromJavaPixelsIndex] > > > and this variable "kImageStolenIndex" and > "kNeedToSyncFromJavaPixelsIndex" are set in OSXOffScreenSurfaceData > but OSXSurfaceData uses BufImgSurfaceData.createData which does not > set this variables > resulting in crash when it tries to access data buffer with wrong > unset index. > > Proposed fix is to use OSXOffscreenSurfaceData where the variables, > accessed by native, are set properly. > > Regards > Prasanta From dmitry.batrak at jetbrains.com Thu Oct 27 08:56:43 2016 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Thu, 27 Oct 2016 11:56:43 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] Make automatic font substitution on macOS work for surrogate pairs In-Reply-To: <5811399E.8080003@oracle.com> References: <5811399E.8080003@oracle.com> Message-ID: Sure, here's the simplest test, that can be used for visual inspection: import javax.swing.*; import java.awt.*; public class SurrogatesFallbackTest { public static void main(String[] args) { SwingUtilities.invokeLater(() -> { JFrame frame = new JFrame(); JLabel label = new JLabel(new String(Character.toChars(0x1d400))); // MATHEMATICAL BOLD CAPITAL A label.setFont(new Font("Menlo", Font.PLAIN, 36)); // expected to fallback to STIXGeneral frame.add(label); frame.pack(); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); frame.setLocationRelativeTo(null); frame.setVisible(true); }); } } I can convert it to an automatic test (rendering to a bitmap and comparing the result to rendering of 'missing' glyph), and add it to the webrev, if that makes sense. Best regards, Dmitry Batrak On Thu, Oct 27, 2016 at 2:17 AM, Philip Race wrote: > Hi, > > I can file a bug on this if I can't find one. > If you can email me the test it will help even if it is not checked in. > > -phil. > > On 10/26/16, 6:28 AM, Dmitry Batrak wrote: > > Hello, > > I'd like to propose a patch to make automatic font substitution on macOS > work for surrogate pairs. > I have a Contributor status via agreement signed by JetBrains, hope > someone can sponsor the patch. > > Currently, if requested font cannot render a Unicode character represented > by a surrogate pair, > no substitution is performed - Font.canDisplay will return false, and the > character will be > rendered as a 'missing' glyph. This behaviour doesn't violate any > specification, but it looks like > it can be easily improved, as underlying OS framework used under the hood > does support surrogate pairs. > > The proposed change consists of two parts. First part is adjusting the > code in CoreTextSupport.m > to handle surrogate pairs while performing char-to-glyph mapping, by > encoding non-displayable > surrogate pairs using negative values of the codepoint, similar to how > non-displayable BMP characters > are encoded. Second part is fixing the rendering code (in > CGGlyphImages.m), where wrong type was used > to pass character values around, so that code for surrogate pairs > handling, already present there, > could work. > > I didn't include a test for this change, as it would depend on OS-specific > font fallback mechanism > and fonts installed, but I can create one that will work on a latest > version of macOS with default > fonts, if needed. > > Webrev for the fix is available at > http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.00/ > (kindly posted by my colleague, having access to cr.openjdk.java.net). > > To my knowledge, there's no ticket in OpenJDK issue tracker for the > proposed enhancement. > I can submit it via http://bugs.java.com/, if that's an obstacle. > > Best regards, > Dmitry Batrak > > -- Dmitry Batrak Senior Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Oct 27 10:51:12 2016 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 27 Oct 2016 03:51:12 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <5810CF2F.7080704@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> <580AA2CD.6000703@oracle.com> <580B8CB2.0@oracle.com> <580DC86E.3010902@oracle.com> <580FCB60.4030706@oracle.com> <7343411a-5941-c873-fd6e-d034ec616916@oracle.com> <5810CF2F.7080704@oracle.com> Message-ID: <057d883f-5778-4a25-bc05-21e368556b80@default> Hi Prasanta, Changes are working fine. Thanks, Jay -----Original Message----- From: Philip Race Sent: Wednesday, October 26, 2016 9:14 PM To: Prasanta Sadhukhan Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. +1 -phil. On 10/25/16, 11:01 PM, Prasanta Sadhukhan wrote: > Please find the webrev with modified testcase > > http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.03/ > > Regards > Prasanta > On 10/26/2016 2:45 AM, Philip Race wrote: >> Hi, >> >> This looks to work properly although I have a couple of nits and a >> concern that perhaps we just need to live with. >> >> * @requires (os.family == "mac") >> >> Why ? This test should be valid across OSes .. and SFAIK Mac is the >> only place it would fail without this fix. >> Both tests have this issue. >> >> I'd like the test(s) to use [something like] >> Point2D.Double p2 = new Point2D.Double(DIM/2.0, DIM/2.0); >> >> Otherwise the size of the shape to be filled neatly matches the span >> of the gradient and that can hide bugs. >> >> I am not sure how much to be concerned that the "raster" path relies >> on creating a custom paint whose size matches the bounds of the shape >> to which the paint will be applied .. >> 536 PaintContext context = >> sg2d.paint.createContext(sg2d.getDeviceColorModel(), userBounds, >> userBounds, sIdentityMatrix, sg2d.getRenderingHints()); >> 537 WritableRaster raster = (WritableRaster) >> (context.getRaster(userBounds.x, userBounds.y, userBounds.width, >> userBounds.height)); >> >> If applied to a very large shape it will need a very large image. >> But this seems the only way to get the gradient with the right >> reflect/repeat behaviour. >> >> -phil. >> >> On 10/24/16, 1:38 AM, Prasanta Sadhukhan wrote: >>> Please find modified webrev with Linear/Radial Gradient NO_CYCLE >>> option catered through quartz api and REPEAT/REFLECT option catered >>> via raster path. >>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 10/22/2016 9:28 PM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> On 10/22/2016 4:50 AM, Philip Race wrote: >>>>> Well it is confusing since in particular this exact change is in >>>>> both webrevs :- >>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java. >>>>> desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.h >>>>> tml >>>>> >>>>> >>>> Yes. This is same and I had to add this in both webrevs as >>>> TexturePaint patch is not yet approved. >>>>> One thing that I think seems less ideal about this fix, at least >>>>> for the Gradient case is that it is creating an image which shows >>>>> pixelisation effects when I zoom in using Preview .. >>>>> >>>>> I don't think the previous code showed those effects so it may be >>>>> you want a hybrid, using the original code when you can. >>>> ok. I will make NO_CYCLE option to go through quartz and other >>>> REPEAT/REFLECT option to go though raster texturepaint path. >>>> >>>> Regards >>>> Prasanta >>>>> That probably is not an issue for TexturePaint .. >>>>> >>>>> -phil >>>>> >>>>> On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: >>>>>> No, this webrev supports LinearGradient/RadialGradient for all 3 >>>>>> options. The fix seems to be almost same as in TexturePaint but >>>>>> in a different else block in OSXSurfaceData.java. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 10/20/2016 9:31 PM, Phil Race wrote: >>>>>>> Leaving aside the tests, the webrev here looks to be the one >>>>>>> proposed for the TexturePaint bug. Did you get things mixed up ? >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>>>>>>> Hi Phil, >>>>>>>> >>>>>>>> I have modified the webrev to support REFLECT and REPEAT albeit >>>>>>>> via raster path and not via Quartz api, as Quartz cannot handle >>>>>>>> REPEAT/REFLECT. >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>>>>>>> >>>>>>>> Have tested with different fractions, stops, color. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> LinearGradientPaint has three options as to how it is extended >>>>>>>>> beyond the end point >>>>>>>>> >>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGra >>>>>>>>> dientPaint.CycleMethod.html >>>>>>>>> >>>>>>>>> >>>>>>>>> So far as I can see this code (and perhaps quartz) can only >>>>>>>>> handle NO_CYCLE .. >>>>>>>>> >>>>>>>>> If REFLECT or REPEAT are specified and Quartz can't handle it >>>>>>>>> we will need to fall back to the raster path. >>>>>>>>> >>>>>>>>> I think it would be helpful to extend the test with examples >>>>>>>>> that use these and also more than just the two colours .. add >>>>>>>>> a variant that tries more like 4 ... >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review a fix for jdk9 where it is seen that >>>>>>>>>> LinearGradientPaint is not getting printed on osx. >>>>>>>>>> The below webrev is only for LinearGradientPaint and >>>>>>>>>> RadialGradientPaint will be handled separately. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>>>>>>> >>>>>>>>>> Issue was LinearGradientPaint is not handled in osx from jdk7 >>>>>>>>>> onwards. It handles simple GradientPaint. >>>>>>>>>> Code is added as per >>>>>>>>>> https://developer.apple.com/library/content/documentation/Gra >>>>>>>>>> phicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_sh >>>>>>>>>> adings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> to use "CGGradientRef" quartz datatype to support >>>>>>>>>> LinearGradientPaint. >>>>>>>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>>>>>>> mentioned in CGGradientRef, i is "Easy to define more than >>>>>>>>>> two locations and colors." as we set 2 or more colors and 2 >>>>>>>>>> or more fractions in LinearGradientPaint. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> > From brian.burkhalter at oracle.com Thu Oct 27 15:16:11 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 27 Oct 2016 08:16:11 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168609: No link to BMP specification in javax.imageio package documentation In-Reply-To: References: <2c1653f0-0ed6-4a26-b699-c0d3853b6363@default> <1375CA02-3E2D-402A-A095-F42A15D7BFE8@oracle.com> Message-ID: Hi Jay, It looks OK to me. It would be good also to see what Phil or others think. Thanks, Brian On Oct 27, 2016, at 12:08 AM, Jayathirth D V wrote: > Thanks for your inputs. > I have updated the webrev to include updated hyperlink and copyright year. > Please review it at your convenience: > Webrev : http://cr.openjdk.java.net/~jdv/8168609/webrev.01/ > Javadoc with change : http://cr.openjdk.java.net/~jdv/8168609/javadoc.01/package.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Oct 27 15:44:51 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 27 Oct 2016 08:44:51 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8168609: No link to BMP specification in javax.imageio package documentation In-Reply-To: References: <2c1653f0-0ed6-4a26-b699-c0d3853b6363@default> <1375CA02-3E2D-402A-A095-F42A15D7BFE8@oracle.com> Message-ID: <3ce454f3-8957-819c-ee11-fd65ab19b1db@oracle.com> +1 -phil On 10/27/2016 08:16 AM, Brian Burkhalter wrote: > Hi Jay, > > It looks OK to me. It would be good also to see what Phil or others think. > > Thanks, > > Brian > > On Oct 27, 2016, at 12:08 AM, Jayathirth D V > > wrote: > >> Thanks for your inputs. >> I have updated the webrev to include updated hyperlink and copyright >> year. >> Please review it at your convenience: >> Webrev : http://cr.openjdk.java.net/~jdv/8168609/webrev.01/ >> >> Javadoc with change : >> http://cr.openjdk.java.net/~jdv/8168609/javadoc.01/package.html >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Oct 27 16:44:02 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 27 Oct 2016 09:44:02 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8040635: [macosx] Printing a shape filled with a texture doesn't work under Mac OS X In-Reply-To: References: <58087C13.9040302@oracle.com> Message-ID: <7e8377ca-f49f-5f00-4aa1-822b606787c1@oracle.com> +1 -phil. On 10/27/2016 01:07 AM, Prasanta Sadhukhan wrote: > Modified webrev after removal of @requires from testcase > > http://cr.openjdk.java.net/~psadhukhan/8040635/webrev.01/ > > Regards > Prasanta > On 10/20/2016 1:40 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for osx printing where it is seen that >> TexturePaint pattern is not getting printed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8040635 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8040635/webrev.00/ >> >> The issue was because TexturePaint Evaluate function in native >> QuartzSurfaceData.m uses LockImage() function to access texture >> buffered image. >> In LockImage(), it accesses image data by checking >> javaImageInfo[sun_java2d_OSXOffScreenSurfaceData_kImageStolenIndex] and >> javaImageInfo[sun_java2d_OSXOffScreenSurfaceData_kNeedToSyncFromJavaPixelsIndex] >> >> >> and this variable "kImageStolenIndex" and >> "kNeedToSyncFromJavaPixelsIndex" are set in OSXOffScreenSurfaceData >> but OSXSurfaceData uses BufImgSurfaceData.createData which does not >> set this variables >> resulting in crash when it tries to access data buffer with wrong >> unset index. >> >> Proposed fix is to use OSXOffscreenSurfaceData where the variables, >> accessed by native, are set properly. >> >> Regards >> Prasanta > From philip.race at oracle.com Thu Oct 27 20:31:32 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 27 Oct 2016 13:31:32 -0700 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: <5810CF2F.7080704@oracle.com> References: <57E39E53.8080305@oracle.com> <57EAD86B.2010006@oracle.com> <58088CEC.1010804@oracle.com> <58099C44.90609@oracle.com> <580AA2CD.6000703@oracle.com> <580B8CB2.0@oracle.com> <580DC86E.3010902@oracle.com> <580FCB60.4030706@oracle.com> <7343411a-5941-c873-fd6e-d034ec616916@oracle.com> <5810CF2F.7080704@oracle.com> Message-ID: Sorry .. I forgot one thing I meant to mention. Please remove all those commented out frprintf debugging statements. 298 //fprintf(stderr, "gradientInfo->start.x %f, gradientInfo->start.y %f\n", 299 // gradientInfo->start.x, gradientInfo->start.y); 300 //fprintf(stderr, "gradientInfo->end.x %f, gradientInfo->end.y %f\n", 301 // gradientInfo->end.x, gradientInfo->end.y); -phil. On 10/26/2016 08:43 AM, Philip Race wrote: > +1 > > -phil. > > On 10/25/16, 11:01 PM, Prasanta Sadhukhan wrote: >> Please find the webrev with modified testcase >> >> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.03/ >> >> Regards >> Prasanta >> On 10/26/2016 2:45 AM, Philip Race wrote: >>> Hi, >>> >>> This looks to work properly although I have a couple of nits and a >>> concern that perhaps we just need to live with. >>> >>> * @requires (os.family == "mac") >>> >>> Why ? This test should be valid across OSes .. and SFAIK Mac is the >>> only place it would fail without this fix. >>> Both tests have this issue. >>> >>> I'd like the test(s) to use [something like] >>> Point2D.Double p2 = new Point2D.Double(DIM/2.0, DIM/2.0); >>> >>> Otherwise the size of the shape to be filled neatly matches the span >>> of the gradient and that can hide bugs. >>> >>> I am not sure how much to be concerned that the "raster" path relies >>> on creating a custom paint whose >>> size matches the bounds of the shape to which the paint will be >>> applied .. >>> 536 PaintContext context = >>> sg2d.paint.createContext(sg2d.getDeviceColorModel(), userBounds, >>> userBounds, sIdentityMatrix, sg2d.getRenderingHints()); >>> 537 WritableRaster raster = (WritableRaster) >>> (context.getRaster(userBounds.x, userBounds.y, userBounds.width, >>> userBounds.height)); >>> >>> If applied to a very large shape it will need a very large image. >>> But this seems the only way to get the gradient with the right >>> reflect/repeat behaviour. >>> >>> -phil. >>> >>> On 10/24/16, 1:38 AM, Prasanta Sadhukhan wrote: >>>> Please find modified webrev with Linear/Radial Gradient NO_CYCLE >>>> option catered through quartz api and REPEAT/REFLECT option catered >>>> via raster path. >>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.02/ >>>> >>>> Regards >>>> Prasanta >>>> On 10/22/2016 9:28 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> >>>>> On 10/22/2016 4:50 AM, Philip Race wrote: >>>>>> Well it is confusing since in particular this exact change is in >>>>>> both webrevs :- >>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m.sdiff.html >>>>>> >>>>>> >>>>> Yes. This is same and I had to add this in both webrevs as >>>>> TexturePaint patch is not yet approved. >>>>>> One thing that I think seems less ideal about this fix, at least for >>>>>> the Gradient case is that it is creating an image which shows >>>>>> pixelisation >>>>>> effects when I zoom in using Preview .. >>>>>> >>>>>> I don't think the previous code showed those effects so it may be >>>>>> you >>>>>> want a hybrid, using the original code when you can. >>>>> ok. I will make NO_CYCLE option to go through quartz and other >>>>> REPEAT/REFLECT option to go though raster texturepaint path. >>>>> >>>>> Regards >>>>> Prasanta >>>>>> That probably is not an issue for TexturePaint .. >>>>>> >>>>>> -phil >>>>>> >>>>>> On 10/20/16, 9:40 PM, Prasanta Sadhukhan wrote: >>>>>>> No, this webrev supports LinearGradient/RadialGradient for all 3 >>>>>>> options. The fix seems to be almost same as in TexturePaint but >>>>>>> in a different else block in OSXSurfaceData.java. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 10/20/2016 9:31 PM, Phil Race wrote: >>>>>>>> Leaving aside the tests, the webrev here looks to be the one >>>>>>>> proposed >>>>>>>> for the TexturePaint bug. Did you get things mixed up ? >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 10/20/2016 02:22 AM, Prasanta Sadhukhan wrote: >>>>>>>>> Hi Phil, >>>>>>>>> >>>>>>>>> I have modified the webrev to support REFLECT and REPEAT >>>>>>>>> albeit via raster path and not via Quartz api, as Quartz >>>>>>>>> cannot handle REPEAT/REFLECT. >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.01/ >>>>>>>>> >>>>>>>>> Have tested with different fractions, stops, color. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 9/28/2016 2:06 AM, Philip Race wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> LinearGradientPaint has three options as to how it is >>>>>>>>>> extended beyond the end point >>>>>>>>>> >>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/MultipleGradientPaint.CycleMethod.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So far as I can see this code (and perhaps quartz) can only >>>>>>>>>> handle NO_CYCLE .. >>>>>>>>>> >>>>>>>>>> If REFLECT or REPEAT are specified and Quartz can't handle it >>>>>>>>>> we will need to >>>>>>>>>> fall back to the raster path. >>>>>>>>>> >>>>>>>>>> I think it would be helpful to extend the test with examples >>>>>>>>>> that use these and >>>>>>>>>> also more than just the two colours .. add a variant that >>>>>>>>>> tries more like 4 ... >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 9/22/16, 2:03 AM, Prasanta Sadhukhan wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for jdk9 where it is seen that >>>>>>>>>>> LinearGradientPaint is not getting printed on osx. >>>>>>>>>>> The below webrev is only for LinearGradientPaint >>>>>>>>>>> and RadialGradientPaint will be handled separately. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162796 >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8162796/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Issue was LinearGradientPaint is not handled in osx from >>>>>>>>>>> jdk7 onwards. It handles simple GradientPaint. >>>>>>>>>>> Code is added as per >>>>>>>>>>> https://developer.apple.com/library/content/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_shadings/dq_shadings.html#//apple_ref/doc/uid/TP30001066-CH207-TPXREF101 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> to use "CGGradientRef" quartz datatype to support >>>>>>>>>>> LinearGradientPaint. >>>>>>>>>>> CGGradientRef is used compared to CGShadingRef because it is >>>>>>>>>>> mentioned in CGGradientRef, i is "Easy to define more than >>>>>>>>>>> two locations and colors." as we set 2 or more colors and 2 >>>>>>>>>>> or more fractions in LinearGradientPaint. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Oct 28 11:27:17 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 28 Oct 2016 14:27:17 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: JDK-8165212 VolatileImage should not be compatible with GraphicsConfiguration which transform is changed In-Reply-To: <4d989226-9ef4-4d19-8e49-3f7fc2ba0c98@default> References: <4d989226-9ef4-4d19-8e49-3f7fc2ba0c98@default> Message-ID: 350 if (!isAccelerationEnabled()) { 351 // Ideally there is no need to re-create a software surface. But 352 // some OSs allow changes to display state at runtime. Such a 353 // provision would cause mismatch in graphics configuration of the 354 // display and the surface. Hence we re-create the software surface 355 // as well. 356 sdBackup = null; 357 sdCurrent = getBackupSurface(); 358 } 359 } It seems that the surface is always recreated when the acceleration is not enabled. May be it should be only done when the graphics configuration transform scales are differ from the ones from vImg graphics configuration? Thanks, Alexandr. On 10/14/2016 1:38 PM, Prahalad Kumar Narayanan wrote: > > Hello Everyone > > Good day to you. > > Request your time in reviewing the fix for- > > Bug : JDK-8165212 > > Title : VolatileImage should not be compatible with > GraphicsConfiguration which transform is changed > > Description on the bug- > > . As per the bug, Volatile Image's graphics configuration is > not updated when the host machine display's DPI is changed at runtime > (while still running the java app). In addition, the method > contentsLost() does not return true when display?s DPI is modified. > > . It is important to note that, the issue is not reproducible > with D3D/OpenGL backend. It is reproducible with non-accelerated > Volatile Image. > > Root Cause > > . A callback method- displayChanged() in > VolatileSurfaceManager.java is invoked when display's settings (DPI) > is modified. > > . The callback method, currently, updates the graphics > configuration only for Accelerated volatile image. Graphics > configuration is not updated for non-accelerated system memory based > VolatileImage. > > . Until recently, there wasn't any need for updating graphics > configuration for non-accelerated volatileImage. However, Win 8.1 and > above provide feature to dynamically update the DPI setting (without > requiring for log-off/ log-in), which causes the current bug. > > Bug Fix > > . First, the callback method is modified to update graphics > configuration for non-accelerated volatile image also. > > . An update to graphics configuration might require re-creation > of the surface. Especially, when the scale factor is increased. Hence > the system memory based backupSurface is re-created here. > > . The above change is followed by change to Validate() API, so > that the backup surface re-creation in displayChanged() method, > correctly returns IMAGE_RESTORED from validate() API. This way, the > code flow for non-accelerated Volatile Images behaves just the same > way as accelerated volatile images. > > . Approximately 81 Jtreg test cases (that contained > VolatileImage) were run on win7, linux, and osx. No new regressions > have been found after the modification. > > . In addition, a manual test case has been provided to ensure > the proper functioning of the fix > > Kindly review the changes and provide your suggestions > > Review link: http://cr.openjdk.java.net/~pnarayanan/8165212/webrev.00/ > > Thank you for your time in review > > Have a good day > > Prahalad N. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Oct 28 13:40:45 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 28 Oct 2016 16:40:45 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> Message-ID: <7b8b3a85-4547-6265-688c-9d2eb9b9205d@oracle.com> On 10/11/2016 10:13 PM, Sergey Bylokhov wrote: > On 11.10.16 21:54, Jim Graham wrote: >> Additionally, for AA rendering, there is no such thing as >> "setClip(someShape)" and "fill(sameShape)" being identical no matter how >> much we predict which rules they may want because clips are inherently >> non-AA and so the fuzzy pixels along the boundary of an AA shape will be >> randomly clipped or included. >> >> When all is said and done I feel (not very strongly) it would be best to >> have clipping remain unaffected by the biasing of STROKE hints, but part >> of that is driven by the fact that I think it can be fixed with a couple >> of lines of code in SG2D/LoopPipe... > > I guess a bottom line is that it is require an additional > investigation. I am not exactly sure, but my expectation is that > fillRect(x,y,w,h)/drawImage(x,y,w,h) + setClip(x,y,w,h) should work in > a similar way(covers the same pixels). And the question should this > behavior be exactly the same as fill(RectShape) + setClip(RectShape) > is unclear (I am not sure is it a critical issue or not) > Right now I tried to fix overlapping, which produce visible artifacts > and were considered as a bugs. The next issue which I would like to > fix is a overlapping of drawImage(). I just created a small sample [1] which fills a rectangle (x, y, w, y), creates an image with size (w, h) and draws the image into the area (x, y, w, h). With the floating point scale like 1.5 the image does not exactly fits the area filled by the rectangle (see image [2] generated by the code [1]). This is because the Graphics.drawImage(...) calls DrawImage.renderImageXform() which uses floor and ceil methods for the region corner rounding: final int dx1 = Math.max((int) Math.floor(ddx1), clip.getLoX()); final int dy1 = Math.max((int) Math.floor(ddy1), clip.getLoY()); final int dx2 = Math.min((int) Math.ceil(ddx2), clip.getHiX()); final int dy2 = Math.min((int) Math.ceil(ddy2), clip.getHiY()); But the Graphics.fillRect() falls down to the code which just cast the transformed coordinates to int. Why the floor/ceil methods are used for the image region rounding? Is it possible to change this to fit the rule for the filled rectangles rounding? [1] http://cr.openjdk.java.net/~alexsch/fpapi/code/FillRectAndImageTest.java [2] http://cr.openjdk.java.net/~alexsch/fpapi/screenshots/rect-and-image.png Thanks, Alexandr. > > From james.graham at oracle.com Fri Oct 28 21:33:56 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 28 Oct 2016 14:33:56 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <7b8b3a85-4547-6265-688c-9d2eb9b9205d@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> <7b8b3a85-4547-6265-688c-9d2eb9b9205d@oracle.com> Message-ID: <13f3b3f9-63a9-79a3-1511-b9edc783d8f5@oracle.com> Hi Alexandr, That code is coming up with maximum extents for the operation, not the exact edges that will be rendered. It passes them down to the native TransformHelper method which refines them using the exact calculations it will use to render the pixels. Admittedly, the calculations you point out below in the DrawImage pipeline would more accurately note that the right/bottom edges fall on a .5 pixel location and shouldn't be included, but I didn't want to make that decision using one set of equations while the actual rendering uses different math down below. Note that if you had a rotation then there are lots of unused pixels on each scanline which are computed and refined by the native code. Those calculations would also be performing the "included/excluded" calculations using the actual rendering equations rather than these higher level boundary equations so even if we switched to "ceil(N - 0.5)" calculations up here for the bounding box to cure the scaled drawImage we'd still potentially have overshoot due to the fixed point/floating point bit errors on those rotated edges. With a general transform it would be difficult to detect the occasional extra pixel being rendered due to bit errors, but it is much easier with these scale-only transforms. One change we could make would be to do the ceil(N-0.5) calculation in the bounds setup code which would "fix" the scale only case. Another might be to fix the scale pipeline to handle arbitrary formats - we could write a related "ScaleHelper" native method that would do the same thing that TransformHelper does. TransformHelper takes a transform loop that transforms pixels to ARGB, and a separate Blit or MaskBlit that blends ARGB pixels into the destination and it runs the first loop into a temporary local buffer on the C call stack and the second loop to blend the pixels into the dest. A ScaleHelper loop would do the same, but with a "Scale(XXX to ARGB)" loop for the first half. Finally, we could also add more ScaleBlit loops for more source/dest pairs so these scales would happen more directly. Unfortunately, many of the missing cases would require creating scale loops that also do blending and the only macros we currently have for direct src->dest scaling are opaque-to-opaque pixel store operations. The first solution is simpler and easier to add, the second one would help with all scales that fall outside our loops. The last solution would arguably provide the highest performance for any source/dest case that we care about (and with the advent of HiDPI we now care about a lot more cases). I'd file 3 bugs: - Scaled and transformed drawImage can overshoot with some scales (1.5) - Add more ScaledBlit graphics primitive instances for common HiDPI cases - Create a general purpose Scale helper method along the lines of TransformHelper The first could be fixed soon with the proposed change you talk about below... ...jim On 10/28/16 6:40 AM, Alexandr Scherbatiy wrote: > On 10/11/2016 10:13 PM, Sergey Bylokhov wrote: >> On 11.10.16 21:54, Jim Graham wrote: >>> Additionally, for AA rendering, there is no such thing as >>> "setClip(someShape)" and "fill(sameShape)" being identical no matter how >>> much we predict which rules they may want because clips are inherently >>> non-AA and so the fuzzy pixels along the boundary of an AA shape will be >>> randomly clipped or included. >>> >>> When all is said and done I feel (not very strongly) it would be best to >>> have clipping remain unaffected by the biasing of STROKE hints, but part >>> of that is driven by the fact that I think it can be fixed with a couple >>> of lines of code in SG2D/LoopPipe... >> >> I guess a bottom line is that it is require an additional investigation. I am not exactly sure, but my expectation is >> that fillRect(x,y,w,h)/drawImage(x,y,w,h) + setClip(x,y,w,h) should work in a similar way(covers the same pixels). And >> the question should this behavior be exactly the same as fill(RectShape) + setClip(RectShape) is unclear (I am not >> sure is it a critical issue or not) >> Right now I tried to fix overlapping, which produce visible artifacts and were considered as a bugs. The next issue >> which I would like to fix is a overlapping of drawImage(). > I just created a small sample [1] which fills a rectangle (x, y, w, y), creates an image with size (w, h) and draws > the image into the area (x, y, w, h). > With the floating point scale like 1.5 the image does not exactly fits the area filled by the rectangle (see image [2] > generated by the code [1]). > > This is because the Graphics.drawImage(...) calls DrawImage.renderImageXform() which uses floor and ceil methods for > the region corner rounding: > final int dx1 = Math.max((int) Math.floor(ddx1), clip.getLoX()); > final int dy1 = Math.max((int) Math.floor(ddy1), clip.getLoY()); > final int dx2 = Math.min((int) Math.ceil(ddx2), clip.getHiX()); > final int dy2 = Math.min((int) Math.ceil(ddy2), clip.getHiY()); > > But the Graphics.fillRect() falls down to the code which just cast the transformed coordinates to int. > > Why the floor/ceil methods are used for the image region rounding? > Is it possible to change this to fit the rule for the filled rectangles rounding? > > [1] http://cr.openjdk.java.net/~alexsch/fpapi/code/FillRectAndImageTest.java > [2] http://cr.openjdk.java.net/~alexsch/fpapi/screenshots/rect-and-image.png > > Thanks, > Alexandr. >> >> > From james.graham at oracle.com Fri Oct 28 21:47:13 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 28 Oct 2016 14:47:13 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales In-Reply-To: <13f3b3f9-63a9-79a3-1511-b9edc783d8f5@oracle.com> References: <7a49e551-871b-f1c7-6977-1acbb9bf92d9@oracle.com> <7a9d3adc-4242-e4d8-3244-d6a9d7c30b9d@oracle.com> <23b34ddd-0adc-fc92-921a-7ca48895767a@oracle.com> <630b6fc9-3284-cffc-1ff4-45c1c9463733@oracle.com> <6ba5161d-5025-a586-f6f6-cb878254e0b9@oracle.com> <5d20912a-f31e-95c4-7b42-63da4cc3945f@oracle.com> <39a1176d-ad99-22ba-f2a2-33d7c3cca398@oracle.com> <91cbe195-9848-4de5-4195-a938bbe7fa91@oracle.com> <2ec937c9-bf2f-faa6-bbba-4a6780a3b908@oracle.com> <09d64b48-2432-1258-9f48-0378cbafac4e@oracle.com> <7b8b3a85-4547-6265-688c-9d2eb9b9205d@oracle.com> <13f3b3f9-63a9-79a3-1511-b9edc783d8f5@oracle.com> Message-ID: <8c4463d9-82f4-7379-134c-bb20328866fa@oracle.com> I suppose that there could be a 4th bug about the fact that the trimming/refining code in the native TransformHelper is based on an inverse transform and subject to bit error, but it's not easy to figure out how to refine it further. Note that it could also cause us to omit a row of pixels in some cases if the rounding went the other way. Refining it further could be easier than the 2nd two solutions, but not really noticeable if we just get do the more conservative calculations on the bounds equations in the setup code... ...jim On 10/28/16 2:33 PM, Jim Graham wrote: > Hi Alexandr, > > That code is coming up with maximum extents for the operation, not the exact edges that will be rendered. It passes > them down to the native TransformHelper method which refines them using the exact calculations it will use to render the > pixels. > > Admittedly, the calculations you point out below in the DrawImage pipeline would more accurately note that the > right/bottom edges fall on a .5 pixel location and shouldn't be included, but I didn't want to make that decision using > one set of equations while the actual rendering uses different math down below. > > Note that if you had a rotation then there are lots of unused pixels on each scanline which are computed and refined by > the native code. Those calculations would also be performing the "included/excluded" calculations using the actual > rendering equations rather than these higher level boundary equations so even if we switched to "ceil(N - 0.5)" > calculations up here for the bounding box to cure the scaled drawImage we'd still potentially have overshoot due to the > fixed point/floating point bit errors on those rotated edges. > > With a general transform it would be difficult to detect the occasional extra pixel being rendered due to bit errors, > but it is much easier with these scale-only transforms. > > One change we could make would be to do the ceil(N-0.5) calculation in the bounds setup code which would "fix" the scale > only case. > > Another might be to fix the scale pipeline to handle arbitrary formats - we could write a related "ScaleHelper" native > method that would do the same thing that TransformHelper does. TransformHelper takes a transform loop that transforms > pixels to ARGB, and a separate Blit or MaskBlit that blends ARGB pixels into the destination and it runs the first loop > into a temporary local buffer on the C call stack and the second loop to blend the pixels into the dest. A ScaleHelper > loop would do the same, but with a "Scale(XXX to ARGB)" loop for the first half. > > Finally, we could also add more ScaleBlit loops for more source/dest pairs so these scales would happen more directly. > Unfortunately, many of the missing cases would require creating scale loops that also do blending and the only macros we > currently have for direct src->dest scaling are opaque-to-opaque pixel store operations. > > The first solution is simpler and easier to add, the second one would help with all scales that fall outside our loops. > The last solution would arguably provide the highest performance for any source/dest case that we care about (and with > the advent of HiDPI we now care about a lot more cases). > > I'd file 3 bugs: > > - Scaled and transformed drawImage can overshoot with some scales (1.5) > - Add more ScaledBlit graphics primitive instances for common HiDPI cases > - Create a general purpose Scale helper method along the lines of TransformHelper > > The first could be fixed soon with the proposed change you talk about below... > > ...jim > > On 10/28/16 6:40 AM, Alexandr Scherbatiy wrote: >> On 10/11/2016 10:13 PM, Sergey Bylokhov wrote: >>> On 11.10.16 21:54, Jim Graham wrote: >>>> Additionally, for AA rendering, there is no such thing as >>>> "setClip(someShape)" and "fill(sameShape)" being identical no matter how >>>> much we predict which rules they may want because clips are inherently >>>> non-AA and so the fuzzy pixels along the boundary of an AA shape will be >>>> randomly clipped or included. >>>> >>>> When all is said and done I feel (not very strongly) it would be best to >>>> have clipping remain unaffected by the biasing of STROKE hints, but part >>>> of that is driven by the fact that I think it can be fixed with a couple >>>> of lines of code in SG2D/LoopPipe... >>> >>> I guess a bottom line is that it is require an additional investigation. I am not exactly sure, but my expectation is >>> that fillRect(x,y,w,h)/drawImage(x,y,w,h) + setClip(x,y,w,h) should work in a similar way(covers the same pixels). And >>> the question should this behavior be exactly the same as fill(RectShape) + setClip(RectShape) is unclear (I am not >>> sure is it a critical issue or not) >>> Right now I tried to fix overlapping, which produce visible artifacts and were considered as a bugs. The next issue >>> which I would like to fix is a overlapping of drawImage(). >> I just created a small sample [1] which fills a rectangle (x, y, w, y), creates an image with size (w, h) and draws >> the image into the area (x, y, w, h). >> With the floating point scale like 1.5 the image does not exactly fits the area filled by the rectangle (see image [2] >> generated by the code [1]). >> >> This is because the Graphics.drawImage(...) calls DrawImage.renderImageXform() which uses floor and ceil methods for >> the region corner rounding: >> final int dx1 = Math.max((int) Math.floor(ddx1), clip.getLoX()); >> final int dy1 = Math.max((int) Math.floor(ddy1), clip.getLoY()); >> final int dx2 = Math.min((int) Math.ceil(ddx2), clip.getHiX()); >> final int dy2 = Math.min((int) Math.ceil(ddy2), clip.getHiY()); >> >> But the Graphics.fillRect() falls down to the code which just cast the transformed coordinates to int. >> >> Why the floor/ceil methods are used for the image region rounding? >> Is it possible to change this to fit the rule for the filled rectangles rounding? >> >> [1] http://cr.openjdk.java.net/~alexsch/fpapi/code/FillRectAndImageTest.java >> [2] http://cr.openjdk.java.net/~alexsch/fpapi/screenshots/rect-and-image.png >> >> Thanks, >> Alexandr. >>> >>> >>