From erik.joelsson at oracle.com Tue Nov 1 09:27:45 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Nov 2016 10:27:45 +0100 Subject: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory In-Reply-To: <01aa9716-c1a7-8690-765c-de8583ba1bd1@oracle.com> References: <75ed1c5e-a595-7251-59ae-e124c54de735@oracle.com> <2df1cd94-bcad-4629-bd86-513da156b875@oracle.com> <2d5c916f-fef2-5dfd-08ca-1b135ed9737c@oracle.com> <6cd646da-99a6-002c-c98a-f82a305046de@oracle.com> <6c0528b7-17c5-3b01-a82c-8dd546485801@oracle.com> <63082BA6-907F-42D3-B7B3-068EE7269125@oracle.com> <66b7f262-b523-d722-beef-25ea5e702737@oracle.com>

<0632C661-D179-4CE3-A49F-C1D5A4D562ED@oracle.com> <81c655fa-f668-c990-dd2d-ad1944681ac3@oracle.com> <7EA7214A-E72A-4D22-9A7D-3E144684B8C7@oracle.com> <5813BC1E.1030809@oracle.com> <01aa9716-c1a7-8690-765c-de8583ba1bd1@oracle.com> <342460f6-1faf-3891-0dbb-01b8c445525e@oracle.com> Message-ID: Mandy and Phil, I thought it would be helpful to add this to the comment in AccesssBridgeCalls.h: * * Also note that the API is used in the jaccessinspector and jaccesswalker tools. * The source for those tools is available in the OpenJDK repository at these links: * * http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp * http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp * http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.10/ I'll start the JPRT job today and then once I get your approval for that comment I will push this into 9. Pete On 11/1/16 4:27 AM, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2016-10-31 15:36, Pete Brunet wrote: >> >> On 10/28/16 8:14 PM, Mandy Chung wrote: >>>> On Oct 28, 2016, at 1:59 PM, Philip Race >>>> wrote: >>>> >>>> If it is not in the image then there is no point in the file existing. >>>> Maybe this could just be a comment at the top of the include file. >>>> >>> This works for me. >> Updated: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.09/ >>> Mandy >>> >>>> -phil. >>>> >>>> On 10/28/16, 12:42 PM, Mandy Chung wrote: >>>>>> On Oct 28, 2016, at 11:32 AM, Pete >>>>>> Brunet wrote: >>>>>> >>>>>> Hi Mandy, That simplifies things. The new patch is at: >>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.08/ >>>>> Looks better. >>>>> >>>>> I only notice now that the readme.html is in the include >>>>> directory. That should be in the documentation as you proposed >>>>> earlier. I don?t think it should be copied to the image. >>>>> >>>>> Mandy >>>>> > From Sergey.Bylokhov at oracle.com Tue Nov 1 15:01:20 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 1 Nov 2016 18:01:20 +0300 Subject: [9] Review Request for 8062525: JInternalFrame can't show correctly with the specical option "-esa -ea -Xcheck:jni -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". In-Reply-To: <60cf3936-ca7e-dbf3-b9c2-f23619b4d183@oracle.com> References: <55FFDE48.9000009@oracle.com> <55FFEB1A.1000500@oracle.com> <560400F8.4050505@oracle.com> <56040877.3070202@oracle.com> <56047B17.1050704@oracle.com> <60cf3936-ca7e-dbf3-b9c2-f23619b4d183@oracle.com> Message-ID: <44011a8f-826b-8bcd-b6c3-c96f942842d1@oracle.com> On 04.10.16 15:46, Semyon Sadetsky wrote: >> It is the similar, but the paintButtonBackground has no an assertion >> and simply returns if the titlePaneParent is not a JInternalFrame or >> JInternalFrame.JDesktopIcon, which means that you cannot simply cast >> the parent of the component to the JInternalFrame in the >> updateFrameGeometry. >> >> But paintFrameBorder for example has an assertion. I think it will be >> good to cleanup this methods a little bit. At lest this sequence of >> similar instanceof inside and outside updateFrameGeometry is strange. > The webrev is updated: > http://cr.openjdk.java.net/~ssadetsky/8062525/webrev.01/ Looks fine. >> >>>> >>>> On 9/21/2015 2:33 PM, Semyon Sadetsky wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8062525 >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8062525/webrev.00/ >>>>> >>>>> In the type check of the updateFrameGeometry() method the internal >>>>> frame >>>>> title buttons was not taken into account. >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Nov 1 19:37:30 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 1 Nov 2016 22:37:30 +0300 Subject: [9] Review request for 8074883: Tab key should move to focused button in a button group In-Reply-To: <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com> References: <28fd190a-c8dc-fb96-5010-22063186a7e3@oracle.com> <5a628ad3-edac-0b45-7c9e-840315e6d07f@oracle.com> <1aa50e8b-6ac3-9431-2bbc-fea5ec4754a8@oracle.com> <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com> Message-ID: On 28.10.16 11:20, Semyon Sadetsky wrote: >> probably it is possible to change the while loop to something? just to >> hide the usage of Enumeration? like >> Enumiration.asIterator().forEachRemaining()? > I did not get why. What is wrong with Enumeration? It is an old style iterator, and we can hide its usage. >> > If a component is disabled it cannot receive input focus, see > java.awt.Component#isEnabled specs. The proposed spec clearly states : > > 247 * If this toggle button is a member of the {@link ButtonGroup} > which has > 248 * an another ***focusable*** toggle button selected, and the > focus cause argument > >> It seems that the code in getGroupSelection() will focus the first >> element in the group, but what elements will be focused if we call >> Component#requestFocus(FocusEvent.Cause) directly for this disabled >> compoenent? Will the the same(first) element be selected? > I did find any mentions of "first element" in the proposed spec. Please > clarify this question. > According to the proposed spec the case when > Component#requestFocus(FocusEvent.Cause) is called on disabled component > will be handled as: > > 253 * In all other cases the result of the method is the same as > calling > 254 * {@link Component#requestFocus(FocusEvent.Cause)} on this > toggle button. The specification states that the call to this.requestFocus(FocusEvent.Cause cause); and the call to selected.requestFocus(FocusEvent.Cause cause); produce the same result "If this toggle button is a member of the {@link ButtonGroup} which has an another focusable toggle button selected, and the focus cause argument denotes window activation or focus traversal action of any direction" The question was "is that always true if the selected element is disabled(but focusable)"? I guess that the implementation in the fix will select the first "this"(the button on which requestFocus() was called), but in the second case something different will be selected. >>> On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote: >>>> On 10/19/2016 8:14 PM, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074883 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/ >>>>> >>>>> To avoid unexpected selection change the selected button of a button >>>>> group should always grab focus when focus is transferred form >>>>> component outside the group to any unselected button inside the group >>>>> in case of traversal or initial container activation actions. >>>> - It is better to pass the cause and boolean focusInWindow arguments >>>> to the getGroupSelection() method to avoid some code duplication like >>>> switching over the same cause values. >>>> - The fix will require a CCC request because it updates a javadoc >>>> for the publci method. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Nov 1 19:44:02 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 1 Nov 2016 22:44:02 +0300 Subject: [9] Review request for 8075918: The regression-swing case failed as the long Tab titles are not clipped with dots at the end with the special options"-client -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel" In-Reply-To: References: <23dd39ad-77aa-cc77-0eb0-3692ac41fbcb@oracle.com> <69259a64-edd2-0098-6a4b-3a5682b745b4@oracle.com> Message-ID: <3134cc26-3f5f-a2be-5a8b-d9a20dd8d59b@oracle.com> On 28.10.16 12:35, Semyon Sadetsky wrote: >> Probably this clipping should be done in the >> 633 paintText(ss, g, tabPlacement, font, metrics, >> 634 tabIndex, clippedTitle, textRect, isSelected); >> ? > It should be designed in the same way as in basic class. Currently the > BasicTabbedPaneUI#paintText() receives pre-clipped text to paint and the > clipping is executed in the paintTab(). >> It seems that currently this method contradicts its specification and >> skips the w/h of the passed bounds(in this case "textRect"). > I don't see any mentions of text clipping in this spec. SynthGraphicsUtils.java * @param bounds Bounds of the text to be drawn. * @param mnemonicIndex Index to draw string at. */ public void paintText(SynthContext ss, Graphics g, String text, Rectangle bounds, int mnemonicIndex) { .... The textRect variable which is calculated in the changed method and passed to paintText() is "Bounds of the text to be drawn". The method violates its specification and ignores w/h of these bounds. So the text is painted outside of the Tab. >> >> On 21.10.16 15:12, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8075918 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8075918/webrev.00/ >>> >>> Title text clipping capability is added to the Synth L&F's tabbed pane >>> UI to fix the issue. >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Nov 1 19:57:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 1 Nov 2016 22:57:43 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: <0c1cae06-af72-4160-f82d-413fcbabefd2@oracle.com> References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <6f7d5215-c66c-879b-8c8e-6fbe9ca2c511@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com>

<8f8372e2-7140-08f5-80d7-e9ea74e970aa@oracle.com> <5c967c6b-50e4-4079-fd9e-2f86628d5bb1@oracle.com> <2a533678-d570-4e45-fa5b-71a1b6ad01fd@oracle.com> <4033f4b2-63ce-e2d5-6749-bfc02868f47a@oracle.com> <749a5127-1c83-75d5-f39e-0a9076a456e6@oracle.com> <2149edd0-85a2-5695-2503-6508b2d6d57c@oracle.com> <0c1cae06-af72-4160-f82d-413fcbabefd2@oracle.com> Message-ID: On 05.10.16 10:35, Semyon Sadetsky wrote: >> Can you clarify, what does it mean "wrong", this why we cannot use it >> or what? If it is wrong then we can fix it, if it is correct why we >> cannot use it? It should be the same as getNativeScale(), because it >> is based on getNativeScale(), but unlike getNativeScale it is a public >> API which is unrelated to X11. > getNativeScale() returns the correct scale only on supported > desktops/WMs. Currently they are gnome3 and Unity. My change doesn't > affect other Linux distributions. What you are suggesting will change > behavior on unsupported distributions. I don't see the reason to do this. I do not understand this the GraphicsConfiguration.getDefaultTransform() is also uses getNativeScale() internally. >> >>>> >>>> ======= >>>>>> since only in jdk9 on HiDPI screens default scale can have some >>>>>> transform. The difference from the current solution is that the >>>>>> shared >>>>>> code will used the public/shared java2d api, instead of platform >>>>>> specific. >>>>>> >>>>>>>>>>> - Take debug scale into account if it was set and skip all >>>>>>>>>>> others. >>>>>>>>>>> - Check J2D_UISCALE >>>>>>>>>>> - Check scale-factor, text-scale-factor, text-scaling-factor. >>>>>>>>>>> - Check Xft.dpi. >>>>>>>>>>> - If non of them was set then scale=1 should be used. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From james.graham at oracle.com Tue Nov 1 20:23:46 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 1 Nov 2016 13:23:46 -0700 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> Message-ID: <333189c9-10b1-2018-f53b-83cffaf2e481@oracle.com> Is SunGraphics2D accessible from Swing? If so, then I'd recommend putting the isFPScale() method right on that class so we don't have to clone the transform by calling g.getTransform(). Also note that g.getTransform() does more than clone the transform as it has to factor out the constrainXY translation - which are always integers so it won't have any effect on the results of "isFPScale()" and is additional wasted work. Eventually we could tie this into the transformState variable in SG2D to differentiate integer and fp scale, but that would take a little more work as those flags are used in a lot of places - for now we can at least get rid of the transform clone and the constraint translation processing. In the implementation of isFPScale(tx), do you really want to return false for non-scale transforms? It seems to me that if the transform has rotations or shears in it then we might need to punt and just repaint the whole viewport. Also, you could simplify it a little to avoid an extra "getter" and extra bit math: isFPScale(AffineTransform tx) { int type = tx.getType() & ~(FLIP | TRANSLATE); if (type == 0) { return false; } else if (type == SCALE) { // check for integers } else { return true or false?; } } The changes to SG2D.drawHiDPIImage point out that we should probably allow fp subimage paramters in the image pipeline for better accuracy, but that's a much bigger change. Until then sub-image blits are not going to be accurate on scaled images. Won't this inaccuracy affect our back buffer blits in Swing? The changes to RepaintManager took me a couple of tries to figure out. It looks like you are now rendering the dirty region at the appropriate X,Y location in the back buffer (rather than at 0,0) in all cases to adjust for the fact that rendering the same primitive at different locations doesn't always match. First, you expand the back buffer even for the unscaled case which wasn't affected by HiDPI. Second, as long as the translate is in device pixels, it shouldn't matter where in the buffer you render it, so it should be enough to just ensure integer translations - did you try using an integer origin for the rendering instead? ...jim On 10/24/2016 9:11 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8162350/webrev.01 > - JScrollPane copy area functionality is disabled for floating point scale > - VolatileImage buffer size is recalculates using transform translate > > Using floating point scale leads that drawing the same thing from > different coordinates gives different results. For example filling a > rectangle with size (1, 1) from location (0, 0) and UI scale 1.5 gives > scaled region (0, 0, 1.5, 1.5) which is rounded to (0, 0, 2, 2). The > same rectangle filled from the location (1, 1) gives the scaled region > (1.5, 1.5, 3, 3) which is rounded to (2, 2, 3, 3). The first rectangle > has size 2 in the device space and the second one has 1. > As a result drawing a component from some coordinates and using > Graphics.copyArea() to translate an image to a new location could have a > differ results than just drawing the same component from the new location. > The fix suggests to disable the JScrollPane area copying for floating > point scales. > > Thanks, > Alexandr. > > On 10/7/2016 4:30 PM, Alexandr Scherbatiy wrote: >> On 10/6/2016 11:42 PM, Sergey Bylokhov wrote: >>> Hi, Alexandr. >>> Can you please provide some standalone small example, which emulates >>> this artifacts via java2d API. (The pattern which we use in >>> RepainManager). It will help to understand the problem. >> >> The code sample [1] draws two the same shapes (with different colors) >> one after another into areas (x, y, w, h) and (x+w, y, w, h) >> accordingly in different ways. >> >> The shape is constructed from the following parts: >> 1. Fill clip area >> - set clip (x, y, w, h) >> - fill the whole image >> As a result only clipped area is filled. >> >> 2. Fill rect >> - fill rect(x, y, w, h) // big rect >> - fill rect(x+1, y+1, w-2, h-2) // small rect >> >> 3. Draw center lines >> - draw line (x, cy, x + w, cy) >> - draw line (cx, y, cx, y + h) >> >> The program has the following options: >> RECT - draw two shapes one after another from point (0, 0) >> SHIFTED_RECT - draw two shapes one after another from point (x, y) >> BACKBUFFER - draw the shape into a backbuffer with size (w, h) and >> draw the backbuffer from the point (x, y) >> SCALED_BACKBUFFER - draw the shape into a scaled backbuffer with >> size (ceil(w*scale), ceil(h*scale)) with scaled graphics from point >> (0, 0) and draw it into the rectangle (x, y, w, h) >> ENLARGED_SCALED_BACKBUFFER - draw the shape into a scaled backbuffer >> with size (ceil((x+w)*scale), ceil((y+h)*scale)) with scaled graphics >> from point (x, y) and draw it into the rectangle (0, 0, x+w, y+h) >> >> The resulted images are placed in the directory [2]. >> Directory name "rect-[7,5,10,8]" means that the rectangles (7,5,10,8) >> was used for the shape drawing. >> Each screenshot name follows the template " >> screenshot-N-[x,y,w,h]-TYPE.png" where the type is a program option >> used for the image generation. >> Screenshots with suffix "-compare" compares the golden image (shape >> drawn in to the rectangle (x, y, w, h)) with the generated image. The >> golden image is on the top left side. The generated image is shown on >> the right and bottom side. >> >> The RepaintManager has an assumption that drawing something in some >> area (x, y, w, h) or just drawing the same thing into an image with >> translated graphics g.translate(-x1, -y1) and drawing the image into >> the area(x, y, w, h) has the the same result. >> >> As it is shown on screenshots this statement is not true for floating >> point scales. >> For example the same shape drawn from the point (0,0) and (x,y) look >> differently (see [3] and [4]). >> >> The solution could be just to use an enlarged backbuffer with size >> (x+w, y+h) with scaled graphics, draw the component into the rectangle >> (x, y, w, h) and draw the backbuffer into the area (0,0, x+w, y+h). >> Even the scaled enlarged backbuffer is used the results can be differ >> (see [5] where the rectangle [7, 5, 11, 9] is used. The backbuffer is >> drawn into bigger size). >> >> >> [1] code samples: >> http://cr.openjdk.java.net/~alexsch/8162350/code/00/Java2DFPSamples.java >> [2] dir with screenshots results: >> http://cr.openjdk.java.net/~alexsch/8162350/results >> [3] RECT: >> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-01-%5b7%2c5%2c10%2c8%5d-rects.png >> [4] SHIFTED_RECT: >> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-02-%5b7%2c5%2c10%2c8%5d-shifted-rects.png >> [5] ENLARGED_SCALED_BACKBUFFER compare: >> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c11%2c9%5d/screenshot-05-%5b7%2c5%2c11%2c9%5d-enlarged-scaled-backbuffers-compare.png >> >> Thanks, >> Alexandr. >> >>> >>> On 06.10.16 20:07, Alexandr Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8162350 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8162350/webrev.00 >>>> >>>> The fix uses the solution suggest by Jim in the email: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007737.html >>>> >>>> To draw to a VolatileImage backbuffer its graphics transform is >>>> set to >>>> identity and device coordinates are used to set the buffer clip. >>>> Copying the backbuffer image to the graphics has some problems. >>>> ------------- >>>> // Since there is no drawImage(img, float x, float y)... >>>> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >>>> destination.drawImage(img, 0, 0) >>>> ------------- >>>> This code solves the problem for the top left corner of the region. >>>> All Graphics.drawImage(...) methods scales the image size and it looks >>>> like ceil(img.getWidth() * scaleX) can be differ from the >>>> ceil(pixelx1 + >>>> img.getWidth() * scaleX) - pixelx1 so the right bottom corner of the >>>> image does not fit the required point. >>>> There is also a question could a line drawn from one point and then >>>> from another has a different width in pixels because the graphics scale >>>> is not integer. >>>> >>>> The proposed fix prepares a backbuffer with size [x + w, y + h] in a >>>> user space and a component is drawn in to the region [pixelx1, pixely1, >>>> pixely2, pixely2] in the device space. >>>> After that the necessary clip is set to the graphics and whole image >>>> is just drawn into it. >>>> >>>> The new logic is used only the component graphics configuration is >>>> scaled the graphics configuration has the same scales. So it possible >>>> just to copy the backbuffer surface data to the graphics surface data. >>>> For other cases like for rotated graphics transform it seems it is >>>> necessary to have more complicated algorithm. >>>> >>>> This solves problems with repainted region but there are still >>>> artifacts with JInternalFrame moving or a component scrolling, This can >>>> be related to the RepaintManager.copyArea() method which needs to be >>>> updated in the similar way. I have created an issue on it: >>>> JDK-8167305 RepaintManager.copyArea() method should be updated for >>>> floating point UI scale >>>> https://bugs.openjdk.java.net/browse/JDK-8167305 >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > From peter.brunet at oracle.com Tue Nov 1 23:21:29 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 1 Nov 2016 18:21:29 -0500 Subject: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory In-Reply-To: References: <75ed1c5e-a595-7251-59ae-e124c54de735@oracle.com> <2df1cd94-bcad-4629-bd86-513da156b875@oracle.com> <2d5c916f-fef2-5dfd-08ca-1b135ed9737c@oracle.com> <6cd646da-99a6-002c-c98a-f82a305046de@oracle.com> <6c0528b7-17c5-3b01-a82c-8dd546485801@oracle.com> <63082BA6-907F-42D3-B7B3-068EE7269125@oracle.com> <66b7f262-b523-d722-beef-25ea5e702737@oracle.com>

<2f3a052c-05ad-209e-c5ba-ee02c7773a01@oracle.com> <298a7c04-be76-f543-54bd-cc8b67e5eaf3@oracle.com> <51f22ea9-e4e5-65de-7833-67ab084ebbb7@oracle.com> <119d56da-a62b-d527-14fa-52905c51dc84@oracle.com> Message-ID: <0339876e-f24b-2264-c44b-d10fbea93f0a@oracle.com> On 10/28/2016 10:47 PM, Sergey Bylokhov wrote: > On 28.10.16 12:56, Semyon Sadetsky wrote: >>> If we unsure what information will be contained in the message is it >>> necessary to provide it to the user? Or it will be enough to describe >>> the problem in general? For example this message should not contain >>> something like this: >>> "The library/module c:/windows/system32/shell.dll cannot be loaded", >>> if the user have no permission to read the file system. >> The path is not printed because there always several paths to look for >> the system module. >> But I did not get how filesystem read permission is related to the >> console output. > > This is not a console output this is an exception which can be handled. Really? How? > Filesystem access can be blocked by Securitymanager, access to the > system properties can be blocked as well. So we should not expose > these data via any other ways, like via the messages from the native > errors. > > Some useful link: > http://www.oracle.com/technetwork/java/seccodeguide-139067.html#2 > From semyon.sadetsky at oracle.com Wed Nov 2 06:58:21 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 2 Nov 2016 09:58:21 +0300 Subject: [9] Review request for 8168992 Add floating point implementation for new BasicGraphicsUtils text related methods use floating point API In-Reply-To: <59bb78f6-06c4-f68a-d8e8-ac2d0787a916@oracle.com> References: <72d1c22e-f7d1-1c10-34c6-3c7c7bd67010@oracle.com> <59bb78f6-06c4-f68a-d8e8-ac2d0787a916@oracle.com> Message-ID: +1 --Semyon On 11/1/2016 5:13 PM, Sergey Bylokhov wrote: > Looks fine. > > On 01.11.16 16:47, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8168992 >> webrev: http://cr.openjdk.java.net/~alexsch/8168992/webrev.00 >> >> The fix JDK-8132119 added stubs for the following methods: >> BasicGraphicsUtils.drawString(JComponent c, Graphics2D g, String >> string, float x, float y) >> BasicGraphicsUtils.drawStringUnderlineCharAt(JComponent c, Graphics2D >> g, String string, int underlinedIndex, float x, float y) >> BasicGraphicsUtils.getStringWidth(JComponent c, FontMetrics fm, String >> string) >> >> The current fix adds implementation which uses floating point API for >> these methods. >> >> The fix also updated the implementation to use floating point API for >> the method: >> Utilities.drawTabbedText(Segment s, float x, float y, Graphics2D g, >> TabExpander e, int startOffset) >> >> Thanks, >> Alexandr. >> > > From semyon.sadetsky at oracle.com Wed Nov 2 07:48:53 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 2 Nov 2016 10:48:53 +0300 Subject: [9] Review request for 8075918: The regression-swing case failed as the long Tab titles are not clipped with dots at the end with the special options"-client -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel" In-Reply-To: <3134cc26-3f5f-a2be-5a8b-d9a20dd8d59b@oracle.com> References: <23dd39ad-77aa-cc77-0eb0-3692ac41fbcb@oracle.com> <69259a64-edd2-0098-6a4b-3a5682b745b4@oracle.com> <3134cc26-3f5f-a2be-5a8b-d9a20dd8d59b@oracle.com> Message-ID: On 11/1/2016 10:44 PM, Sergey Bylokhov wrote: > On 28.10.16 12:35, Semyon Sadetsky wrote: >>> Probably this clipping should be done in the >>> 633 paintText(ss, g, tabPlacement, font, metrics, >>> 634 tabIndex, clippedTitle, textRect, isSelected); >>> ? >> It should be designed in the same way as in basic class. Currently the >> BasicTabbedPaneUI#paintText() receives pre-clipped text to paint and the >> clipping is executed in the paintTab(). >>> It seems that currently this method contradicts its specification and >>> skips the w/h of the passed bounds(in this case "textRect"). >> I don't see any mentions of text clipping in this spec. > > SynthGraphicsUtils.java > * @param bounds Bounds of the text to be drawn. > * @param mnemonicIndex Index to draw string at. > */ > public void paintText(SynthContext ss, Graphics g, String text, > Rectangle bounds, int mnemonicIndex) { > .... > > The textRect variable which is calculated in the changed method and > passed to paintText() is "Bounds of the text to be drawn". The method > violates its specification and ignores w/h of these bounds. So the > text is painted outside of the Tab. Anyway it doesn't say do clip. Adding clipping to this method would be a mistake because in this case the text may be clipped twice. > >>> >>> On 21.10.16 15:12, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075918 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8075918/webrev.00/ >>>> >>>> Title text clipping capability is added to the Synth L&F's tabbed pane >>>> UI to fix the issue. >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Wed Nov 2 07:51:49 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 2 Nov 2016 10:51:49 +0300 Subject: [9] Review request for 8074883: Tab key should move to focused button in a button group In-Reply-To: References: <28fd190a-c8dc-fb96-5010-22063186a7e3@oracle.com> <5a628ad3-edac-0b45-7c9e-840315e6d07f@oracle.com> <1aa50e8b-6ac3-9431-2bbc-fea5ec4754a8@oracle.com> <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com> Message-ID: On 11/1/2016 10:37 PM, Sergey Bylokhov wrote: > On 28.10.16 11:20, Semyon Sadetsky wrote: >>> probably it is possible to change the while loop to something? just to >>> hide the usage of Enumeration? like >>> Enumiration.asIterator().forEachRemaining()? >> I did not get why. What is wrong with Enumeration? > > It is an old style iterator, and we can hide its usage. Okay. http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.02/ > >>> >> If a component is disabled it cannot receive input focus, see >> java.awt.Component#isEnabled specs. The proposed spec clearly states : >> >> 247 * If this toggle button is a member of the {@link ButtonGroup} >> which has >> 248 * an another ***focusable*** toggle button selected, and the >> focus cause argument >> >>> It seems that the code in getGroupSelection() will focus the first >>> element in the group, but what elements will be focused if we call >>> Component#requestFocus(FocusEvent.Cause) directly for this disabled >>> compoenent? Will the the same(first) element be selected? >> I did find any mentions of "first element" in the proposed spec. Please >> clarify this question. >> According to the proposed spec the case when >> Component#requestFocus(FocusEvent.Cause) is called on disabled component >> will be handled as: >> >> 253 * In all other cases the result of the method is the same as >> calling >> 254 * {@link Component#requestFocus(FocusEvent.Cause)} on this >> toggle button. > > The specification states that the call to > this.requestFocus(FocusEvent.Cause cause); > and the call to > selected.requestFocus(FocusEvent.Cause cause); > produce the same result "If this toggle button is a member of the > {@link ButtonGroup} which has an another focusable toggle button > selected, and the focus cause argument denotes window activation or > focus traversal action of any direction" > > The question was "is that always true if the selected element is > disabled(but focusable)"? I guess that the implementation in the fix > will select the first "this"(the button on which requestFocus() was > called), but in the second case something different will be selected. > >>>> On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote: >>>>> On 10/19/2016 8:14 PM, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074883 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/ >>>>>> >>>>>> To avoid unexpected selection change the selected button of a button >>>>>> group should always grab focus when focus is transferred form >>>>>> component outside the group to any unselected button inside the >>>>>> group >>>>>> in case of traversal or initial container activation actions. >>>>> - It is better to pass the cause and boolean focusInWindow >>>>> arguments >>>>> to the getGroupSelection() method to avoid some code duplication like >>>>> switching over the same cause values. >>>>> - The fix will require a CCC request because it updates a javadoc >>>>> for the publci method. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>> >>>>> >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Wed Nov 2 07:59:34 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 2 Nov 2016 10:59:34 +0300 Subject: [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled In-Reply-To: References: <280a5d75-0c8a-345c-08cd-44e13cf56fee@oracle.com> <42cdd713-c4e5-e407-9d43-5ced49f611ad@oracle.com> <06e261d1-4a7d-3016-5f22-531e909097f7@oracle.com> <94897cb8-f94e-c573-cde3-8e1b95da73f6@oracle.com>

<8f8372e2-7140-08f5-80d7-e9ea74e970aa@oracle.com> <5c967c6b-50e4-4079-fd9e-2f86628d5bb1@oracle.com> <2a533678-d570-4e45-fa5b-71a1b6ad01fd@oracle.com> <4033f4b2-63ce-e2d5-6749-bfc02868f47a@oracle.com> <749a5127-1c83-75d5-f39e-0a9076a456e6@oracle.com> <2149edd0-85a2-5695-2503-6508b2d6d57c@oracle.com> <0c1cae06-af72-4160-f82d-413fcbabefd2@oracle.com> Message-ID: <51d624d2-99c0-0e52-aefd-ab89fc4ff330@oracle.com> On 11/1/2016 10:57 PM, Sergey Bylokhov wrote: > On 05.10.16 10:35, Semyon Sadetsky wrote: >>> Can you clarify, what does it mean "wrong", this why we cannot use it >>> or what? If it is wrong then we can fix it, if it is correct why we >>> cannot use it? It should be the same as getNativeScale(), because it >>> is based on getNativeScale(), but unlike getNativeScale it is a public >>> API which is unrelated to X11. >> getNativeScale() returns the correct scale only on supported >> desktops/WMs. Currently they are gnome3 and Unity. My change doesn't >> affect other Linux distributions. What you are suggesting will change >> behavior on unsupported distributions. I don't see the reason to do >> this. > > I do not understand this the > GraphicsConfiguration.getDefaultTransform() is also uses > getNativeScale() internally. It returns 1 for unsupported desktops, so everything remains the same for them. The bug is reported for hi-dpi case. > >>> >>>>> >>>>> ======= >>>>>>> since only in jdk9 on HiDPI screens default scale can have some >>>>>>> transform. The difference from the current solution is that the >>>>>>> shared >>>>>>> code will used the public/shared java2d api, instead of platform >>>>>>> specific. >>>>>>> >>>>>>>>>>>> - Take debug scale into account if it was set and skip all >>>>>>>>>>>> others. >>>>>>>>>>>> - Check J2D_UISCALE >>>>>>>>>>>> - Check scale-factor, text-scale-factor, text-scaling-factor. >>>>>>>>>>>> - Check Xft.dpi. >>>>>>>>>>>> - If non of them was set then scale=1 should be used. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Wed Nov 2 16:23:30 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 2 Nov 2016 19:23:30 +0300 Subject: [9] Review request for 8139394: more detailed message for "Could not initialize shell library" In-Reply-To: <0339876e-f24b-2264-c44b-d10fbea93f0a@oracle.com> References: <856c8307-1075-e6de-aae5-47c3cc0f3657@oracle.com> <19214b69-76a8-808b-6c3e-90ca005eac49@oracle.com>

<50687e80-f79e-4af4-b374-f1419aa575ee@oracle.com>

<55BBB3BD-2673-45F1-9DF3-950DE40DC43B@oracle.com> <188090ae-deb1-e117-ed57-9ae13aa1043d@oracle.com> <435c659c-cb24-8d49-41ba-c5e15068957f@oracle.com> <12b0de58-486b-5f0b-0bf5-9d2ea39d4d24@oracle.com> <9e118bd1-946d-d4dd-f328-fa975a78c6e4@oracle.com> Message-ID: <72576b6d-505e-ed54-2d4c-382950374db9@oracle.com> The fix looks good to me. Thanks, Alexandr. On 10/31/2016 9:31 PM, Jim Graham wrote: > Looks good. +1 > > ...jim > > On 10/30/16 11:53 PM, Avik Niyogi wrote: >> Hi All, >> Please review the proposed specification for JDK9 including inputs >> from reviewer reviews. >> *cr.openjdk.java.net/~aniyogi/8138771/webrev.05/* >> >> Thank you in advance. >> >> With Regards, >> Avik Niyogi >>> On 28-Oct-2016, at 1:18 am, Jim Graham >> > wrote: >>> >>> Hi Avik, >>> >>> My suggestion about adding a word "the" was not taken and a couple >>> of other changes were made to the @return >>> statements which are not optimal. Let's reset and use the following >>> @return statements for each of the methods (to >>> mirror the way these are described in the Image base class): >>> >>> getWidth() - @return the width of the base image, or -1 if the width >>> is not yet known >>> getHeight() - @return the height of the base image, or -1 if the >>> height is not yet known >>> getGraphics() - @return throws {@code UnsupportedOperationException} >>> getSource() - @return the image producer that produces the pixels >>> for the base image >>> getProperty() - @return the value of the named property in the base >>> image >>> >>> (It would also be nice if the blank lines were the same in all of >>> the doc comments. Some comments have a couple of >>> blank lines to separate the javadoc sections and others have no >>> blank lines. But, that doesn't affect correctness, it >>> is just an easthetic issue...) >>> >>> ...jim >>> >>> On 10/26/16 11:51 PM, Avik Niyogi wrote: >>>> Hi All, >>>> >>>> Please review the proposed specification for JDK9 including inputs >>>> from reviewer reviews. >>>> *http://cr.openjdk.java.net/~aniyogi/8138771/webrev.04/* >>>> Thank you in advance. >>>> >>>> With Regards, >>>> Avik Niyogi >>>> >>>>> On 27-Oct-2016, at 2:33 am, Jim Graham >>>> >>>>> > wrote: >>>>> >>>>> The "@return" tags should not start with "returns" in the text. >>>>> >>>>> Also, in the @return for getProperty(), insert a word "the" as >>>>> "the property of the base image"... >>>>> >>>>> ...jim >>>>> >>>>> On 10/26/16 12:36 AM, Avik Niyogi wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review the proposed specification for JDK9 including >>>>>> inputs from reviver reviews. >>>>>> >>>>>> *cr.openjdk.java.net/~aniyogi/8138771/webrev.03/* >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thank you in advance. >>>>>> >>>>>> With Regards, >>>>>> Avik Niyogi >>>> >> From alexandr.scherbatiy at oracle.com Thu Nov 3 12:19:12 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 3 Nov 2016 15:19:12 +0300 Subject: [9] RFR JDK-8048702: Deprecate obsolete classes in javax/swing/plaf/metal/MetalFileChooserUI.java In-Reply-To: <118c8ff6-8fd8-4eba-0341-72facedf1811@oracle.com> References: <74729ca9-460f-5353-7362-abb0c4fa0d4c@oracle.com> <67732ff4-573a-81c6-23fb-a99121c42787@oracle.com>

<118c8ff6-8fd8-4eba-0341-72facedf1811@oracle.com> Message-ID: <4c41f056-f5d0-14e6-6c3d-a6e9e4f56ddb@oracle.com> The fix looks good to me. Thanks, Alexandr. On 10/31/2016 3:03 PM, Sergey Bylokhov wrote: > +1 > Thanks. > > On 31.10.16 8:10, Prasanta Sadhukhan wrote: >> Ok. Added javadoc tag. >> >> http://cr.openjdk.java.net/~psadhukhan/8048702/webrev.01/ >> >> Regards >> Prasanta >> On 10/29/2016 1:05 AM, Sergey Bylokhov wrote: >>> It seems that most of our deprecated api have an annotation and a >>> javadoc tag. I guess we should add javadoc tag here as well. >>> >>> On 28.10.16 14:04, Alexandr Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 10/28/2016 7:19 AM, Prasanta Sadhukhan wrote: >>>>> Please find the webrev with the proposed changes. >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8048702/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 10/27/2016 8:03 PM, Alexandr Scherbatiy wrote: >>>>>> On 10/26/2016 10:28 AM, Prasanta Sadhukhan wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review a fix for the issue where this obsolete class >>>>>>> needs to >>>>>>> be deprecated: >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048702 >>>>>>> >>>>>>> diff -r aae3690e53e3 >>>>>>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> a/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java >>>>>>> >>>>>>> >>>>>>> Thu Oct 20 14:21:46 2016 +0300 >>>>>>> +++ >>>>>>> b/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java >>>>>>> >>>>>>> >>>>>>> Wed Oct 26 12:56:48 2016 +0530 >>>>>>> @@ -570,8 +570,9 @@ >>>>>>> } >>>>>>> >>>>>>> /** >>>>>>> - * Obsolete class, not used in this version. >>>>>>> + * Obsolete class, not used in this version. deprecated as of >>>>>>> JDK version 9. >>>>>> - The deprecated word should start with the capital letter after >>>>>> the full stop. >>>>>>> */ >>>>>>> + @Deprecated >>>>>> - since="1.9" can be added. >>>>>> - Could you provide the webrev for the fix? >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> protected class SingleClickListener extends MouseAdapter { >>>>>>> /** >>>>>>> * Constructs an instance of {@code SingleClickListener}. >>>>>>> @@ -583,8 +584,9 @@ >>>>>>> } >>>>>>> >>>>>>> /** >>>>>>> - * Obsolete class, not used in this version. >>>>>>> + * Obsolete class, not used in this version. deprecated as of >>>>>>> JDK version 9. >>>>>>> */ >>>>>>> + @Deprecated >>>>>>> @SuppressWarnings("serial") // Superclass is not serializable >>>>>>> across versions >>>>>>> protected class FileRenderer extends DefaultListCellRenderer { >>>>>>> } >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>> >>>> >>> >>> >> > > From sergey.bylokhov at oracle.com Thu Nov 3 13:35:51 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 3 Nov 2016 06:35:51 -0700 (PDT) Subject: [9] Review request for 8139394: more detailed message for "Could not initialize shell library" Message-ID: ----- semyon.sadetsky at oracle.com wrote: > On 02.11.2016 19:23, Sergey Bylokhov wrote: > > > On 02.11.16 9:43, Semyon Sadetsky wrote: > >>>> The path is not printed because there always several paths to > look for > >>>> the system module. > >>>> But I did not get how filesystem read permission is related to > the > >>>> console output. > >>> > >>> This is not a console output this is an exception which can be > handled. > >> Really? > >> How? > > > > This is a question how to catch an exception which we throw in the > > Java_sun_awt_shell_Win32ShellFolder2_initIDs, or what? > You are right it is possible. I already wrote the path is not shown. > What is your concern? My concern: is it necessary to use lastError message or not, since the message can varies. For example the message below does not explain the problem correctly: "java.lang.InternalError: Could not initialize shell library . ?? ??????? ????????? ?????????" I guess we can provide the same message ourself, From alok.sharma at hpe.com Fri Nov 4 04:52:22 2016 From: alok.sharma at hpe.com (Sharma, Alok Kumar (OSTL)) Date: Fri, 4 Nov 2016 04:52:22 +0000 Subject: Back port of fix JDK-7067885: FileChooser does not display soft link name if link is to nonexistent file/directory to OpenJDK-8 Message-ID: Hi, JDK-7067885 fix is applicable to OpenJDK-8, Code changes and testing for OpenJDK-8 are done. Mercurial diff for updated source change: ----------------------------------------------------------------------------------------------------------------------- diff -r 687fd7c7986d src/share/classes/sun/awt/shell/ShellFolder.java --- a/src/share/classes/sun/awt/shell/ShellFolder.java Tue Mar 04 11:51:53 2014 -0800 +++ b/src/share/classes/sun/awt/shell/ShellFolder.java Wed Nov 02 11:15:16 2016 +0530 @@ -30,6 +30,10 @@ import java.awt.Toolkit; import java.io.*; import java.io.FileNotFoundException; +import java.nio.file.Files; +import java.nio.file.LinkOption; +import java.nio.file.Path; +import java.nio.file.Paths; import java.util.*; import java.util.concurrent.Callable; @@ -236,10 +240,11 @@ * @exception FileNotFoundException if file does not exist */ public static ShellFolder getShellFolder(File file) throws FileNotFoundException { + Path path = Paths.get(file.getPath()); if (file instanceof ShellFolder) { return (ShellFolder)file; } - if (!file.exists()) { + if (!Files.exists(path, LinkOption.NOFOLLOW_LINKS)) { throw new FileNotFoundException(); } return shellFolderManager.createShellFolder(file); ----------------------------------------------------------------------------------------------------------------------- Regards, Alok -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Nov 4 06:58:27 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 4 Nov 2016 09:58:27 +0300 Subject: Back port of fix JDK-7067885: FileChooser does not display soft link name if link is to nonexistent file/directory to OpenJDK-8 In-Reply-To: References: Message-ID: <24f64daf-26d4-5f46-19b6-136ef3b77d1b@oracle.com> Alok, JDK-7067885 fix caused regression and was reverted. Consider to backport JDK-8168899. --Semyon On 04.11.2016 07:52, Sharma, Alok Kumar (OSTL) wrote: > > Hi, > > JDK-7067885 fix is > applicable to OpenJDK-8, Code changes and testing for OpenJDK-8 are done. > > Mercurial diff for updated source change: > > ----------------------------------------------------------------------------------------------------------------------- > > > diff -r 687fd7c7986d src/share/classes/sun/awt/shell/ShellFolder.java > > --- a/src/share/classes/sun/awt/shell/ShellFolder.java Tue Mar 04 > 11:51:53 2014 -0800 > > +++ b/src/share/classes/sun/awt/shell/ShellFolder.java Wed Nov 02 > 11:15:16 2016 +0530 > > @@ -30,6 +30,10 @@ > > import java.awt.Toolkit; > > import java.io.*; > > import java.io.FileNotFoundException; > > +import java.nio.file.Files; > > +import java.nio.file.LinkOption; > > +import java.nio.file.Path; > > +import java.nio.file.Paths; > > import java.util.*; > > import java.util.concurrent.Callable; > > @@ -236,10 +240,11 @@ > > * @exception FileNotFoundException if file does not exist > > */ > > public static ShellFolder getShellFolder(File file) throws > FileNotFoundException { > > + Path path = Paths.get(file.getPath()); > > if (file instanceof ShellFolder) { > > return (ShellFolder)file; > > } > > - if (!file.exists()) { > > + if (!Files.exists(path, LinkOption.NOFOLLOW_LINKS)) { > > throw new FileNotFoundException(); > > } > > return shellFolderManager.createShellFolder(file); > > ----------------------------------------------------------------------------------------------------------------------- > > > Regards, > > Alok > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Nov 4 14:42:51 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 04 Nov 2016 07:42:51 -0700 Subject: Back port of fix JDK-7067885: FileChooser does not display soft link name if link is to nonexistent file/directory to OpenJDK-8 In-Reply-To: <24f64daf-26d4-5f46-19b6-136ef3b77d1b@oracle.com> References: <24f64daf-26d4-5f46-19b6-136ef3b77d1b@oracle.com> Message-ID: <581C9E6B.9000303@oracle.com> And this is a reminder to run applicable tests before pushing. Also given the first fix causing a regression and that this is a long-standing issue I don't see why we need to "rush" to backport even this 2nd fix. I'd like to see proper bake time in JDK 9 first. -phil. On 11/3/16, 11:58 PM, Semyon Sadetsky wrote: > > Alok, > > JDK-7067885 fix > caused regression and was reverted. Consider to backport JDK-8168899. > > --Semyon > > > On 04.11.2016 07:52, Sharma, Alok Kumar (OSTL) wrote: >> >> Hi, >> >> JDK-7067885 fix is >> applicable to OpenJDK-8, Code changes and testing for OpenJDK-8 are done. >> >> Mercurial diff for updated source change: >> >> ----------------------------------------------------------------------------------------------------------------------- >> >> >> diff -r 687fd7c7986d src/share/classes/sun/awt/shell/ShellFolder.java >> >> --- a/src/share/classes/sun/awt/shell/ShellFolder.java Tue Mar 04 >> 11:51:53 2014 -0800 >> >> +++ b/src/share/classes/sun/awt/shell/ShellFolder.java Wed Nov 02 >> 11:15:16 2016 +0530 >> >> @@ -30,6 +30,10 @@ >> >> import java.awt.Toolkit; >> >> import java.io.*; >> >> import java.io.FileNotFoundException; >> >> +import java.nio.file.Files; >> >> +import java.nio.file.LinkOption; >> >> +import java.nio.file.Path; >> >> +import java.nio.file.Paths; >> >> import java.util.*; >> >> import java.util.concurrent.Callable; >> >> @@ -236,10 +240,11 @@ >> >> * @exception FileNotFoundException if file does not exist >> >> */ >> >> public static ShellFolder getShellFolder(File file) throws >> FileNotFoundException { >> >> + Path path = Paths.get(file.getPath()); >> >> if (file instanceof ShellFolder) { >> >> return (ShellFolder)file; >> >> } >> >> - if (!file.exists()) { >> >> + if (!Files.exists(path, LinkOption.NOFOLLOW_LINKS)) { >> >> throw new FileNotFoundException(); >> >> } >> >> return shellFolderManager.createShellFolder(file); >> >> ----------------------------------------------------------------------------------------------------------------------- >> >> >> Regards, >> >> Alok >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Nov 4 23:00:09 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 4 Nov 2016 16:00:09 -0700 Subject: RFR:8168316: Suppress deprecation warnings for Applet classes in java.desktop In-Reply-To: <510b4057-8e7c-0ece-5e98-c7fa2ce3d8f4@oracle.com> References: <5807D43A.10409@oracle.com> <510b4057-8e7c-0ece-5e98-c7fa2ce3d8f4@oracle.com> Message-ID: <0d5fa454-6511-cf55-bfb5-ef4ab2542b59@oracle.com> I've been testing this by re-enabling deprecation so On 11/02/2016 10:50 PM, Prasanta Sadhukhan wrote: > > Do we need the suppression in JavaSoundAudioClip.java as I could not > find any mention of Applet in that class? > > In AppletViewer.java > shouldn't we need to add "deprecation" to > 45 @SuppressWarnings("serial") // JDK implementation class No, it is not needed there since "TextFrame" isn't using any deprecated class. > Do we still need this > > 160 @SuppressWarnings("deprecation") > since we added > > 120 @SuppressWarnings({"serial", "deprecation"}) I agree 160 should not be needed. > > Other than that, looks good to me. OK. I'm going to push with this tweak as the deprecation warnings are starting to pile up again and I need to get at least part of it fixed. -phil > > Regards > Prasanta > On 10/20/2016 1:44 AM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168316 >> Webrev: http://cr.openjdk.java.net/~prr/8168316/ >> >> When applets were deprecated it seems that due to all deprecated >> warning being suppressed in java.desktop many places that should >> have been updated weren't >> >> This resolves the applet ones .. as a precursor to fixing up the >> other issues >> that cause this global supression. >> >> -phil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Nov 7 15:09:29 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 Nov 2016 18:09:29 +0300 Subject: [9] Review request for 8027639: JComboBox's popup leaves tracks after closing In-Reply-To: References: <1a80cff6-a73c-b488-439f-d575bcab76cc@oracle.com> <9071c5a4-4977-9b28-dcfd-197e82470665@oracle.com> <85c0e893-a986-ef8d-4a77-6e0a24193461@oracle.com> <963dd99c-b677-92b9-15fd-f291846ad741@oracle.com> <42d7e4c1-9696-93e7-e01d-0a9401eff339@oracle.com> Message-ID: <73481511-7931-e352-3214-e05e826093de@oracle.com> On 27.10.16 21:43, Semyon Sadetsky wrote: >> As you mention above background of the window will be always cleared >> by the window itself, and we can get double alpha in the background >> when we blit the backbuffer to the window. What composite is used when >> we draw backbuffer to the window? > It is src-over. If it is src-over mean that in the window you will get a composite of colors, which was drawn to the backbuffer and the colors which was drawn in the window(which was drawn by the window itself). And in this case you will get a different results when you paint via backbuffer or when you skip it. >>>>>> Should the previous composite be restored after the rect filling? >>>>> SRC should be the default composite type. >>>> >>>> default composite type should be srcOver, and it should be restored >>>> before call paintToOffscreen(). >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Nov 7 15:31:26 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 7 Nov 2016 18:31:26 +0300 Subject: [9] Review request for 8027639: JComboBox's popup leaves tracks after closing In-Reply-To: <73481511-7931-e352-3214-e05e826093de@oracle.com> References: <1a80cff6-a73c-b488-439f-d575bcab76cc@oracle.com> <9071c5a4-4977-9b28-dcfd-197e82470665@oracle.com> <85c0e893-a986-ef8d-4a77-6e0a24193461@oracle.com> <963dd99c-b677-92b9-15fd-f291846ad741@oracle.com> <42d7e4c1-9696-93e7-e01d-0a9401eff339@oracle.com> <73481511-7931-e352-3214-e05e826093de@oracle.com> Message-ID: <1a776830-5a46-53b5-6e88-b88da0c2db43@oracle.com> On 11/7/2016 6:09 PM, Sergey Bylokhov wrote: > On 27.10.16 21:43, Semyon Sadetsky wrote: >>> As you mention above background of the window will be always cleared >>> by the window itself, and we can get double alpha in the background >>> when we blit the backbuffer to the window. What composite is used when >>> we draw backbuffer to the window? >> It is src-over. > > If it is src-over mean that in the window you will get a composite of > colors, which was drawn to the backbuffer and the colors which was > drawn in the window(which was drawn by the window itself). And in this > case you will get a different results when you paint via backbuffer or > when you skip it. I did not get this. You've state if JRootPane has own different transparent color than it may be painted twice. At first, I'm not sure that JRootPane may have such color. Because we only support window translucency if window is non-opaque and having non-opaque window with opaque JRootPane seems incorrect usage. But anyway I don't see the way how the JRootPane transparent color may be pained twice. For non-opaque JRootPane it's background color is not painted, regardless of transparency. With opaque JRootPane the parent window paint() method will not be called and window background will not be painted. > >>>>>>> Should the previous composite be restored after the rect filling? >>>>>> SRC should be the default composite type. >>>>> >>>>> default composite type should be srcOver, and it should be restored >>>>> before call paintToOffscreen(). >>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon Nov 7 16:01:55 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 Nov 2016 19:01:55 +0300 Subject: [9] Review request for 8027639: JComboBox's popup leaves tracks after closing In-Reply-To: <1a776830-5a46-53b5-6e88-b88da0c2db43@oracle.com> References: <1a80cff6-a73c-b488-439f-d575bcab76cc@oracle.com> <9071c5a4-4977-9b28-dcfd-197e82470665@oracle.com> <85c0e893-a986-ef8d-4a77-6e0a24193461@oracle.com> <963dd99c-b677-92b9-15fd-f291846ad741@oracle.com> <42d7e4c1-9696-93e7-e01d-0a9401eff339@oracle.com> <73481511-7931-e352-3214-e05e826093de@oracle.com> <1a776830-5a46-53b5-6e88-b88da0c2db43@oracle.com> Message-ID: <6651f73d-04a6-22a4-fd33-5f8ecc7406c8@oracle.com> On 07.11.16 18:31, Semyon Sadetsky wrote: >> If it is src-over mean that in the window you will get a composite of >> colors, which was drawn to the backbuffer and the colors which was >> drawn in the window(which was drawn by the window itself). And in this >> case you will get a different results when you paint via backbuffer or >> when you skip it. > I did not get this. You've state if JRootPane has own different > transparent color than it may be painted twice. I am talking about the color of the window, you said that it is always painted. http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006854.html So if it always painted in case of non-opaque windows and you paint it to the backbuffer means that you paint it twice, no? > At first, I'm not sure that JRootPane may have such color. Because we > only support window translucency if window is non-opaque and having > non-opaque window with opaque JRootPane seems incorrect usage. The components can be opaque/non-opaque even if the window is opaque/non-opaque. They have a different meaning. For window this means that it has a transparent background, for components it means that before the component is painted all its containers should be painted first. > But anyway I don't see the way how the JRootPane transparent color may > be pained twice. For non-opaque JRootPane it's background color is not > painted, regardless of transparency. With opaque JRootPane the parent > window paint() method will not be called and window background will not > be painted. >> >>>>>>>> Should the previous composite be restored after the rect filling? >>>>>>> SRC should be the default composite type. >>>>>> >>>>>> default composite type should be srcOver, and it should be restored >>>>>> before call paintToOffscreen(). >>>> >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Mon Nov 7 18:49:28 2016 From: philip.race at oracle.com (Phil Race) Date: Mon, 7 Nov 2016 10:49:28 -0800 Subject: RFR: 8155874: Fix java.desktop deprecation warnings about Class.newInstance Message-ID: <9e100acb-ced0-3e70-61e3-8f33f3ab5bcc@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8155874 Webrev: http://cr.openjdk.java.net/~prr/8155874/ This hits all across the desktop module, hence the cross-post. The Class.newInstance() has been deprecated since it may throw checked exceptions that are not declared. Class.getConstructor().newInstance() was recommended as a replacement but it will return only public constructors. So if you have package access to a package private constructor it will fail where as the previous pattern succeeded So the recommendation now is to use Class.getDeclaredConstructor().newInstance() and this fix uses that except for some cases where we have a limited and known set of internal "service providers" which are known to use public classes and constructors. Also some exception catching has been cleaned up as appropriate for the new method call and taking advantage of the JDK 1.7 ReflectiveOperationException -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Nov 7 19:12:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 7 Nov 2016 22:12:43 +0300 Subject: RFR: 8155874: Fix java.desktop deprecation warnings about Class.newInstance In-Reply-To: <9e100acb-ced0-3e70-61e3-8f33f3ab5bcc@oracle.com> References: <9e100acb-ced0-3e70-61e3-8f33f3ab5bcc@oracle.com> Message-ID: <675d4cbd-76f2-e4f8-3cd3-b49d90936591@oracle.com> Looks fine. On 07.11.16 21:49, Phil Race wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8155874 > Webrev: http://cr.openjdk.java.net/~prr/8155874/ > > This hits all across the desktop module, hence the cross-post. > > The Class.newInstance() has been deprecated since it > may throw checked exceptions that are not declared. > > Class.getConstructor().newInstance() was recommended as a > replacement but it will return only public constructors. > > So if you have package access to a package private constructor it will > fail where > as the previous pattern succeeded > > So the recommendation now is to use > Class.getDeclaredConstructor().newInstance() > and this fix uses that except for some cases where we have a limited and > known > set of internal "service providers" which are known to use public > classes and constructors. > > Also some exception catching has been cleaned up as appropriate for the > new method call and taking advantage of the JDK 1.7 > ReflectiveOperationException > > -phil. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Tue Nov 8 09:20:42 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 8 Nov 2016 12:20:42 +0300 Subject: RFR: 8155874: Fix java.desktop deprecation warnings about Class.newInstance In-Reply-To: <675d4cbd-76f2-e4f8-3cd3-b49d90936591@oracle.com> References: <9e100acb-ced0-3e70-61e3-8f33f3ab5bcc@oracle.com> <675d4cbd-76f2-e4f8-3cd3-b49d90936591@oracle.com> Message-ID: The fix looks good to me. Thanks, Alexandr. On 11/7/2016 10:12 PM, Sergey Bylokhov wrote: > Looks fine. > > On 07.11.16 21:49, Phil Race wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8155874 >> Webrev: http://cr.openjdk.java.net/~prr/8155874/ >> >> This hits all across the desktop module, hence the cross-post. >> >> The Class.newInstance() has been deprecated since it >> may throw checked exceptions that are not declared. >> >> Class.getConstructor().newInstance() was recommended as a >> replacement but it will return only public constructors. >> >> So if you have package access to a package private constructor it will >> fail where >> as the previous pattern succeeded >> >> So the recommendation now is to use >> Class.getDeclaredConstructor().newInstance() >> and this fix uses that except for some cases where we have a limited and >> known >> set of internal "service providers" which are known to use public >> classes and constructors. >> >> Also some exception catching has been cleaned up as appropriate for the >> new method call and taking advantage of the JDK 1.7 >> ReflectiveOperationException >> >> -phil. >> > > From Sergey.Bylokhov at oracle.com Tue Nov 8 13:00:14 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 8 Nov 2016 16:00:14 +0300 Subject: [9] Review request for 8074883: Tab key should move to focused button in a button group In-Reply-To: References: <28fd190a-c8dc-fb96-5010-22063186a7e3@oracle.com> <5a628ad3-edac-0b45-7c9e-840315e6d07f@oracle.com> <1aa50e8b-6ac3-9431-2bbc-fea5ec4754a8@oracle.com> <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com>

Message-ID: <5aecaa3b-6fbc-e4a5-da09-d47de6c201bd@oracle.com> On 02.11.16 10:51, Semyon Sadetsky wrote: > On 11/1/2016 10:37 PM, Sergey Bylokhov wrote: > >> On 28.10.16 11:20, Semyon Sadetsky wrote: >>>> probably it is possible to change the while loop to something? just to >>>> hide the usage of Enumeration? like >>>> Enumiration.asIterator().forEachRemaining()? >>> I did not get why. What is wrong with Enumeration? >> >> It is an old style iterator, and we can hide its usage. > Okay. http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.02/ But what about the question to specification, is it the spac below is true when the selected toggle button is disabled?: 48 * If this toggle button is a member of the {@link ButtonGroup} which has an another focusable toggle button selected, and the focus cause argument denotes window activation or focus traversal action of any direction the result of the method execution is the same as calling {@link Component#requestFocus(FocusEvent.Cause)} on the toggle button selected in the group. Because the current implementation filter out disabled components(the same question is about invisible, non-displayable), but according to the spec results should be the same like we call the method directly on the selected button. >> >>>> >>> If a component is disabled it cannot receive input focus, see >>> java.awt.Component#isEnabled specs. The proposed spec clearly states : >>> >>> 247 * If this toggle button is a member of the {@link ButtonGroup} >>> which has >>> 248 * an another ***focusable*** toggle button selected, and the >>> focus cause argument >>> >>>> It seems that the code in getGroupSelection() will focus the first >>>> element in the group, but what elements will be focused if we call >>>> Component#requestFocus(FocusEvent.Cause) directly for this disabled >>>> compoenent? Will the the same(first) element be selected? >>> I did find any mentions of "first element" in the proposed spec. Please >>> clarify this question. >>> According to the proposed spec the case when >>> Component#requestFocus(FocusEvent.Cause) is called on disabled component >>> will be handled as: >>> >>> 253 * In all other cases the result of the method is the same as >>> calling >>> 254 * {@link Component#requestFocus(FocusEvent.Cause)} on this >>> toggle button. >> >> The specification states that the call to >> this.requestFocus(FocusEvent.Cause cause); >> and the call to >> selected.requestFocus(FocusEvent.Cause cause); >> produce the same result "If this toggle button is a member of the >> {@link ButtonGroup} which has an another focusable toggle button >> selected, and the focus cause argument denotes window activation or >> focus traversal action of any direction" >> >> The question was "is that always true if the selected element is >> disabled(but focusable)"? I guess that the implementation in the fix >> will select the first "this"(the button on which requestFocus() was >> called), but in the second case something different will be selected. >> >>>>> On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote: >>>>>> On 10/19/2016 8:14 PM, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review fix for JDK9: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074883 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/ >>>>>>> >>>>>>> To avoid unexpected selection change the selected button of a button >>>>>>> group should always grab focus when focus is transferred form >>>>>>> component outside the group to any unselected button inside the >>>>>>> group >>>>>>> in case of traversal or initial container activation actions. >>>>>> - It is better to pass the cause and boolean focusInWindow >>>>>> arguments >>>>>> to the getGroupSelection() method to avoid some code duplication like >>>>>> switching over the same cause values. >>>>>> - The fix will require a CCC request because it updates a javadoc >>>>>> for the publci method. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Nov 8 13:39:22 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 8 Nov 2016 16:39:22 +0300 Subject: [9] Review request for 8075918: The regression-swing case failed as the long Tab titles are not clipped with dots at the end with the special options"-client -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel" In-Reply-To: References: <23dd39ad-77aa-cc77-0eb0-3692ac41fbcb@oracle.com> <69259a64-edd2-0098-6a4b-3a5682b745b4@oracle.com> <3134cc26-3f5f-a2be-5a8b-d9a20dd8d59b@oracle.com> Message-ID: <95db52a5-3a5f-9f3a-f9cb-76186f3c171d@oracle.com> On 02.11.16 10:48, Semyon Sadetsky wrote: > On 11/1/2016 10:44 PM, Sergey Bylokhov wrote: >> On 28.10.16 12:35, Semyon Sadetsky wrote: >>>> Probably this clipping should be done in the >>>> 633 paintText(ss, g, tabPlacement, font, metrics, >>>> 634 tabIndex, clippedTitle, textRect, isSelected); >>>> ? >>> It should be designed in the same way as in basic class. Currently the >>> BasicTabbedPaneUI#paintText() receives pre-clipped text to paint and the >>> clipping is executed in the paintTab(). >>>> It seems that currently this method contradicts its specification and >>>> skips the w/h of the passed bounds(in this case "textRect"). >>> I don't see any mentions of text clipping in this spec. >> >> SynthGraphicsUtils.java >> * @param bounds Bounds of the text to be drawn.h >> * @param mnemonicIndex Index to draw string at. >> */ >> public void paintText(SynthContext ss, Graphics g, String text, >> Rectangle bounds, int mnemonicIndex) { >> .... >> >> The textRect variable which is calculated in the changed method and >> passed to paintText() is "Bounds of the text to be drawn". The method >> violates its specification and ignores w/h of these bounds. So the >> text is painted outside of the Tab. > Anyway it doesn't say do clip. The bounds to which the text should be drawn mean that the "paint" should not draw outside of this area(this area should be used as a clip). This bug is also affects the Icons in tabpain which also ignore these bounds and paints outside of the tab area. > Adding clipping to this method would be a mistake because in this case > the text may be clipped twice. >> >>>> >>>> On 21.10.16 15:12, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075918 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8075918/webrev.00/ >>>>> >>>>> Title text clipping capability is added to the Synth L&F's tabbed pane >>>>> UI to fix the issue. >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From avik.niyogi at oracle.com Wed Nov 9 08:06:15 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 9 Nov 2016 13:36:15 +0530 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java Message-ID: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> Hi All, Kindly review the proposed webrev for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8167160 Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/ Issue: The test case : javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X Cause: The test case does not apply for OS X and should work for windows and Linux Fix: Appropriatechanges in test case parameters were added. With Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Nov 9 10:11:28 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 9 Nov 2016 15:41:28 +0530 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> Message-ID: <66b71127-00b5-d745-5ecc-0319a52bf23b@oracle.com> looks good to me. Regards Prasanta On 11/9/2016 1:36 PM, Avik Niyogi wrote: > Hi All, > > Kindly review the proposed webrev for JDK9. > > *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* > > *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/ > * > > *Issue: *The test case : > javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X > > *Cause: * The test case does not apply for OS X and should work for > windows and Linux > > *Fix:* Appropriatechanges in test case parameters were added. > > With Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Nov 9 13:21:42 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 9 Nov 2016 16:21:42 +0300 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> Message-ID: <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com> On 09.11.16 11:06, Avik Niyogi wrote: > *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* > > *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* > > *Issue: *The test case : > javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X > > *Cause: * The test case does not apply for OS X and should work for > windows and Linux What is the reason why the test does not work on OSX? -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Wed Nov 9 13:30:02 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 9 Nov 2016 16:30:02 +0300 Subject: [9] Review request for 8075084: https://bugs.openjdk.java.net/browse/JDK-8075084 In-Reply-To: References: Message-ID: On 10/25/2016 4:24 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8075084 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8075084/webrev.00/ > > When a modal dialog is shown in scroll bar button click listener it > blocks all events targeted to the scroll bar owner window. > > At the same time clicking on scroll bar button triggers a timer which > should adjust scroll bar value automatically until mouse button is > released, i.e. until mouse release event comes to the pushed scroll > button. So, this timer is not stopped by the mouse release event > because it is rejected by the modal filter. When modal dialog is > closed the timer continues to produce scroll adjustment events and the > dialog is shown again. Also the scroll button remains pushed and > hovered all the time (because it didn't get mouse release event). > > In the suggested fix the timer is started only if the scroll bar owner > window keeps input focus after the adjustment callback and the scroll > button is reset otherwise. Is it possible that a scroll bar lost the focus not because a new modal dialog opened by some other valid reason and the scroll timer should be started for this case? Thanks, Alexandr. > > --Semyon > From avik.niyogi at oracle.com Thu Nov 10 06:53:18 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Thu, 10 Nov 2016 12:23:18 +0530 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com> References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com> Message-ID: Arrow buttons for traversing a radio button group is not the expected OS X behaviour. In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. > On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov wrote: > > On 09.11.16 11:06, Avik Niyogi wrote: >> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >> >> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >> >> *Issue: *The test case : >> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >> >> *Cause: * The test case does not apply for OS X and should work for >> windows and Linux > > What is the reason why the test does not work on OSX? > > > -- > Best regards, Sergey. From semyon.sadetsky at oracle.com Thu Nov 10 07:33:28 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 10 Nov 2016 10:33:28 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> <413e1a77-b95e-15b3-203e-ccecccff3ec5@oracle.com> <1e0f3003-d2c0-c11a-08f1-18cb8c891994@oracle.com> Message-ID: please review the updated webrev: http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.02/ system property was removed. --Semyon On 7/21/2016 4:40 PM, Semyon Sadetsky wrote: > > > On 7/21/2016 2:51 PM, Alexandr Scherbatiy wrote: >> On 7/20/2016 4:46 PM, Semyon Sadetsky wrote: >>> >>> >>> On 7/20/2016 2:29 PM, Alexandr Scherbatiy wrote: >>>> On 7/20/2016 10:18 AM, Semyon Sadetsky wrote: >>>>> On 7/19/2016 4:06 PM, Alexandr Scherbatiy wrote: >>>>> >>>>>> On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: >>>>>>> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> The fix prints the warning method in case of wrong row sorter >>>>>>>> usage. How often this can happen? Could the large number of the >>>>>>>> messages overflow a user output? >>>>>>> In the FilePane this happened only once after the initial file >>>>>>> list loading. >>>>>> I am just worrying that in a user application which does not >>>>>> properly use the row sorter there can be a lot of such warnings. >>>>>> And it could be some library which he can't be able to update. Is >>>>>> it possible to show the warning only once? >>>>> Yes. See the updated webrev: >>>>> http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.01/ >>>> A property which should be used by users needs to have the CCC >>>> request. >>> It is added on the off-chance. It doesn't merit to be a documented >>> property. >> Who should use the proposed property? > If it will not be possible to correct the code (for example an old > application that is not supported) and seeing the warning is > displeased for some reasons. > > --Semyon >> >> Thanks, >> Alexandr. >> >>> >>> --Semyon >>>> I believe that printing the warning message only once is enough. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>>>>>>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> A warning is added to avoid issues in user code to throw >>>>>>>>>>> exceptions which were masked before. See bug descriptions >>>>>>>>>>> for details. >>>>>>>>>> Should this behavior (which exists for long time) be >>>>>>>>>> specified in the >>>>>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>>>>> javadoc? >>>>>>>>> This was not a >>>>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>>>> issue. It was a mistake in the FilePane class. >>>>>>>>> RowSorter's javadoc mentions the correct way to use it: >>>>>>>>> >>>>>>>>> The view invokes a model change method when the underlying >>>>>>>>> model has changed. There may be order dependencies in how the >>>>>>>>> events are delivered, so a RowSorter should not update its >>>>>>>>> mapping until one of these methods is invoked. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Thu Nov 10 08:01:40 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 10 Nov 2016 11:01:40 +0300 Subject: [9] Review request for 8075084: https://bugs.openjdk.java.net/browse/JDK-8075084 In-Reply-To: References:

Message-ID: <517a8252-744c-2626-0eb3-3c38e3f7f175@oracle.com> On 11/9/2016 4:30 PM, Alexandr Scherbatiy wrote: > On 10/25/2016 4:24 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8075084 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8075084/webrev.00/ >> >> When a modal dialog is shown in scroll bar button click listener it >> blocks all events targeted to the scroll bar owner window. >> >> At the same time clicking on scroll bar button triggers a timer which >> should adjust scroll bar value automatically until mouse button is >> released, i.e. until mouse release event comes to the pushed scroll >> button. So, this timer is not stopped by the mouse release event >> because it is rejected by the modal filter. When modal dialog is >> closed the timer continues to produce scroll adjustment events and >> the dialog is shown again. Also the scroll button remains pushed and >> hovered all the time (because it didn't get mouse release event). >> >> In the suggested fix the timer is started only if the scroll bar >> owner window keeps input focus after the adjustment callback and the >> scroll button is reset otherwise. > > Is it possible that a scroll bar lost the focus not because a new > modal dialog opened by some other valid reason and the scroll timer > should be started for this case? It is not possible, because setting another window as focused in KFM is executed in the component event handler on EDT, which will only happen after returning from the mouse pressed handler or if the secondary event loop is started (a modal dialog is shown). --Semyon > > Thanks, > Alexandr. > >> >> --Semyon >> > From philip.race at oracle.com Thu Nov 10 17:50:59 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 10 Nov 2016 09:50:59 -0800 Subject: RFR: 8169518: Suppress Deprecation warnings for deprecated Swing APIs Message-ID: <3412484c-3ea5-04dd-62c0-be66521acc6b@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8169518 Webrev: http://cr.openjdk.java.net/~prr/8169518 The last set of deprecation warnings to be suppressed or fixed in desktop - so with this fix we can re-enable javac lint checking of deprecation. I have used JPRT to verify this builds on all platforms. -phil. From alexander.zvegintsev at oracle.com Fri Nov 11 09:36:20 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 11 Nov 2016 12:36:20 +0300 Subject: [9] Review request for 8160087: Change IOOBE to warning in the scenarios when it had not being thrown before the JDK-8078514 In-Reply-To: References: <19eeb5bb-18bc-85b2-7eaf-f16bfb6a0f9d@oracle.com> <4bcb6a4a-030c-fea5-30d5-33ec1c0ff2c1@oracle.com> <578DF340.8060204@oracle.com> <7e874ada-48e0-ec9a-da52-1cbf5cd519c7@oracle.com> <578E1564.4010007@oracle.com> <66bd44af-5787-7a9b-57f5-43af52e9c5e5@oracle.com> <413e1a77-b95e-15b3-203e-ccecccff3ec5@oracle.com> <1e0f3003-d2c0-c11a-08f1-18cb8c891994@oracle.com>

Message-ID: +1 -- Thanks, Alexander. On 10.11.2016 10:33, Semyon Sadetsky wrote: > please review the updated webrev: > http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.02/ > > system property was removed. > > --Semyon > > > On 7/21/2016 4:40 PM, Semyon Sadetsky wrote: >> >> >> On 7/21/2016 2:51 PM, Alexandr Scherbatiy wrote: >>> On 7/20/2016 4:46 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 7/20/2016 2:29 PM, Alexandr Scherbatiy wrote: >>>>> On 7/20/2016 10:18 AM, Semyon Sadetsky wrote: >>>>>> On 7/19/2016 4:06 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>>> On 7/19/2016 2:56 PM, Semyon Sadetsky wrote: >>>>>>>> On 19.07.2016 14:20, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> The fix prints the warning method in case of wrong row sorter >>>>>>>>> usage. How often this can happen? Could the large number of >>>>>>>>> the messages overflow a user output? >>>>>>>> In the FilePane this happened only once after the initial file >>>>>>>> list loading. >>>>>>> I am just worrying that in a user application which does not >>>>>>> properly use the row sorter there can be a lot of such warnings. >>>>>>> And it could be some library which he can't be able to update. >>>>>>> Is it possible to show the warning only once? >>>>>> Yes. See the updated webrev: >>>>>> http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.01/ >>>>> A property which should be used by users needs to have the CCC >>>>> request. >>>> It is added on the off-chance. It doesn't merit to be a documented >>>> property. >>> Who should use the proposed property? >> If it will not be possible to correct the code (for example an old >> application that is not supported) and seeing the warning is >> displeased for some reasons. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>>> I believe that printing the warning message only once is enough. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 7/19/2016 12:30 PM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 19.07.2016 12:18, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 7/18/2016 11:46 AM, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160087 >>>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8160087/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> A warning is added to avoid issues in user code to throw >>>>>>>>>>>> exceptions which were masked before. See bug descriptions >>>>>>>>>>>> for details. >>>>>>>>>>> Should this behavior (which exists for long time) be >>>>>>>>>>> specified in the >>>>>>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>>>>>> javadoc? >>>>>>>>>> This was not a >>>>>>>>>> DefaultRowSorter.convertRowIndexToView()/convertRowIndexToModel() >>>>>>>>>> issue. It was a mistake in the FilePane class. >>>>>>>>>> RowSorter's javadoc mentions the correct way to use it: >>>>>>>>>> >>>>>>>>>> The view invokes a model change method when the underlying >>>>>>>>>> model has changed. There may be order dependencies in how the >>>>>>>>>> events are delivered, so a RowSorter should not update its >>>>>>>>>> mapping until one of these methods is invoked. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Sun Nov 13 20:48:23 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 13 Nov 2016 23:48:23 +0300 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com> Message-ID: On 10.11.16 9:53, Avik Niyogi wrote: > Arrow buttons for traversing a radio button group is not the expected OS X behaviour. This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? > In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov wrote: >> >> On 09.11.16 11:06, Avik Niyogi wrote: >>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>> >>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>> >>> *Issue: *The test case : >>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>> >>> *Cause: * The test case does not apply for OS X and should work for >>> windows and Linux >> >> What is the reason why the test does not work on OSX? >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From avik.niyogi at oracle.com Mon Nov 14 03:43:46 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 14 Nov 2016 09:13:46 +0530 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com>

Message-ID: <12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com> This is OS X Specific. > On 14-Nov-2016, at 2:18 am, Sergey Bylokhov wrote: > > On 10.11.16 9:53, Avik Niyogi wrote: >> Arrow buttons for traversing a radio button group is not the expected OS X behaviour. > > This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? > >> In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov wrote: >>> >>> On 09.11.16 11:06, Avik Niyogi wrote: >>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>>> >>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>>> >>>> *Issue: *The test case : >>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>>> >>>> *Cause: * The test case does not apply for OS X and should work for >>>> windows and Linux >>> >>> What is the reason why the test does not work on OSX? >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Nov 14 09:03:53 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 14 Nov 2016 12:03:53 +0300 Subject: [9] Review request for 8027639: JComboBox's popup leaves tracks after closing In-Reply-To: <6651f73d-04a6-22a4-fd33-5f8ecc7406c8@oracle.com> References: <1a80cff6-a73c-b488-439f-d575bcab76cc@oracle.com> <9071c5a4-4977-9b28-dcfd-197e82470665@oracle.com> <85c0e893-a986-ef8d-4a77-6e0a24193461@oracle.com> <963dd99c-b677-92b9-15fd-f291846ad741@oracle.com> <42d7e4c1-9696-93e7-e01d-0a9401eff339@oracle.com> <73481511-7931-e352-3214-e05e826093de@oracle.com> <1a776830-5a46-53b5-6e88-b88da0c2db43@oracle.com> <6651f73d-04a6-22a4-fd33-5f8ecc7406c8@oracle.com> Message-ID: <516833ea-7bfb-be0e-7c67-d2584839bf8b@oracle.com> Please review the updated webrev: http://cr.openjdk.java.net/~ssadetsky/8027639/webrev.01/ - buffer fill color is changed to 0,0,0,0 - graphics context background color and composition is restored - scenario when the buffered JComponent has transparent background and opaque=true is taken into account --Semyon On 11/7/2016 7:01 PM, Sergey Bylokhov wrote: > On 07.11.16 18:31, Semyon Sadetsky wrote: >>> If it is src-over mean that in the window you will get a composite of >>> colors, which was drawn to the backbuffer and the colors which was >>> drawn in the window(which was drawn by the window itself). And in this >>> case you will get a different results when you paint via backbuffer or >>> when you skip it. >> I did not get this. You've state if JRootPane has own different >> transparent color than it may be painted twice. > > I am talking about the color of the window, you said that it is always > painted. > http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006854.html > So if it always painted in case of non-opaque windows and you paint it > to the backbuffer means that you paint it twice, no? > >> At first, I'm not sure that JRootPane may have such color. Because we >> only support window translucency if window is non-opaque and having >> non-opaque window with opaque JRootPane seems incorrect usage. > > The components can be opaque/non-opaque even if the window is > opaque/non-opaque. They have a different meaning. For window this > means that it has a transparent background, for components it means > that before the component is painted all its containers should be > painted first. > >> But anyway I don't see the way how the JRootPane transparent color may >> be pained twice. For non-opaque JRootPane it's background color is not >> painted, regardless of transparency. With opaque JRootPane the parent >> window paint() method will not be called and window background will not >> be painted. >>> >>>>>>>>> Should the previous composite be restored after the rect >>>>>>>>> filling? >>>>>>>> SRC should be the default composite type. >>>>>>> >>>>>>> default composite type should be srcOver, and it should be restored >>>>>>> before call paintToOffscreen(). >>>>> >>>>> >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Mon Nov 14 09:16:20 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 14 Nov 2016 12:16:20 +0300 Subject: [9] Review request for 8074883: Tab key should move to focused button in a button group In-Reply-To: <5aecaa3b-6fbc-e4a5-da09-d47de6c201bd@oracle.com> References: <28fd190a-c8dc-fb96-5010-22063186a7e3@oracle.com> <5a628ad3-edac-0b45-7c9e-840315e6d07f@oracle.com> <1aa50e8b-6ac3-9431-2bbc-fea5ec4754a8@oracle.com> <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com>

<5aecaa3b-6fbc-e4a5-da09-d47de6c201bd@oracle.com> Message-ID: <44aeb9e7-92f0-45cb-bf75-06de3c612199@oracle.com> On 11/8/2016 4:00 PM, Sergey Bylokhov wrote: > On 02.11.16 10:51, Semyon Sadetsky wrote: >> On 11/1/2016 10:37 PM, Sergey Bylokhov wrote: >> >>> On 28.10.16 11:20, Semyon Sadetsky wrote: >>>>> probably it is possible to change the while loop to something? >>>>> just to >>>>> hide the usage of Enumeration? like >>>>> Enumiration.asIterator().forEachRemaining()? >>>> I did not get why. What is wrong with Enumeration? >>> >>> It is an old style iterator, and we can hide its usage. >> Okay. http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.02/ > > But what about the question to specification, is it the spac below is > true when the selected toggle button is disabled?: > > 48 * If this toggle button is a member of the {@link ButtonGroup} > which has an another focusable toggle button selected, and the focus > cause argument denotes window activation or focus traversal action of > any direction the result of the method execution is the same as > calling {@link Component#requestFocus(FocusEvent.Cause)} on the toggle > button selected in the group. > > Because the current implementation filter out disabled components(the > same question is about invisible, non-displayable), but according to > the spec results should be the same like we call the method directly > on the selected button. Probably you missed my previous answer to this question: If a component is disabled it cannot receive input focus, see java.awt.Component#isEnabled specs. The proposed spec clearly states : 247 * If this toggle button is a member of the {@link ButtonGroup} which has 248 * an another ***focusable*** toggle button selected, and the focus cause argument in Swing a component may not receive focus if it is disabled, invisible, non-displayable... According to the spec the result will be the same if you call Component#requestFocus on ***this*** toggle button. > >>> >>>>> >>>> If a component is disabled it cannot receive input focus, see >>>> java.awt.Component#isEnabled specs. The proposed spec clearly >>>> states : >>>> >>>> 247 * If this toggle button is a member of the {@link >>>> ButtonGroup} >>>> which has >>>> 248 * an another ***focusable*** toggle button selected, and the >>>> focus cause argument >>>> >>>>> It seems that the code in getGroupSelection() will focus the first >>>>> element in the group, but what elements will be focused if we call >>>>> Component#requestFocus(FocusEvent.Cause) directly for this disabled >>>>> compoenent? Will the the same(first) element be selected? >>>> I did find any mentions of "first element" in the proposed spec. >>>> Please >>>> clarify this question. >>>> According to the proposed spec the case when >>>> Component#requestFocus(FocusEvent.Cause) is called on disabled >>>> component >>>> will be handled as: >>>> >>>> 253 * In all other cases the result of the method is the same as >>>> calling >>>> 254 * {@link Component#requestFocus(FocusEvent.Cause)} on this >>>> toggle button. >>> >>> The specification states that the call to >>> this.requestFocus(FocusEvent.Cause cause); >>> and the call to >>> selected.requestFocus(FocusEvent.Cause cause); >>> produce the same result "If this toggle button is a member of the >>> {@link ButtonGroup} which has an another focusable toggle button >>> selected, and the focus cause argument denotes window activation or >>> focus traversal action of any direction" >>> >>> The question was "is that always true if the selected element is >>> disabled(but focusable)"? I guess that the implementation in the fix >>> will select the first "this"(the button on which requestFocus() was >>> called), but in the second case something different will be selected. >>> >>>>>> On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote: >>>>>>> On 10/19/2016 8:14 PM, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review fix for JDK9: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074883 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/ >>>>>>>> >>>>>>>> To avoid unexpected selection change the selected button of a >>>>>>>> button >>>>>>>> group should always grab focus when focus is transferred form >>>>>>>> component outside the group to any unselected button inside the >>>>>>>> group >>>>>>>> in case of traversal or initial container activation actions. >>>>>>> - It is better to pass the cause and boolean focusInWindow >>>>>>> arguments >>>>>>> to the getGroupSelection() method to avoid some code duplication >>>>>>> like >>>>>>> switching over the same cause values. >>>>>>> - The fix will require a CCC request because it updates a javadoc >>>>>>> for the publci method. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon Nov 14 12:52:01 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Nov 2016 15:52:01 +0300 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: <12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com> References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com>

<12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com> Message-ID: On 14.11.16 6:43, Avik Niyogi wrote: > This is OS X Specific. Are you sure? I guess the test will pass if will be run using MetalLookAndFeel. >> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov wrote: >> >> On 10.11.16 9:53, Avik Niyogi wrote: >>> Arrow buttons for traversing a radio button group is not the expected OS X behaviour. >> >> This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? >> >>> In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov wrote: >>>> >>>> On 09.11.16 11:06, Avik Niyogi wrote: >>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>>>> >>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>>>> >>>>> *Issue: *The test case : >>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>>>> >>>>> *Cause: * The test case does not apply for OS X and should work for >>>>> windows and Linux >>>> >>>> What is the reason why the test does not work on OSX? >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Nov 14 13:24:22 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Nov 2016 16:24:22 +0300 Subject: [9] Review request for 8074883: Tab key should move to focused button in a button group In-Reply-To: <44aeb9e7-92f0-45cb-bf75-06de3c612199@oracle.com> References: <28fd190a-c8dc-fb96-5010-22063186a7e3@oracle.com> <5a628ad3-edac-0b45-7c9e-840315e6d07f@oracle.com> <1aa50e8b-6ac3-9431-2bbc-fea5ec4754a8@oracle.com> <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com>

<5aecaa3b-6fbc-e4a5-da09-d47de6c201bd@oracle.com> <44aeb9e7-92f0-45cb-bf75-06de3c612199@oracle.com> Message-ID: <80642c14-c243-37df-0c4c-5e7fcf77f3eb@oracle.com> On 14.11.16 12:16, Semyon Sadetsky wrote: >> But what about the question to specification, is it the spac below is >> true when the selected toggle button is disabled?: >> >> 48 * If this toggle button is a member of the {@link ButtonGroup} >> which has an another focusable toggle button selected, and the focus >> cause argument denotes window activation or focus traversal action of >> any direction the result of the method execution is the same as >> calling {@link Component#requestFocus(FocusEvent.Cause)} on the toggle >> button selected in the group. >> >> Because the current implementation filter out disabled components(the >> same question is about invisible, non-displayable), but according to >> the spec results should be the same like we call the method directly >> on the selected button. > Probably you missed my previous answer to this question: > > If a component is disabled it cannot receive input focus, see > java.awt.Component#isEnabled specs. The proposed spec clearly states : > > 247 * If this toggle button is a member of the {@link ButtonGroup} > which has > 248 * an another ***focusable*** toggle button selected, and the > focus cause argument > > in Swing a component may not receive focus if it is disabled, invisible, > non-displayable... > According to the spec the result will be the same if you call > Component#requestFocus on ***this*** toggle button. It just confirms that the new spec is not complete, result of "Component#requestFocus on ***this*** toggle button" will be different from the result of "selected#requestFocus(FocusEvent.Cause)" if the selected component is disabled. Because "Component#requestFocus on ***this*** toggle button" will select "this", and "selected#requestFocus(FocusEvent.Cause)" will select nothing. The property "***focusable***" is a defined in the Component#isFocusable() and have nothing related to visibility, enable state/etc. It will return true if component is disabled. >> >>>> >>>>>> >>>>> If a component is disabled it cannot receive input focus, see >>>>> java.awt.Component#isEnabled specs. The proposed spec clearly >>>>> states : >>>>> >>>>> 247 * If this toggle button is a member of the {@link >>>>> ButtonGroup} >>>>> which has >>>>> 248 * an another ***focusable*** toggle button selected, and the >>>>> focus cause argument >>>>> >>>>>> It seems that the code in getGroupSelection() will focus the first >>>>>> element in the group, but what elements will be focused if we call >>>>>> Component#requestFocus(FocusEvent.Cause) directly for this disabled >>>>>> compoenent? Will the the same(first) element be selected? >>>>> I did find any mentions of "first element" in the proposed spec. >>>>> Please >>>>> clarify this question. >>>>> According to the proposed spec the case when >>>>> Component#requestFocus(FocusEvent.Cause) is called on disabled >>>>> component >>>>> will be handled as: >>>>> >>>>> 253 * In all other cases the result of the method is the same as >>>>> calling >>>>> 254 * {@link Component#requestFocus(FocusEvent.Cause)} on this >>>>> toggle button. >>>> >>>> The specification states that the call to >>>> this.requestFocus(FocusEvent.Cause cause); >>>> and the call to >>>> selected.requestFocus(FocusEvent.Cause cause); >>>> produce the same result "If this toggle button is a member of the >>>> {@link ButtonGroup} which has an another focusable toggle button >>>> selected, and the focus cause argument denotes window activation or >>>> focus traversal action of any direction" >>>> >>>> The question was "is that always true if the selected element is >>>> disabled(but focusable)"? I guess that the implementation in the fix >>>> will select the first "this"(the button on which requestFocus() was >>>> called), but in the second case something different will be selected. >>>> >>>>>>> On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 10/19/2016 8:14 PM, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review fix for JDK9: >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074883 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/ >>>>>>>>> >>>>>>>>> To avoid unexpected selection change the selected button of a >>>>>>>>> button >>>>>>>>> group should always grab focus when focus is transferred form >>>>>>>>> component outside the group to any unselected button inside the >>>>>>>>> group >>>>>>>>> in case of traversal or initial container activation actions. >>>>>>>> - It is better to pass the cause and boolean focusInWindow >>>>>>>> arguments >>>>>>>> to the getGroupSelection() method to avoid some code duplication >>>>>>>> like >>>>>>>> switching over the same cause values. >>>>>>>> - The fix will require a CCC request because it updates a javadoc >>>>>>>> for the publci method. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From avik.niyogi at oracle.com Mon Nov 14 14:18:56 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 14 Nov 2016 19:48:56 +0530 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com>

<12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com> Message-ID: I checked with MetalLAF as well. does not seem to work. also, tried with a native Mac app. Does not have any option for radio button focus traversal. > On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov wrote: > > On 14.11.16 6:43, Avik Niyogi wrote: >> This is OS X Specific. > > Are you sure? I guess the test will pass if will be run using MetalLookAndFeel. > >>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov wrote: >>> >>> On 10.11.16 9:53, Avik Niyogi wrote: >>>> Arrow buttons for traversing a radio button group is not the expected OS X behaviour. >>> >>> This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? >>> >>>> In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov wrote: >>>>> >>>>> On 09.11.16 11:06, Avik Niyogi wrote: >>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>>>>> >>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>>>>> >>>>>> *Issue: *The test case : >>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>>>>> >>>>>> *Cause: * The test case does not apply for OS X and should work for >>>>>> windows and Linux >>>>> >>>>> What is the reason why the test does not work on OSX? >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Nov 14 14:33:24 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Nov 2016 17:33:24 +0300 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com>

<12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com>

Message-ID: <8d86bcae-6f25-170a-82a3-0b1732621e52@oracle.com> On 14.11.16 17:18, Avik Niyogi wrote: > I checked with MetalLAF as well. does not seem to work. also, tried with a native Mac app. Does not have any option for radio button focus traversal. Can you please clarify how you set the L&F for this test? I also checked it and the test passed on the current jdk9-client in case of "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel" > >> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov wrote: >> >> On 14.11.16 6:43, Avik Niyogi wrote: >>> This is OS X Specific. >> >> Are you sure? I guess the test will pass if will be run using MetalLookAndFeel. >> >>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov wrote: >>>> >>>> On 10.11.16 9:53, Avik Niyogi wrote: >>>>> Arrow buttons for traversing a radio button group is not the expected OS X behaviour. >>>> >>>> This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? >>>> >>>>> In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov wrote: >>>>>> >>>>>> On 09.11.16 11:06, Avik Niyogi wrote: >>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>>>>>> >>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>>>>>> >>>>>>> *Issue: *The test case : >>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>>>>>> >>>>>>> *Cause: * The test case does not apply for OS X and should work for >>>>>>> windows and Linux >>>>>> >>>>>> What is the reason why the test does not work on OSX? >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From avik.niyogi at oracle.com Mon Nov 14 15:33:19 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 14 Nov 2016 21:03:19 +0530 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: <8d86bcae-6f25-170a-82a3-0b1732621e52@oracle.com> References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com>

<12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com>

<8d86bcae-6f25-170a-82a3-0b1732621e52@oracle.com> Message-ID: <2E02C35E-E32F-45B4-A2AE-1D7407AFCAB2@oracle.com> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works but for default settings on mac it is not working. > On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov wrote: > > On 14.11.16 17:18, Avik Niyogi wrote: >> I checked with MetalLAF as well. does not seem to work. also, tried with a native Mac app. Does not have any option for radio button focus traversal. > > Can you please clarify how you set the L&F for this test? I also checked it and the test passed on the current jdk9-client in case of "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel" > >> >>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov wrote: >>> >>> On 14.11.16 6:43, Avik Niyogi wrote: >>>> This is OS X Specific. >>> >>> Are you sure? I guess the test will pass if will be run using MetalLookAndFeel. >>> >>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov wrote: >>>>> >>>>> On 10.11.16 9:53, Avik Niyogi wrote: >>>>>> Arrow buttons for traversing a radio button group is not the expected OS X behaviour. >>>>> >>>>> This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? >>>>> >>>>>> In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov wrote: >>>>>>> >>>>>>> On 09.11.16 11:06, Avik Niyogi wrote: >>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>>>>>>> >>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>>>>>>> >>>>>>>> *Issue: *The test case : >>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>>>>>>> >>>>>>>> *Cause: * The test case does not apply for OS X and should work for >>>>>>>> windows and Linux >>>>>>> >>>>>>> What is the reason why the test does not work on OSX? >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Nov 14 15:51:16 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 14 Nov 2016 18:51:16 +0300 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <333189c9-10b1-2018-f53b-83cffaf2e481@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <333189c9-10b1-2018-f53b-83cffaf2e481@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8162350/webrev.02 The previous fix renders the dirty region to the backbuffer from the same (x, y) coordinates where it should be repainted. The JScrollPane can have large (x, y) values which can exceed the double buffer maximum size and some regions can be painted outside the backbuffer. The current fix tries to adjust the component translation to a value which allows to draw a component in the same way when floating point scale is used. The scale is converted to the irreducible fraction n / m where m is the step under which the component is drawn in the same way. The translation to the zero point is adjusted to the value: -translation + translation % m. The backbuffer is enlarged to the value: size + m. The floating point scale and general transform are handled differently because general transform requires calculation pixel values in general way, not just scale * x + translation. The integer and floating point scales are handed differently because the floating point scale handling now use % operator which can consume some time. Thanks, Alexandr. On 11/1/2016 11:23 PM, Jim Graham wrote: > Is SunGraphics2D accessible from Swing? If so, then I'd recommend > putting the isFPScale() method right on that class so we don't have to > clone the transform by calling g.getTransform(). Also note that > g.getTransform() does more than clone the transform as it has to > factor out the constrainXY translation - which are always integers so > it won't have any effect on the results of "isFPScale()" and is > additional wasted work. Eventually we could tie this into the > transformState variable in SG2D to differentiate integer and fp scale, > but that would take a little more work as those flags are used in a > lot of places - for now we can at least get rid of the transform clone > and the constraint translation processing. > > In the implementation of isFPScale(tx), do you really want to return > false for non-scale transforms? It seems to me that if the transform > has rotations or shears in it then we might need to punt and just > repaint the whole viewport. Also, you could simplify it a little to > avoid an extra "getter" and extra bit math: > > isFPScale(AffineTransform tx) { > int type = tx.getType() & ~(FLIP | TRANSLATE); > if (type == 0) { > return false; > } else if (type == SCALE) { > // check for integers > } else { > return true or false?; > } > } > > The changes to SG2D.drawHiDPIImage point out that we should probably > allow fp subimage paramters in the image pipeline for better accuracy, > but that's a much bigger change. Until then sub-image blits are not > going to be accurate on scaled images. Won't this inaccuracy affect > our back buffer blits in Swing? > > The changes to RepaintManager took me a couple of tries to figure out. > It looks like you are now rendering the dirty region at the > appropriate X,Y location in the back buffer (rather than at 0,0) in > all cases to adjust for the fact that rendering the same primitive at > different locations doesn't always match. First, you expand the back > buffer even for the unscaled case which wasn't affected by HiDPI. > Second, as long as the translate is in device pixels, it shouldn't > matter where in the buffer you render it, so it should be enough to > just ensure integer translations - did you try using an integer origin > for the rendering instead? > > ...jim > > On 10/24/2016 9:11 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8162350/webrev.01 >> - JScrollPane copy area functionality is disabled for floating >> point scale >> - VolatileImage buffer size is recalculates using transform translate >> >> Using floating point scale leads that drawing the same thing from >> different coordinates gives different results. For example filling a >> rectangle with size (1, 1) from location (0, 0) and UI scale 1.5 gives >> scaled region (0, 0, 1.5, 1.5) which is rounded to (0, 0, 2, 2). The >> same rectangle filled from the location (1, 1) gives the scaled region >> (1.5, 1.5, 3, 3) which is rounded to (2, 2, 3, 3). The first rectangle >> has size 2 in the device space and the second one has 1. >> As a result drawing a component from some coordinates and using >> Graphics.copyArea() to translate an image to a new location could have a >> differ results than just drawing the same component from the new >> location. >> The fix suggests to disable the JScrollPane area copying for floating >> point scales. >> >> Thanks, >> Alexandr. >> >> On 10/7/2016 4:30 PM, Alexandr Scherbatiy wrote: >>> On 10/6/2016 11:42 PM, Sergey Bylokhov wrote: >>>> Hi, Alexandr. >>>> Can you please provide some standalone small example, which emulates >>>> this artifacts via java2d API. (The pattern which we use in >>>> RepainManager). It will help to understand the problem. >>> >>> The code sample [1] draws two the same shapes (with different colors) >>> one after another into areas (x, y, w, h) and (x+w, y, w, h) >>> accordingly in different ways. >>> >>> The shape is constructed from the following parts: >>> 1. Fill clip area >>> - set clip (x, y, w, h) >>> - fill the whole image >>> As a result only clipped area is filled. >>> >>> 2. Fill rect >>> - fill rect(x, y, w, h) // big rect >>> - fill rect(x+1, y+1, w-2, h-2) // small rect >>> >>> 3. Draw center lines >>> - draw line (x, cy, x + w, cy) >>> - draw line (cx, y, cx, y + h) >>> >>> The program has the following options: >>> RECT - draw two shapes one after another from point (0, 0) >>> SHIFTED_RECT - draw two shapes one after another from point (x, y) >>> BACKBUFFER - draw the shape into a backbuffer with size (w, h) and >>> draw the backbuffer from the point (x, y) >>> SCALED_BACKBUFFER - draw the shape into a scaled backbuffer with >>> size (ceil(w*scale), ceil(h*scale)) with scaled graphics from point >>> (0, 0) and draw it into the rectangle (x, y, w, h) >>> ENLARGED_SCALED_BACKBUFFER - draw the shape into a scaled backbuffer >>> with size (ceil((x+w)*scale), ceil((y+h)*scale)) with scaled graphics >>> from point (x, y) and draw it into the rectangle (0, 0, x+w, y+h) >>> >>> The resulted images are placed in the directory [2]. >>> Directory name "rect-[7,5,10,8]" means that the rectangles (7,5,10,8) >>> was used for the shape drawing. >>> Each screenshot name follows the template " >>> screenshot-N-[x,y,w,h]-TYPE.png" where the type is a program option >>> used for the image generation. >>> Screenshots with suffix "-compare" compares the golden image (shape >>> drawn in to the rectangle (x, y, w, h)) with the generated image. The >>> golden image is on the top left side. The generated image is shown on >>> the right and bottom side. >>> >>> The RepaintManager has an assumption that drawing something in some >>> area (x, y, w, h) or just drawing the same thing into an image with >>> translated graphics g.translate(-x1, -y1) and drawing the image into >>> the area(x, y, w, h) has the the same result. >>> >>> As it is shown on screenshots this statement is not true for floating >>> point scales. >>> For example the same shape drawn from the point (0,0) and (x,y) look >>> differently (see [3] and [4]). >>> >>> The solution could be just to use an enlarged backbuffer with size >>> (x+w, y+h) with scaled graphics, draw the component into the rectangle >>> (x, y, w, h) and draw the backbuffer into the area (0,0, x+w, y+h). >>> Even the scaled enlarged backbuffer is used the results can be differ >>> (see [5] where the rectangle [7, 5, 11, 9] is used. The backbuffer is >>> drawn into bigger size). >>> >>> >>> [1] code samples: >>> http://cr.openjdk.java.net/~alexsch/8162350/code/00/Java2DFPSamples.java >>> >>> [2] dir with screenshots results: >>> http://cr.openjdk.java.net/~alexsch/8162350/results >>> [3] RECT: >>> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-01-%5b7%2c5%2c10%2c8%5d-rects.png >>> >>> [4] SHIFTED_RECT: >>> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-02-%5b7%2c5%2c10%2c8%5d-shifted-rects.png >>> >>> [5] ENLARGED_SCALED_BACKBUFFER compare: >>> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c11%2c9%5d/screenshot-05-%5b7%2c5%2c11%2c9%5d-enlarged-scaled-backbuffers-compare.png >>> >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 06.10.16 20:07, Alexandr Scherbatiy wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8162350 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8162350/webrev.00 >>>>> >>>>> The fix uses the solution suggest by Jim in the email: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007737.html >>>>> >>>>> >>>>> To draw to a VolatileImage backbuffer its graphics transform is >>>>> set to >>>>> identity and device coordinates are used to set the buffer clip. >>>>> Copying the backbuffer image to the graphics has some problems. >>>>> ------------- >>>>> // Since there is no drawImage(img, float x, float y)... >>>>> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >>>>> destination.drawImage(img, 0, 0) >>>>> ------------- >>>>> This code solves the problem for the top left corner of the region. >>>>> All Graphics.drawImage(...) methods scales the image size and it >>>>> looks >>>>> like ceil(img.getWidth() * scaleX) can be differ from the >>>>> ceil(pixelx1 + >>>>> img.getWidth() * scaleX) - pixelx1 so the right bottom corner of the >>>>> image does not fit the required point. >>>>> There is also a question could a line drawn from one point and then >>>>> from another has a different width in pixels because the graphics >>>>> scale >>>>> is not integer. >>>>> >>>>> The proposed fix prepares a backbuffer with size [x + w, y + h] >>>>> in a >>>>> user space and a component is drawn in to the region [pixelx1, >>>>> pixely1, >>>>> pixely2, pixely2] in the device space. >>>>> After that the necessary clip is set to the graphics and whole >>>>> image >>>>> is just drawn into it. >>>>> >>>>> The new logic is used only the component graphics configuration is >>>>> scaled the graphics configuration has the same scales. So it possible >>>>> just to copy the backbuffer surface data to the graphics surface >>>>> data. >>>>> For other cases like for rotated graphics transform it seems it is >>>>> necessary to have more complicated algorithm. >>>>> >>>>> This solves problems with repainted region but there are still >>>>> artifacts with JInternalFrame moving or a component scrolling, >>>>> This can >>>>> be related to the RepaintManager.copyArea() method which needs to be >>>>> updated in the similar way. I have created an issue on it: >>>>> JDK-8167305 RepaintManager.copyArea() method should be updated for >>>>> floating point UI scale >>>>> https://bugs.openjdk.java.net/browse/JDK-8167305 >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> From semyon.sadetsky at oracle.com Mon Nov 14 16:41:54 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 14 Nov 2016 19:41:54 +0300 Subject: [9] Review request for 8074883: Tab key should move to focused button in a button group In-Reply-To: <80642c14-c243-37df-0c4c-5e7fcf77f3eb@oracle.com> References: <28fd190a-c8dc-fb96-5010-22063186a7e3@oracle.com> <5a628ad3-edac-0b45-7c9e-840315e6d07f@oracle.com> <1aa50e8b-6ac3-9431-2bbc-fea5ec4754a8@oracle.com> <1ab82825-e9c4-5c68-c2bf-63018fb393e4@oracle.com>

<5aecaa3b-6fbc-e4a5-da09-d47de6c201bd@oracle.com> <44aeb9e7-92f0-45cb-bf75-06de3c612199@oracle.com> <80642c14-c243-37df-0c4c-5e7fcf77f3eb@oracle.com> Message-ID: <86049691-31c5-1744-6b03-de609e631b02@oracle.com> On 14.11.2016 16:24, Sergey Bylokhov wrote: > On 14.11.16 12:16, Semyon Sadetsky wrote: >>> But what about the question to specification, is it the spac below is >>> true when the selected toggle button is disabled?: >>> >>> 48 * If this toggle button is a member of the {@link ButtonGroup} >>> which has an another focusable toggle button selected, and the focus >>> cause argument denotes window activation or focus traversal action of >>> any direction the result of the method execution is the same as >>> calling {@link Component#requestFocus(FocusEvent.Cause)} on the toggle >>> button selected in the group. >>> >>> Because the current implementation filter out disabled components(the >>> same question is about invisible, non-displayable), but according to >>> the spec results should be the same like we call the method directly >>> on the selected button. >> Probably you missed my previous answer to this question: >> >> If a component is disabled it cannot receive input focus, see >> java.awt.Component#isEnabled specs. The proposed spec clearly states : >> >> 247 * If this toggle button is a member of the {@link ButtonGroup} >> which has >> 248 * an another ***focusable*** toggle button selected, and the >> focus cause argument >> >> in Swing a component may not receive focus if it is disabled, invisible, >> non-displayable... >> According to the spec the result will be the same if you call >> Component#requestFocus on ***this*** toggle button. > > It just confirms that the new spec is not complete, result of > "Component#requestFocus on ***this*** toggle button" will be different > from the result of "selected#requestFocus(FocusEvent.Cause)" if the > selected component is disabled. Because "Component#requestFocus on > ***this*** toggle button" will select "this", and > "selected#requestFocus(FocusEvent.Cause)" will select nothing. I did not get this. There two results of the call 1) selected.Component#requestFocus 2) this.Component#requestFocus. Of cause they are different. They cover 100% of outcome. "select nothing" is not mentioned in the spec. Is it really needed? > The property "***focusable***" is a defined in the > Component#isFocusable() and have nothing related to visibility, enable > state/etc. It will return true if component is disabled. I did not mean isFocusable property, but the general capability to get focus. The standard check for focusability is isVisible() && isDisplayable() && isEnabled() && isFocusable(). > >>> >>>>> >>>>>>> >>>>>> If a component is disabled it cannot receive input focus, see >>>>>> java.awt.Component#isEnabled specs. The proposed spec clearly >>>>>> states : >>>>>> >>>>>> 247 * If this toggle button is a member of the {@link >>>>>> ButtonGroup} >>>>>> which has >>>>>> 248 * an another ***focusable*** toggle button selected, >>>>>> and the >>>>>> focus cause argument >>>>>> >>>>>>> It seems that the code in getGroupSelection() will focus the first >>>>>>> element in the group, but what elements will be focused if we call >>>>>>> Component#requestFocus(FocusEvent.Cause) directly for this disabled >>>>>>> compoenent? Will the the same(first) element be selected? >>>>>> I did find any mentions of "first element" in the proposed spec. >>>>>> Please >>>>>> clarify this question. >>>>>> According to the proposed spec the case when >>>>>> Component#requestFocus(FocusEvent.Cause) is called on disabled >>>>>> component >>>>>> will be handled as: >>>>>> >>>>>> 253 * In all other cases the result of the method is the >>>>>> same as >>>>>> calling >>>>>> 254 * {@link Component#requestFocus(FocusEvent.Cause)} on this >>>>>> toggle button. >>>>> >>>>> The specification states that the call to >>>>> this.requestFocus(FocusEvent.Cause cause); >>>>> and the call to >>>>> selected.requestFocus(FocusEvent.Cause cause); >>>>> produce the same result "If this toggle button is a member of the >>>>> {@link ButtonGroup} which has an another focusable toggle button >>>>> selected, and the focus cause argument denotes window activation or >>>>> focus traversal action of any direction" >>>>> >>>>> The question was "is that always true if the selected element is >>>>> disabled(but focusable)"? I guess that the implementation in the fix >>>>> will select the first "this"(the button on which requestFocus() was >>>>> called), but in the second case something different will be selected. >>>>> >>>>>>>> On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote: >>>>>>>>> On 10/19/2016 8:14 PM, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review fix for JDK9: >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074883 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/ >>>>>>>>>> >>>>>>>>>> To avoid unexpected selection change the selected button of a >>>>>>>>>> button >>>>>>>>>> group should always grab focus when focus is transferred form >>>>>>>>>> component outside the group to any unselected button inside the >>>>>>>>>> group >>>>>>>>>> in case of traversal or initial container activation actions. >>>>>>>>> - It is better to pass the cause and boolean focusInWindow >>>>>>>>> arguments >>>>>>>>> to the getGroupSelection() method to avoid some code duplication >>>>>>>>> like >>>>>>>>> switching over the same cause values. >>>>>>>>> - The fix will require a CCC request because it updates a >>>>>>>>> javadoc >>>>>>>>> for the publci method. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Mon Nov 14 17:19:37 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 14 Nov 2016 20:19:37 +0300 Subject: RFR: 8169518: Suppress Deprecation warnings for deprecated Swing APIs In-Reply-To: <3412484c-3ea5-04dd-62c0-be66521acc6b@oracle.com> References: <3412484c-3ea5-04dd-62c0-be66521acc6b@oracle.com> Message-ID: The fix looks good to me. Thanks, Alexandr. On 11/10/2016 8:50 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8169518 > Webrev: http://cr.openjdk.java.net/~prr/8169518 > > The last set of deprecation warnings to be suppressed or fixed in > desktop - so > with this fix we can re-enable javac lint checking of deprecation. > > I have used JPRT to verify this builds on all platforms. > > -phil. > > From semyon.sadetsky at oracle.com Mon Nov 14 17:39:39 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 14 Nov 2016 20:39:39 +0300 Subject: RFR: 8169518: Suppress Deprecation warnings for deprecated Swing APIs In-Reply-To: References: <3412484c-3ea5-04dd-62c0-be66521acc6b@oracle.com> Message-ID: <99d7d20f-60cc-1ff1-b915-4601ba61acdf@oracle.com> +1 --Semyon On 14.11.2016 20:19, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 11/10/2016 8:50 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169518 >> Webrev: http://cr.openjdk.java.net/~prr/8169518 >> >> The last set of deprecation warnings to be suppressed or fixed in >> desktop - so >> with this fix we can re-enable javac lint checking of deprecation. >> >> I have used JPRT to verify this builds on all platforms. >> >> -phil. >> >> > From james.graham at oracle.com Mon Nov 14 22:48:19 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 14 Nov 2016 14:48:19 -0800 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <333189c9-10b1-2018-f53b-83cffaf2e481@oracle.com> Message-ID: Hi Alexandr, On 11/14/2016 7:51 AM, Alexandr Scherbatiy wrote: > The current fix tries to adjust the component translation to a value > which allows to draw a component in the same way when floating point > scale is used. > The scale is converted to the irreducible fraction n / m where m is > the step under which the component is drawn in the same way. > The translation to the zero point is adjusted to the value: > -translation + translation % m. > The backbuffer is enlarged to the value: size + m. Why not just ensure that you are translating by integer pixel amounts? That would work for any scale without add modulus calculations which still add slop to the amount of room you need in the buffer... ...jim From james.graham at oracle.com Mon Nov 14 23:44:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 14 Nov 2016 15:44:04 -0800 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> Message-ID: <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> I want to clarify the following issue... On 10/24/2016 9:11 AM, Alexandr Scherbatiy wrote: > Using floating point scale leads that drawing the same thing from > different coordinates gives different results. For example filling a > rectangle with size (1, 1) from location (0, 0) and UI scale 1.5 gives > scaled region (0, 0, 1.5, 1.5) which is rounded to (0, 0, 2, 2). The > same rectangle filled from the location (1, 1) gives the scaled region > (1.5, 1.5, 3, 3) which is rounded to (2, 2, 3, 3). The first rectangle > has size 2 in the device space and the second one has 1. First, while those primitives would be drawn in 2 different sizes, the first should be 1x1 and the second should be 2x2 if they follow our fill rules. Were you seeing something different? Still, the point you bring up about the two being 2 different sizes is acknowledged. Fill rule rounding for these rectangles should be "ceil(coordinate - 0.5)". Drawn with an integer translation of 0,0 (i.e. before scrolling operations or damage repair): scale = 1.5 translate = 0,0 in device pixels fillRect(0, 0, 1, 1) transforms to 0.0, 0.0, 1.5, 1.5 fills (0,0,1,1) covers 1x1 pixels fillRect(1, 1, 1, 1) transforms to 1.5, 1.5, 3.0, 3.0 fills (1,1,3,3) covers 2x2 pixels scale = 1.5 translate = 1,1 in device pixels fillRect(0, 0, 1, 1) transforms to 1.0, 1.0, 2.5, 2.5 fills (1,1,2,2) covers 1x1 pixels fillRect(1, 1, 1, 1) transforms to 2.5, 2.5, 4.0, 4.0 fills (2,2,4,4) covers 2x2 pixels No change in the relative sizes is observed. Now, if you are talking about an integer translation in user space, then there is a difference, as in: scale = 1.5 translate = 1,1 in user space = 1.5,1.5 in device space fillRect(0, 0, 1, 1) transforms to 1.5, 1.5, 3.0, 3.0 fills (1,1,3,3) covers 2x2 pixels fillRect(1, 1, 1, 1) transforms to 3.0, 3.0, 4.5, 4.5 fills (3,3,4,4) covers 1x1 pixels That can create a problem, but only if the translation is an integer distance in user space. If RepaintManager is applying integer distances in device space, then it should not affect the relative sizes of the rendered primitives. Were you seeing that happen? Because that would be a rendering bug in fillRect... ...jim > As a result drawing a component from some coordinates and using > Graphics.copyArea() to translate an image to a new location could have a > differ results than just drawing the same component from the new location. > The fix suggests to disable the JScrollPane area copying for floating > point scales. > > Thanks, > Alexandr. > > On 10/7/2016 4:30 PM, Alexandr Scherbatiy wrote: >> On 10/6/2016 11:42 PM, Sergey Bylokhov wrote: >>> Hi, Alexandr. >>> Can you please provide some standalone small example, which emulates >>> this artifacts via java2d API. (The pattern which we use in >>> RepainManager). It will help to understand the problem. >> >> The code sample [1] draws two the same shapes (with different colors) >> one after another into areas (x, y, w, h) and (x+w, y, w, h) >> accordingly in different ways. >> >> The shape is constructed from the following parts: >> 1. Fill clip area >> - set clip (x, y, w, h) >> - fill the whole image >> As a result only clipped area is filled. >> >> 2. Fill rect >> - fill rect(x, y, w, h) // big rect >> - fill rect(x+1, y+1, w-2, h-2) // small rect >> >> 3. Draw center lines >> - draw line (x, cy, x + w, cy) >> - draw line (cx, y, cx, y + h) >> >> The program has the following options: >> RECT - draw two shapes one after another from point (0, 0) >> SHIFTED_RECT - draw two shapes one after another from point (x, y) >> BACKBUFFER - draw the shape into a backbuffer with size (w, h) and >> draw the backbuffer from the point (x, y) >> SCALED_BACKBUFFER - draw the shape into a scaled backbuffer with >> size (ceil(w*scale), ceil(h*scale)) with scaled graphics from point >> (0, 0) and draw it into the rectangle (x, y, w, h) >> ENLARGED_SCALED_BACKBUFFER - draw the shape into a scaled backbuffer >> with size (ceil((x+w)*scale), ceil((y+h)*scale)) with scaled graphics >> from point (x, y) and draw it into the rectangle (0, 0, x+w, y+h) >> >> The resulted images are placed in the directory [2]. >> Directory name "rect-[7,5,10,8]" means that the rectangles (7,5,10,8) >> was used for the shape drawing. >> Each screenshot name follows the template " >> screenshot-N-[x,y,w,h]-TYPE.png" where the type is a program option >> used for the image generation. >> Screenshots with suffix "-compare" compares the golden image (shape >> drawn in to the rectangle (x, y, w, h)) with the generated image. The >> golden image is on the top left side. The generated image is shown on >> the right and bottom side. >> >> The RepaintManager has an assumption that drawing something in some >> area (x, y, w, h) or just drawing the same thing into an image with >> translated graphics g.translate(-x1, -y1) and drawing the image into >> the area(x, y, w, h) has the the same result. >> >> As it is shown on screenshots this statement is not true for floating >> point scales. >> For example the same shape drawn from the point (0,0) and (x,y) look >> differently (see [3] and [4]). >> >> The solution could be just to use an enlarged backbuffer with size >> (x+w, y+h) with scaled graphics, draw the component into the rectangle >> (x, y, w, h) and draw the backbuffer into the area (0,0, x+w, y+h). >> Even the scaled enlarged backbuffer is used the results can be differ >> (see [5] where the rectangle [7, 5, 11, 9] is used. The backbuffer is >> drawn into bigger size). >> >> >> [1] code samples: >> http://cr.openjdk.java.net/~alexsch/8162350/code/00/Java2DFPSamples.java >> [2] dir with screenshots results: >> http://cr.openjdk.java.net/~alexsch/8162350/results >> [3] RECT: >> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-01-%5b7%2c5%2c10%2c8%5d-rects.png >> [4] SHIFTED_RECT: >> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-02-%5b7%2c5%2c10%2c8%5d-shifted-rects.png >> [5] ENLARGED_SCALED_BACKBUFFER compare: >> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c11%2c9%5d/screenshot-05-%5b7%2c5%2c11%2c9%5d-enlarged-scaled-backbuffers-compare.png >> >> Thanks, >> Alexandr. >> >>> >>> On 06.10.16 20:07, Alexandr Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8162350 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8162350/webrev.00 >>>> >>>> The fix uses the solution suggest by Jim in the email: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007737.html >>>> >>>> To draw to a VolatileImage backbuffer its graphics transform is >>>> set to >>>> identity and device coordinates are used to set the buffer clip. >>>> Copying the backbuffer image to the graphics has some problems. >>>> ------------- >>>> // Since there is no drawImage(img, float x, float y)... >>>> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >>>> destination.drawImage(img, 0, 0) >>>> ------------- >>>> This code solves the problem for the top left corner of the region. >>>> All Graphics.drawImage(...) methods scales the image size and it looks >>>> like ceil(img.getWidth() * scaleX) can be differ from the >>>> ceil(pixelx1 + >>>> img.getWidth() * scaleX) - pixelx1 so the right bottom corner of the >>>> image does not fit the required point. >>>> There is also a question could a line drawn from one point and then >>>> from another has a different width in pixels because the graphics scale >>>> is not integer. >>>> >>>> The proposed fix prepares a backbuffer with size [x + w, y + h] in a >>>> user space and a component is drawn in to the region [pixelx1, pixely1, >>>> pixely2, pixely2] in the device space. >>>> After that the necessary clip is set to the graphics and whole image >>>> is just drawn into it. >>>> >>>> The new logic is used only the component graphics configuration is >>>> scaled the graphics configuration has the same scales. So it possible >>>> just to copy the backbuffer surface data to the graphics surface data. >>>> For other cases like for rotated graphics transform it seems it is >>>> necessary to have more complicated algorithm. >>>> >>>> This solves problems with repainted region but there are still >>>> artifacts with JInternalFrame moving or a component scrolling, This can >>>> be related to the RepaintManager.copyArea() method which needs to be >>>> updated in the similar way. I have created an issue on it: >>>> JDK-8167305 RepaintManager.copyArea() method should be updated for >>>> floating point UI scale >>>> https://bugs.openjdk.java.net/browse/JDK-8167305 >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Nov 15 10:49:35 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 15 Nov 2016 13:49:35 +0300 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> Message-ID: On 11/15/2016 2:44 AM, Jim Graham wrote: > I want to clarify the following issue... > > On 10/24/2016 9:11 AM, Alexandr Scherbatiy wrote: >> Using floating point scale leads that drawing the same thing from >> different coordinates gives different results. For example filling a >> rectangle with size (1, 1) from location (0, 0) and UI scale 1.5 gives >> scaled region (0, 0, 1.5, 1.5) which is rounded to (0, 0, 2, 2). The >> same rectangle filled from the location (1, 1) gives the scaled region >> (1.5, 1.5, 3, 3) which is rounded to (2, 2, 3, 3). The first rectangle >> has size 2 in the device space and the second one has 1. > > First, while those primitives would be drawn in 2 different sizes, the > first should be 1x1 and the second should be 2x2 if they follow our > fill rules. Were you seeing something different? Still, the point you > bring up about the two being 2 different sizes is acknowledged. Fill > rule rounding for these rectangles should be "ceil(coordinate - 0.5)". > > Drawn with an integer translation of 0,0 (i.e. before scrolling > operations or damage repair): > > scale = 1.5 > translate = 0,0 in device pixels > fillRect(0, 0, 1, 1) > transforms to 0.0, 0.0, 1.5, 1.5 > fills (0,0,1,1) > covers 1x1 pixels > fillRect(1, 1, 1, 1) > transforms to 1.5, 1.5, 3.0, 3.0 > fills (1,1,3,3) > covers 2x2 pixels > > scale = 1.5 > translate = 1,1 in device pixels > fillRect(0, 0, 1, 1) > transforms to 1.0, 1.0, 2.5, 2.5 > fills (1,1,2,2) > covers 1x1 pixels > fillRect(1, 1, 1, 1) > transforms to 2.5, 2.5, 4.0, 4.0 > fills (2,2,4,4) > covers 2x2 pixels > > No change in the relative sizes is observed. Now, if you are talking > about an integer translation in user space, then there is a > difference, as in: > > scale = 1.5 > translate = 1,1 in user space > = 1.5,1.5 in device space > fillRect(0, 0, 1, 1) > transforms to 1.5, 1.5, 3.0, 3.0 > fills (1,1,3,3) > covers 2x2 pixels > fillRect(1, 1, 1, 1) > transforms to 3.0, 3.0, 4.5, 4.5 > fills (3,3,4,4) > covers 1x1 pixels > > That can create a problem, but only if the translation is an integer > distance in user space. If RepaintManager is applying integer > distances in device space, then it should not affect the relative > sizes of the rendered primitives. > > Were you seeing that happen? Because that would be a rendering bug in > fillRect... Let's consider the following use case: scale = 1.5 A component calls fillRect(1, 1, 1, 1). This is (1.5, 1.5, 3.0, 3.0) in the device space which fills (1, 1, 3, 3) and covers 2x2 pixels Now the area (1, 1, 1, 1) needs to be repainted create a backbuffer translate(-1, -1) // move the top left corner of the area to the zero point draw the component into the backbuffer: fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, 1) -> after scaling (0.0, 0.0, 1.5, 1.5 ) in the device space which fills (0, 0, 1, 1) and covers 1x1 pixels Draw the backbuffer to the window at coordinates (1, 1) The rectangle with size 1x1 pixels is drawn instead of the 2x2 The result of translation, painting to the backbuffer and painting the backbuffer from the requested point can differ from just drawing from this point just because drawing from some point and drawing the same thing from the zero point can differ for the floating point scale. Thanks, Alexandr. > > ...jim > >> As a result drawing a component from some coordinates and using >> Graphics.copyArea() to translate an image to a new location could have a >> differ results than just drawing the same component from the new >> location. >> The fix suggests to disable the JScrollPane area copying for floating >> point scales. >> >> Thanks, >> Alexandr. >> >> On 10/7/2016 4:30 PM, Alexandr Scherbatiy wrote: >>> On 10/6/2016 11:42 PM, Sergey Bylokhov wrote: >>>> Hi, Alexandr. >>>> Can you please provide some standalone small example, which emulates >>>> this artifacts via java2d API. (The pattern which we use in >>>> RepainManager). It will help to understand the problem. >>> >>> The code sample [1] draws two the same shapes (with different colors) >>> one after another into areas (x, y, w, h) and (x+w, y, w, h) >>> accordingly in different ways. >>> >>> The shape is constructed from the following parts: >>> 1. Fill clip area >>> - set clip (x, y, w, h) >>> - fill the whole image >>> As a result only clipped area is filled. >>> >>> 2. Fill rect >>> - fill rect(x, y, w, h) // big rect >>> - fill rect(x+1, y+1, w-2, h-2) // small rect >>> >>> 3. Draw center lines >>> - draw line (x, cy, x + w, cy) >>> - draw line (cx, y, cx, y + h) >>> >>> The program has the following options: >>> RECT - draw two shapes one after another from point (0, 0) >>> SHIFTED_RECT - draw two shapes one after another from point (x, y) >>> BACKBUFFER - draw the shape into a backbuffer with size (w, h) and >>> draw the backbuffer from the point (x, y) >>> SCALED_BACKBUFFER - draw the shape into a scaled backbuffer with >>> size (ceil(w*scale), ceil(h*scale)) with scaled graphics from point >>> (0, 0) and draw it into the rectangle (x, y, w, h) >>> ENLARGED_SCALED_BACKBUFFER - draw the shape into a scaled backbuffer >>> with size (ceil((x+w)*scale), ceil((y+h)*scale)) with scaled graphics >>> from point (x, y) and draw it into the rectangle (0, 0, x+w, y+h) >>> >>> The resulted images are placed in the directory [2]. >>> Directory name "rect-[7,5,10,8]" means that the rectangles (7,5,10,8) >>> was used for the shape drawing. >>> Each screenshot name follows the template " >>> screenshot-N-[x,y,w,h]-TYPE.png" where the type is a program option >>> used for the image generation. >>> Screenshots with suffix "-compare" compares the golden image (shape >>> drawn in to the rectangle (x, y, w, h)) with the generated image. The >>> golden image is on the top left side. The generated image is shown on >>> the right and bottom side. >>> >>> The RepaintManager has an assumption that drawing something in some >>> area (x, y, w, h) or just drawing the same thing into an image with >>> translated graphics g.translate(-x1, -y1) and drawing the image into >>> the area(x, y, w, h) has the the same result. >>> >>> As it is shown on screenshots this statement is not true for floating >>> point scales. >>> For example the same shape drawn from the point (0,0) and (x,y) look >>> differently (see [3] and [4]). >>> >>> The solution could be just to use an enlarged backbuffer with size >>> (x+w, y+h) with scaled graphics, draw the component into the rectangle >>> (x, y, w, h) and draw the backbuffer into the area (0,0, x+w, y+h). >>> Even the scaled enlarged backbuffer is used the results can be differ >>> (see [5] where the rectangle [7, 5, 11, 9] is used. The backbuffer is >>> drawn into bigger size). >>> >>> >>> [1] code samples: >>> http://cr.openjdk.java.net/~alexsch/8162350/code/00/Java2DFPSamples.java >>> >>> [2] dir with screenshots results: >>> http://cr.openjdk.java.net/~alexsch/8162350/results >>> [3] RECT: >>> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-01-%5b7%2c5%2c10%2c8%5d-rects.png >>> >>> [4] SHIFTED_RECT: >>> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c10%2c8%5d/screenshot-02-%5b7%2c5%2c10%2c8%5d-shifted-rects.png >>> >>> [5] ENLARGED_SCALED_BACKBUFFER compare: >>> http://cr.openjdk.java.net/~alexsch/8162350/results/rect-%5b7%2c5%2c11%2c9%5d/screenshot-05-%5b7%2c5%2c11%2c9%5d-enlarged-scaled-backbuffers-compare.png >>> >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 06.10.16 20:07, Alexandr Scherbatiy wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8162350 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8162350/webrev.00 >>>>> >>>>> The fix uses the solution suggest by Jim in the email: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007737.html >>>>> >>>>> >>>>> To draw to a VolatileImage backbuffer its graphics transform is >>>>> set to >>>>> identity and device coordinates are used to set the buffer clip. >>>>> Copying the backbuffer image to the graphics has some problems. >>>>> ------------- >>>>> // Since there is no drawImage(img, float x, float y)... >>>>> destination.translate(pixelx1 / scaleX, pixely1 / scaleY) >>>>> destination.drawImage(img, 0, 0) >>>>> ------------- >>>>> This code solves the problem for the top left corner of the region. >>>>> All Graphics.drawImage(...) methods scales the image size and it >>>>> looks >>>>> like ceil(img.getWidth() * scaleX) can be differ from the >>>>> ceil(pixelx1 + >>>>> img.getWidth() * scaleX) - pixelx1 so the right bottom corner of the >>>>> image does not fit the required point. >>>>> There is also a question could a line drawn from one point and then >>>>> from another has a different width in pixels because the graphics >>>>> scale >>>>> is not integer. >>>>> >>>>> The proposed fix prepares a backbuffer with size [x + w, y + h] >>>>> in a >>>>> user space and a component is drawn in to the region [pixelx1, >>>>> pixely1, >>>>> pixely2, pixely2] in the device space. >>>>> After that the necessary clip is set to the graphics and whole >>>>> image >>>>> is just drawn into it. >>>>> >>>>> The new logic is used only the component graphics configuration is >>>>> scaled the graphics configuration has the same scales. So it possible >>>>> just to copy the backbuffer surface data to the graphics surface >>>>> data. >>>>> For other cases like for rotated graphics transform it seems it is >>>>> necessary to have more complicated algorithm. >>>>> >>>>> This solves problems with repainted region but there are still >>>>> artifacts with JInternalFrame moving or a component scrolling, >>>>> This can >>>>> be related to the RepaintManager.copyArea() method which needs to be >>>>> updated in the similar way. I have created an issue on it: >>>>> JDK-8167305 RepaintManager.copyArea() method should be updated for >>>>> floating point UI scale >>>>> https://bugs.openjdk.java.net/browse/JDK-8167305 >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> From alexandr.scherbatiy at oracle.com Tue Nov 15 13:49:46 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 15 Nov 2016 16:49:46 +0300 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D Message-ID: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8169719 webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 WrappedPlainView.modelToView() method is updated to use Utilities.getTabbedTextWidth() which returns floating point text width. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Tue Nov 15 14:08:04 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Nov 2016 17:08:04 +0300 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> Message-ID: <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> Should "@SuppressWarnings("deprecation")" be removed from this method? Why the test is linux and windows specific? On 15.11.16 16:49, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8169719 > webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 > > WrappedPlainView.modelToView() method is updated to use > Utilities.getTabbedTextWidth() which returns floating point text width. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Tue Nov 15 17:18:47 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 15 Nov 2016 20:18:47 +0300 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> Message-ID: <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> On 11/15/2016 5:08 PM, Sergey Bylokhov wrote: > Should "@SuppressWarnings("deprecation")" be removed from this method? > Why the test is linux and windows specific? Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8169719/webrev.01/ - "@SuppressWarnings("deprecation")"is removed The test is not suitable for Mac OS X because chars advances on Mac OS X have integer values. Thanks, Alexandr. > > On 15.11.16 16:49, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8169719 >> webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 >> >> WrappedPlainView.modelToView() method is updated to use >> Utilities.getTabbedTextWidth() which returns floating point text width. >> >> Thanks, >> Alexandr. >> > > From Sergey.Bylokhov at oracle.com Tue Nov 15 18:14:42 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Nov 2016 21:14:42 +0300 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> Message-ID: <81586edc-842a-3072-9040-efb374e1f1ef@oracle.com> On 15.11.16 20:18, Alexandr Scherbatiy wrote: > On 11/15/2016 5:08 PM, Sergey Bylokhov wrote: >> Should "@SuppressWarnings("deprecation")" be removed from this method? >> Why the test is linux and windows specific? > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8169719/webrev.01/ > - "@SuppressWarnings("deprecation")"is removed > > The test is not suitable for Mac OS X because chars advances on Mac OS > X have integer values. There is Solaris also, but as far as I understand the fractional chars text is a system/platform specifics and it is not necessary be so on some windows/linux? or it is always fractional? > > Thanks, > Alexandr. > >> >> On 15.11.16 16:49, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169719 >>> webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 >>> >>> WrappedPlainView.modelToView() method is updated to use >>> Utilities.getTabbedTextWidth() which returns floating point text width. >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Tue Nov 15 18:52:02 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Nov 2016 10:52:02 -0800 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> Message-ID: <94c4dd72-be72-6228-7e61-58e7362ed260@oracle.com> The assumption that just because values *can* be non-integral that they *will* be non-integral is not valid. Even if you know that the probability is small, it is not zero. This seems like it could lead to spurious failures of this test. -phil. On 11/15/2016 09:18 AM, Alexandr Scherbatiy wrote: > On 11/15/2016 5:08 PM, Sergey Bylokhov wrote: >> Should "@SuppressWarnings("deprecation")" be removed from this method? >> Why the test is linux and windows specific? > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8169719/webrev.01/ > - "@SuppressWarnings("deprecation")"is removed > > The test is not suitable for Mac OS X because chars advances on Mac > OS X have integer values. > > Thanks, > Alexandr. > >> >> On 15.11.16 16:49, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8169719 >>> webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 >>> >>> WrappedPlainView.modelToView() method is updated to use >>> Utilities.getTabbedTextWidth() which returns floating point text width. >>> >>> Thanks, >>> Alexandr. >>> >> >> > From alexandr.scherbatiy at oracle.com Tue Nov 15 20:32:33 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 15 Nov 2016 23:32:33 +0300 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <94c4dd72-be72-6228-7e61-58e7362ed260@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> <94c4dd72-be72-6228-7e61-58e7362ed260@oracle.com> Message-ID: <055a8e58-2193-3cc9-92ec-990ece6b39f4@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8169719/webrev.02 - The test is removed. Floating point values mean that the test passes but only integral values do not mean that the test fail. Thanks, Alexandr. On 11/15/2016 9:52 PM, Phil Race wrote: > The assumption that just because values *can* be non-integral that > they *will* be non-integral is not valid. Even if you know that the > probability is small, it is not zero. > > This seems like it could lead to spurious failures of this test. > > -phil. > > > On 11/15/2016 09:18 AM, Alexandr Scherbatiy wrote: >> On 11/15/2016 5:08 PM, Sergey Bylokhov wrote: >>> Should "@SuppressWarnings("deprecation")" be removed from this method? >>> Why the test is linux and windows specific? >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8169719/webrev.01/ >> - "@SuppressWarnings("deprecation")"is removed >> >> The test is not suitable for Mac OS X because chars advances on Mac >> OS X have integer values. >> >> Thanks, >> Alexandr. >> >>> >>> On 15.11.16 16:49, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169719 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 >>>> >>>> WrappedPlainView.modelToView() method is updated to use >>>> Utilities.getTabbedTextWidth() which returns floating point text >>>> width. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > From philip.race at oracle.com Tue Nov 15 20:51:50 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Nov 2016 12:51:50 -0800 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <055a8e58-2193-3cc9-92ec-990ece6b39f4@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> <94c4dd72-be72-6228-7e61-58e7362ed260@oracle.com> <055a8e58-2193-3cc9-92ec-990ece6b39f4@oracle.com> Message-ID: <15c5669c-60c1-32f0-f40d-25fac984e006@oracle.com> +1 -phil On 11/15/2016 12:32 PM, Alexandr Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8169719/webrev.02 > > - The test is removed. > > Floating point values mean that the test passes but only integral > values do not mean that the test fail. > > Thanks, > Alexandr. > > On 11/15/2016 9:52 PM, Phil Race wrote: >> The assumption that just because values *can* be non-integral that >> they *will* be non-integral is not valid. Even if you know that the >> probability is small, it is not zero. >> >> This seems like it could lead to spurious failures of this test. >> >> -phil. >> >> >> On 11/15/2016 09:18 AM, Alexandr Scherbatiy wrote: >>> On 11/15/2016 5:08 PM, Sergey Bylokhov wrote: >>>> Should "@SuppressWarnings("deprecation")" be removed from this method? >>>> Why the test is linux and windows specific? >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8169719/webrev.01/ >>> - "@SuppressWarnings("deprecation")"is removed >>> >>> The test is not suitable for Mac OS X because chars advances on >>> Mac OS X have integer values. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 15.11.16 16:49, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169719 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 >>>>> >>>>> WrappedPlainView.modelToView() method is updated to use >>>>> Utilities.getTabbedTextWidth() which returns floating point text >>>>> width. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> > From philip.race at oracle.com Tue Nov 15 22:33:49 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Nov 2016 14:33:49 -0800 Subject: RFR: 8167182: Exported elements referring to inaccessible types in jdk.accessibility Message-ID: <413f32f9-fe07-94c3-9b3a-8fbc0486411b@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8167182 Webrev: http://cr.openjdk.java.net/~prr/8167182/ There are three fields exposed in the accessibility docs which are of types that are not exported : http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AWTEventMonitor.html#awtListener http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/SwingEventMonitor.html#swingListener http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AccessibilityEventMonitor.html#accessibilityListener These fields are not intended for client use. The first has been deprecated since JDK 8 under https://bugs.openjdk.java.net/browse/JDK-8007499 and is not used by the implementation - and is documented as such. The other two are also package private types which external code could use only via enabling access using core reflection. Furthermore those types - which are nested classes - are commented as being only intended to be used inside the containing class. Since jigsaw (the module system) will make these fields wholly unusable, we should either remove them from the API, or promote them to public. Since the latter option was never intended or not useful, instead the fix is to (effectively) remove these fields by making them private. For the first it is more of a delete and rename but the result is the same. In addition, the 12 other fields updated in 8007499 and which are of public types are updated as being "forRemoval". They were deprecated in 8, but this signals a clear intention to remove these in JDK 10. A bug to do so will be filed once this webrev (and a CCC) are approved to proceed that way. These 12 "forRemoval"s are not strictly required in this fix but since the other (non-public) one is being removed it seems a good opportunity to do that too. A possibility exists to go even further and remove them immediately is theoretically available since they have already been deprecated for a major release and these are NOT "SE" APIs anyway - they are JDK scope utility classes. I am open to that if there are strong views for it and CCC will approve. -phil. From james.graham at oracle.com Tue Nov 15 22:43:01 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 15 Nov 2016 14:43:01 -0800 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> Message-ID: <4933101b-8bac-9c28-e0e7-325d17e5e13f@oracle.com> On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote: >> Were you seeing that happen? Because that would be a rendering bug in fillRect... > Let's consider the following use case: > scale = 1.5 > A component calls fillRect(1, 1, 1, 1). > This is (1.5, 1.5, 3.0, 3.0) in the device space > which fills (1, 1, 3, 3) and covers 2x2 pixels > > Now the area (1, 1, 1, 1) needs to be repainted Is that the area in device pixels or component scaled coordinates? > create a backbuffer > translate(-1, -1) // move the top left corner of the area to the zero point Are you calling translate(-1,-1) on a scaled graphics or on a graphics that has an identity transform set instead? > draw the component into the backbuffer: > fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, 1) -> after scaling (0.0, 0.0, 1.5, 1.5 ) in the > device space > which fills (0, 0, 1, 1) and covers 1x1 pixels That is true if you are using scaled translates that don't line up on pixel bounds. I am suggesting that the repaint code use only *INTEGER DEVICE PIXEL TRANSLATES* which don't have this problem... > Draw the backbuffer to the window at coordinates (1, 1) At (1, 1) in the device pixel coordinate space or the scaled component coordinate space? > The rectangle with size 1x1 pixels is drawn instead of the 2x2 It sounds like you were using scaled component coordinate space translations and blits which would cause the rendering to change. RepaintManager should only ever be using device pixel translates and do none of its set-up work in the scaled coordinate space. > The result of translation, painting to the backbuffer and painting the backbuffer from the requested point can differ > from just drawing from this point just because drawing from some point and drawing the same thing from the zero point > can differ for the floating point scale. They can only differ if you make the mistake of using scaled coordinate translations to manage dirty areas and scrolling... ...jim From james.graham at oracle.com Tue Nov 15 22:52:53 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 15 Nov 2016 14:52:53 -0800 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> Message-ID: <4ef3364d-c41b-0790-8eeb-b2b28d657761@oracle.com> Let me clarify something... On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote: > Let's consider the following use case: > scale = 1.5 > A component calls fillRect(1, 1, 1, 1). > This is (1.5, 1.5, 3.0, 3.0) in the device space > which fills (1, 1, 3, 3) and covers 2x2 pixels Agreed. > Now the area (1, 1, 1, 1) needs to be repainted > create a backbuffer > translate(-1, -1) // move the top left corner of the area to the zero point > draw the component into the backbuffer: > fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, 1) -> after scaling (0.0, 0.0, 1.5, 1.5 ) in the > device space > which fills (0, 0, 1, 1) and covers 1x1 pixels If you did g.setTransform(identity), g.translate(-1, -1), (then restore the scale) then the analysis is as follows: g.setTransform(identity) => [1 0 0] [0 1 0] g.translate(-1, -1) => [1 0 -1] [0 1 -1] g.scale(1.5, 1.5) => [1.5 0 -1] [0 1.5 -1] g.fillRect(1, 1, 1, 1) => coordinates are (1.5-1, 1.5-1, 3-1, 3-1) => (.5, .5, 2, 2) => fills (0, 0, 2, 2) => which covers 2x2 pixels If you did g.translate(-1, -1) on the scaled transform then the analysis is as follows: g.transform is [1.5 0 0] [0 1.5 0] g.translate(-1, -1) is [1.5 0 -1.5] [0 1.5 -1.5] g.fillRect(1, 1, 1, 1) => coordinates are (1.5-1.5, 1.5-1.5, 3-1.5, 3-1.5) => (0, 0, 1.5, 1.5) => fill (0, 0, 1, 1) => covers 1x1 pixels The second operation is what you are describing above and that would be an inappropriate way to perform damage repair because you used a scaled translation which did not result in an integer coordinate translation. Please re-read my previous analysis that shows what happens when you use integer device-pixel translations which are translations that happen using integers on a non-scaled transform. Note that you can add a scale *AFTER* you apply the integer device pixel translation and it will not affect the integer-ness of the translation. You can see above that the difference in how the translate command is issues affects where the translation components of the matrix end up being -1,-1 or -1.5,-1.5... ...jim From semyon.sadetsky at oracle.com Wed Nov 16 06:47:03 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 16 Nov 2016 09:47:03 +0300 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <15c5669c-60c1-32f0-f40d-25fac984e006@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> <94c4dd72-be72-6228-7e61-58e7362ed260@oracle.com> <055a8e58-2193-3cc9-92ec-990ece6b39f4@oracle.com> <15c5669c-60c1-32f0-f40d-25fac984e006@oracle.com> Message-ID: +1 --Semyon On 11/15/2016 11:51 PM, Phil Race wrote: > +1 > > -phil > > On 11/15/2016 12:32 PM, Alexandr Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8169719/webrev.02 >> >> - The test is removed. >> >> Floating point values mean that the test passes but only integral >> values do not mean that the test fail. >> >> Thanks, >> Alexandr. >> >> On 11/15/2016 9:52 PM, Phil Race wrote: >>> The assumption that just because values *can* be non-integral that >>> they *will* be non-integral is not valid. Even if you know that the >>> probability is small, it is not zero. >>> >>> This seems like it could lead to spurious failures of this test. >>> >>> -phil. >>> >>> >>> On 11/15/2016 09:18 AM, Alexandr Scherbatiy wrote: >>>> On 11/15/2016 5:08 PM, Sergey Bylokhov wrote: >>>>> Should "@SuppressWarnings("deprecation")" be removed from this >>>>> method? >>>>> Why the test is linux and windows specific? >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8169719/webrev.01/ >>>> - "@SuppressWarnings("deprecation")"is removed >>>> >>>> The test is not suitable for Mac OS X because chars advances on >>>> Mac OS X have integer values. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> On 15.11.16 16:49, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169719 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 >>>>>> >>>>>> WrappedPlainView.modelToView() method is updated to use >>>>>> Utilities.getTabbedTextWidth() which returns floating point text >>>>>> width. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Wed Nov 16 07:33:01 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 16 Nov 2016 10:33:01 +0300 Subject: RFR: 8167182: Exported elements referring to inaccessible types in jdk.accessibility In-Reply-To: <413f32f9-fe07-94c3-9b3a-8fbc0486411b@oracle.com> References: <413f32f9-fe07-94c3-9b3a-8fbc0486411b@oracle.com> Message-ID: <10e31f8a-213a-065e-d2c6-9377c1789ff2@oracle.com> +1 --Semyon On 11/16/2016 1:33 AM, Phil Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8167182 > Webrev: http://cr.openjdk.java.net/~prr/8167182/ > > There are three fields exposed in the accessibility docs which are of > types > that are not exported : > http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AWTEventMonitor.html#awtListener > > http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/SwingEventMonitor.html#swingListener > > http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AccessibilityEventMonitor.html#accessibilityListener > > > These fields are not intended for client use. > The first has been deprecated since JDK 8 under > https://bugs.openjdk.java.net/browse/JDK-8007499 > and is not used by the implementation - and is documented as such. > > The other two are also package private types which external code > could use only via enabling access using core reflection. > Furthermore those types - which are nested classes - are commented > as being only intended to be used inside the containing class. > > > Since jigsaw (the module system) will make these fields wholly unusable, > we should either remove them from the API, or promote them to public. > Since the latter option was never intended or not useful, instead > the fix is to (effectively) remove these fields by making them private. > For the first it is more of a delete and rename but the result is the > same. > > In addition, the 12 other fields updated in 8007499 and which are of > public types > are updated as being "forRemoval". They were deprecated in 8, but this > signals > a clear intention to remove these in JDK 10. A bug to do so will be > filed once > this webrev (and a CCC) are approved to proceed that way. > These 12 "forRemoval"s are not strictly required in this fix but since > the other (non-public) one is being removed it seems a good opportunity > to do that too. > A possibility exists to go even further and remove them immediately is > theoretically > available since they have already been deprecated for a major release and > these are NOT "SE" APIs anyway - they are JDK scope utility classes. > I am open to that if there are strong views for it and CCC will approve. > > -phil. > > > From prasanta.sadhukhan at oracle.com Wed Nov 16 09:38:22 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 16 Nov 2016 15:08:22 +0530 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails Message-ID: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> Hi All, Please review a simple fix for a swing issue where it is seen that a closed test was failing on Nimbus LaF Bug: https://bugs.openjdk.java.net/browse/JDK-7190578 webrev: http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.00/ This is is continuation to the closed review and this just moves the fixed test from closed to open. The failure was happening because Nimbus LAF#getDefaults() sets TitledBorder via LoweredBorder constructor which sets insets to 10 http://hg.openjdk.java.net/jdk9/client/jdk/file/a4d2db195b23/src/java.desktop/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java#l48 so we get a white border for Nimbus but other LAF, there is no default border set but the test checks for background color at a location (8,45) which falls within the white border. Proposed fix is to move the background location x position which needs to be tested by 15 pixels same as y so that we move out of the white border. This does not affect the test as the background is set outside the border. I intended to open this testcase so remove dependancy on Util library. I tested with other LAFs and it passed. Regards Prasanta From Sergey.Bylokhov at oracle.com Wed Nov 16 13:27:33 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Nov 2016 16:27:33 +0300 Subject: RFR: 8167182: Exported elements referring to inaccessible types in jdk.accessibility In-Reply-To: <413f32f9-fe07-94c3-9b3a-8fbc0486411b@oracle.com> References: <413f32f9-fe07-94c3-9b3a-8fbc0486411b@oracle.com> Message-ID: Looks fine. On 16.11.16 1:33, Phil Race wrote: > Bug : https://bugs.openjdk.java.net/browse/JDK-8167182 > Webrev: http://cr.openjdk.java.net/~prr/8167182/ > > There are three fields exposed in the accessibility docs which are of types > that are not exported : > http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AWTEventMonitor.html#awtListener > > http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/SwingEventMonitor.html#swingListener > > http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AccessibilityEventMonitor.html#accessibilityListener > > > These fields are not intended for client use. > The first has been deprecated since JDK 8 under > https://bugs.openjdk.java.net/browse/JDK-8007499 > and is not used by the implementation - and is documented as such. > > The other two are also package private types which external code > could use only via enabling access using core reflection. > Furthermore those types - which are nested classes - are commented > as being only intended to be used inside the containing class. > > > Since jigsaw (the module system) will make these fields wholly unusable, > we should either remove them from the API, or promote them to public. > Since the latter option was never intended or not useful, instead > the fix is to (effectively) remove these fields by making them private. > For the first it is more of a delete and rename but the result is the same. > > In addition, the 12 other fields updated in 8007499 and which are of > public types > are updated as being "forRemoval". They were deprecated in 8, but this > signals > a clear intention to remove these in JDK 10. A bug to do so will be > filed once > this webrev (and a CCC) are approved to proceed that way. > These 12 "forRemoval"s are not strictly required in this fix but since > the other (non-public) one is being removed it seems a good opportunity > to do that too. > A possibility exists to go even further and remove them immediately is > theoretically > available since they have already been deprecated for a major release and > these are NOT "SE" APIs anyway - they are JDK scope utility classes. > I am open to that if there are strong views for it and CCC will approve. > > -phil. > > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Nov 16 14:25:57 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Nov 2016 17:25:57 +0300 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> Message-ID: <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> It seems that the test has the main() method and ".html" file is not necessary? On 16.11.16 12:38, Prasanta Sadhukhan wrote: > I intended to open this testcase so remove dependancy on Util library. > I tested with other LAFs and it passed. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Nov 16 15:42:28 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 16 Nov 2016 21:12:28 +0530 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> Message-ID: Ok. Removed html file and updated test not to use JApplet. Please find the updated webrev http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.01/ Regards Prasanta On 11/16/2016 7:55 PM, Sergey Bylokhov wrote: > It seems that the test has the main() method and ".html" file is not > necessary? > > On 16.11.16 12:38, Prasanta Sadhukhan wrote: >> I intended to open this testcase so remove dependancy on Util library. >> I tested with other LAFs and it passed. > From Sergey.Bylokhov at oracle.com Wed Nov 16 15:52:19 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 Nov 2016 18:52:19 +0300 Subject: [9] Review request for 8169719 WrappedPlainView.modelToView() should return Rectangle2D In-Reply-To: <15c5669c-60c1-32f0-f40d-25fac984e006@oracle.com> References: <0604a933-6fea-f454-5d5a-cd1feff54f85@oracle.com> <590d1204-e4bb-bf18-48bb-ff97c752f1b3@oracle.com> <10d9da00-cd34-5cec-7761-e50b923b2666@oracle.com> <94c4dd72-be72-6228-7e61-58e7362ed260@oracle.com> <055a8e58-2193-3cc9-92ec-990ece6b39f4@oracle.com> <15c5669c-60c1-32f0-f40d-25fac984e006@oracle.com> Message-ID: Looks fine. On 15.11.16 23:51, Phil Race wrote: > +1 > > -phil > > On 11/15/2016 12:32 PM, Alexandr Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8169719/webrev.02 >> >> - The test is removed. >> >> Floating point values mean that the test passes but only integral >> values do not mean that the test fail. >> >> Thanks, >> Alexandr. >> >> On 11/15/2016 9:52 PM, Phil Race wrote: >>> The assumption that just because values *can* be non-integral that >>> they *will* be non-integral is not valid. Even if you know that the >>> probability is small, it is not zero. >>> >>> This seems like it could lead to spurious failures of this test. >>> >>> -phil. >>> >>> >>> On 11/15/2016 09:18 AM, Alexandr Scherbatiy wrote: >>>> On 11/15/2016 5:08 PM, Sergey Bylokhov wrote: >>>>> Should "@SuppressWarnings("deprecation")" be removed from this method? >>>>> Why the test is linux and windows specific? >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8169719/webrev.01/ >>>> - "@SuppressWarnings("deprecation")"is removed >>>> >>>> The test is not suitable for Mac OS X because chars advances on >>>> Mac OS X have integer values. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> On 15.11.16 16:49, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169719 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8169719/webrev.00 >>>>>> >>>>>> WrappedPlainView.modelToView() method is updated to use >>>>>> Utilities.getTabbedTextWidth() which returns floating point text >>>>>> width. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. From avik.niyogi at oracle.com Thu Nov 17 10:45:58 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Thu, 17 Nov 2016 16:15:58 +0530 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: <2E02C35E-E32F-45B4-A2AE-1D7407AFCAB2@oracle.com> References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com>

<12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com>

<8d86bcae-6f25-170a-82a3-0b1732621e52@oracle.com> <2E02C35E-E32F-45B4-A2AE-1D7407AFCAB2@oracle.com> Message-ID: Hi All, Please review the code changes made as suggested by reviewers for JDK9 as available for perusal in the link below http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/ With Regards, Avik Niyogi > On 14-Nov-2016, at 9:03 pm, Avik Niyogi wrote: > > If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works but for default settings on mac it is not working. > >> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov > wrote: >> >> On 14.11.16 17:18, Avik Niyogi wrote: >>> I checked with MetalLAF as well. does not seem to work. also, tried with a native Mac app. Does not have any option for radio button focus traversal. >> >> Can you please clarify how you set the L&F for this test? I also checked it and the test passed on the current jdk9-client in case of "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel" >> >>> >>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov > wrote: >>>> >>>> On 14.11.16 6:43, Avik Niyogi wrote: >>>>> This is OS X Specific. >>>> >>>> Are you sure? I guess the test will pass if will be run using MetalLookAndFeel. >>>> >>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov > wrote: >>>>>> >>>>>> On 10.11.16 9:53, Avik Niyogi wrote: >>>>>>> Arrow buttons for traversing a radio button group is not the expected OS X behaviour. >>>>>> >>>>>> This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? >>>>>> >>>>>>> In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov > wrote: >>>>>>>> >>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote: >>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>>>>>>>> >>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>>>>>>>> >>>>>>>>> *Issue: *The test case : >>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>>>>>>>> >>>>>>>>> *Cause: * The test case does not apply for OS X and should work for >>>>>>>>> windows and Linux >>>>>>>> >>>>>>>> What is the reason why the test does not work on OSX? >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Nov 17 17:31:12 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 Nov 2016 20:31:12 +0300 Subject: [9] Review Request: 8169900 The code which use Applets should be deprecated Message-ID: Hello. Please review the fix for jdk9. Some time ago the Applets were deprecated,see JEP-289[1]. After that the code which uses Applets were marked with "@SuppressWarnings("deprecation")"[2]. This is a request to deprecate such API in JavaBeans and in Swing. I also mark as deprecated the code which is related to AppletViewer(it is also deprecated[3]) [1] http://openjdk.java.net/jeps/289 [2] http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006788.html [3] https://bugs.openjdk.java.net/browse/JDK-8074165 Bug: https://bugs.openjdk.java.net/browse/JDK-8169900 Webrev can be found at: http://cr.openjdk.java.net/~serb/8169900/webrev.00 -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Nov 18 08:44:36 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 18 Nov 2016 14:14:36 +0530 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> Message-ID: <3d8c699e-32d7-263e-2bec-7b2eb9bedb6d@oracle.com> Any further objection on this? If not, can I get +1 ? Regards Prasanta On 11/16/2016 9:12 PM, Prasanta Sadhukhan wrote: > Ok. Removed html file and updated test not to use JApplet. Please find > the updated webrev > > http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.01/ > > > Regards > Prasanta > On 11/16/2016 7:55 PM, Sergey Bylokhov wrote: >> It seems that the test has the main() method and ".html" file is not >> necessary? >> >> On 16.11.16 12:38, Prasanta Sadhukhan wrote: >>> I intended to open this testcase so remove dependancy on Util library. >>> I tested with other LAFs and it passed. >> > From Sergey.Bylokhov at oracle.com Fri Nov 18 08:53:10 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Nov 2016 11:53:10 +0300 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: <3d8c699e-32d7-263e-2bec-7b2eb9bedb6d@oracle.com> References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> <3d8c699e-32d7-263e-2bec-7b2eb9bedb6d@oracle.com> Message-ID: <72763349-c88a-7f5b-4a09-08ad993a1cc7@oracle.com> On 18.11.16 11:44, Prasanta Sadhukhan wrote: > Any further objection on this? If not, can I get +1 ? It seems that there are some issues in the test: - The Swing components accessed on the main thread instead of EDT(JEditorPane,JFrame); - The JFrame should be disposed at the end of the test(when the test passed or failed). > > Regards > Prasanta > On 11/16/2016 9:12 PM, Prasanta Sadhukhan wrote: >> Ok. Removed html file and updated test not to use JApplet. Please find >> the updated webrev >> >> http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.01/ >> >> >> Regards >> Prasanta >> On 11/16/2016 7:55 PM, Sergey Bylokhov wrote: >>> It seems that the test has the main() method and ".html" file is not >>> necessary? >>> >>> On 16.11.16 12:38, Prasanta Sadhukhan wrote: >>>> I intended to open this testcase so remove dependancy on Util library. >>>> I tested with other LAFs and it passed. >>> >> > -- Best regards, Sergey. From ajit.ghaisas at oracle.com Fri Nov 18 09:07:49 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 18 Nov 2016 01:07:49 -0800 (PST) Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: <72763349-c88a-7f5b-4a09-08ad993a1cc7@oracle.com> References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> <3d8c699e-32d7-263e-2bec-7b2eb9bedb6d@oracle.com> <72763349-c88a-7f5b-4a09-08ad993a1cc7@oracle.com> Message-ID: <9e3f46f0-d4a3-4d62-8c6a-46e06a8e2d31@default> The test summary says that "Tests if background is correctly painted when has css margins" In test, -background-color: #cccccc - is set as CSS, but a negative check is made with Color.white to fail the test. I think, we can improve the test to check for color set in CSS and fail if it is not set. Regards, Ajit -----Original Message----- From: Sergey Bylokhov Sent: Friday, November 18, 2016 2:23 PM To: Prasanta Sadhukhan; Alexandr Scherbatiy; Avik Niyogi; swing-dev at openjdk.java.net Subject: Re: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails On 18.11.16 11:44, Prasanta Sadhukhan wrote: > Any further objection on this? If not, can I get +1 ? It seems that there are some issues in the test: - The Swing components accessed on the main thread instead of EDT(JEditorPane,JFrame); - The JFrame should be disposed at the end of the test(when the test passed or failed). > > Regards > Prasanta > On 11/16/2016 9:12 PM, Prasanta Sadhukhan wrote: >> Ok. Removed html file and updated test not to use JApplet. Please find >> the updated webrev >> >> http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.01/ >> >> >> Regards >> Prasanta >> On 11/16/2016 7:55 PM, Sergey Bylokhov wrote: >>> It seems that the test has the main() method and ".html" file is not >>> necessary? >>> >>> On 16.11.16 12:38, Prasanta Sadhukhan wrote: >>>> I intended to open this testcase so remove dependancy on Util library. >>>> I tested with other LAFs and it passed. >>> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Nov 18 09:44:14 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 18 Nov 2016 12:44:14 +0300 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <4ef3364d-c41b-0790-8eeb-b2b28d657761@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> <4ef3364d-c41b-0790-8eeb-b2b28d657761@oracle.com> Message-ID: <43d71670-cbe8-c46c-1f49-f33877a8c130@oracle.com> Thank you. I see that using the integer device-pixel translations preserves the component painting in the same way for floating point scales. Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8162350/webrev.03 - translation adjustment is removed - Region.clipRound() is used for pixels coordinates rounding. Thanks, Alexandr. On 11/16/2016 1:52 AM, Jim Graham wrote: > Let me clarify something... > > On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote: >> Let's consider the following use case: >> scale = 1.5 >> A component calls fillRect(1, 1, 1, 1). >> This is (1.5, 1.5, 3.0, 3.0) in the device space >> which fills (1, 1, 3, 3) and covers 2x2 pixels > > Agreed. > >> Now the area (1, 1, 1, 1) needs to be repainted >> create a backbuffer >> translate(-1, -1) // move the top left corner of the area to the >> zero point >> draw the component into the backbuffer: >> fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, 1) >> -> after scaling (0.0, 0.0, 1.5, 1.5 ) in the >> device space >> which fills (0, 0, 1, 1) and covers 1x1 pixels > > If you did g.setTransform(identity), g.translate(-1, -1), (then > restore the scale) then the analysis is as follows: > > g.setTransform(identity) => [1 0 0] [0 1 0] > g.translate(-1, -1) => [1 0 -1] [0 1 -1] > g.scale(1.5, 1.5) => [1.5 0 -1] [0 1.5 -1] > g.fillRect(1, 1, 1, 1) > => coordinates are (1.5-1, 1.5-1, 3-1, 3-1) > => (.5, .5, 2, 2) > => fills (0, 0, 2, 2) > => which covers 2x2 pixels > > If you did g.translate(-1, -1) on the scaled transform then the > analysis is as follows: > > g.transform is [1.5 0 0] [0 1.5 0] > g.translate(-1, -1) is [1.5 0 -1.5] [0 1.5 -1.5] > g.fillRect(1, 1, 1, 1) > => coordinates are (1.5-1.5, 1.5-1.5, 3-1.5, 3-1.5) > => (0, 0, 1.5, 1.5) > => fill (0, 0, 1, 1) > => covers 1x1 pixels > > The second operation is what you are describing above and that would > be an inappropriate way to perform damage repair because you used a > scaled translation which did not result in an integer coordinate > translation. > > Please re-read my previous analysis that shows what happens when you > use integer device-pixel translations which are translations that > happen using integers on a non-scaled transform. Note that you can > add a scale *AFTER* you apply the integer device pixel translation and > it will not affect the integer-ness of the translation. You can see > above that the difference in how the translate command is issues > affects where the translation components of the matrix end up being > -1,-1 or -1.5,-1.5... > > ...jim From prasanta.sadhukhan at oracle.com Fri Nov 18 11:11:04 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 18 Nov 2016 16:41:04 +0530 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: <9e3f46f0-d4a3-4d62-8c6a-46e06a8e2d31@default> References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> <3d8c699e-32d7-263e-2bec-7b2eb9bedb6d@oracle.com> <72763349-c88a-7f5b-4a09-08ad993a1cc7@oracle.com> <9e3f46f0-d4a3-4d62-8c6a-46e06a8e2d31@default> Message-ID: <81f197d4-64a5-ad61-596d-38a56b47eddb@oracle.com> Updated test to access swing component on EDT and dispose frame at end of test. Also, updated test to check background color (cccccc) and not white. But it seems robot.getPixelColor() gives a spurious color for the 1st location irrespective of what is the location, so used "match" variable so that if there is more matches (bg color equals to cccccc) then make test passed. http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.02/ Regards Prasanta On 11/18/2016 2:37 PM, Ajit Ghaisas wrote: > The test summary says that "Tests if background is correctly painted when has css margins" > In test, -background-color: #cccccc - is set as CSS, but a negative check is made with Color.white to fail the test. > I think, we can improve the test to check for color set in CSS and fail if it is not set. > > Regards, > Ajit > > > > -----Original Message----- > From: Sergey Bylokhov > Sent: Friday, November 18, 2016 2:23 PM > To: Prasanta Sadhukhan; Alexandr Scherbatiy; Avik Niyogi; swing-dev at openjdk.java.net > Subject: Re: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails > > On 18.11.16 11:44, Prasanta Sadhukhan wrote: >> Any further objection on this? If not, can I get +1 ? > It seems that there are some issues in the test: > - The Swing components accessed on the main thread instead of EDT(JEditorPane,JFrame); > - The JFrame should be disposed at the end of the test(when the test passed or failed). > >> Regards >> Prasanta >> On 11/16/2016 9:12 PM, Prasanta Sadhukhan wrote: >>> Ok. Removed html file and updated test not to use JApplet. Please find >>> the updated webrev >>> >>> http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.01/ >>> >>> >>> Regards >>> Prasanta >>> On 11/16/2016 7:55 PM, Sergey Bylokhov wrote: >>>> It seems that the test has the main() method and ".html" file is not >>>> necessary? >>>> >>>> On 16.11.16 12:38, Prasanta Sadhukhan wrote: >>>>> I intended to open this testcase so remove dependancy on Util library. >>>>> I tested with other LAFs and it passed. > From philip.race at oracle.com Fri Nov 18 18:08:25 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 18 Nov 2016 10:08:25 -0800 Subject: RFR: 8169887: javax/swing/JEditorPane/8080972/TestJEditor.java, javax/swing/text/View/8080972/TestObjectView.java are failing Message-ID: <8996fca0-c22b-618f-8f4b-f3bfb2c6fec4@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8169887 webrev : http://cr.openjdk.java.net/~prr/8169887/ 8155874 changed many calls from the deprecated Class.newInstance() to Class.getDeclaredConstructor().newInstance(). However in the cases where the called code may be loaded from a different class loader (ie app code) these are not equivalent and require a doPrivileged. The fix is to revert to Class.newInstance() for all cases where it is not obvious that we will only call code from within the same desktop module. This should be the lowest risk fix. Later (JDK10) we can revisit these. note that the change at line 473/474 in java/beans/PropertyDescriptor.java was actually a mistake ! I just noticed it and that is reverted to what it was before the first fix :- http://cr.openjdk.java.net/~prr/8155874/src/java.desktop/share/classes/java/beans/PropertyDescriptor.java.sdiff.html -phil From Sergey.Bylokhov at oracle.com Fri Nov 18 18:21:28 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Nov 2016 21:21:28 +0300 Subject: RFR: 8169887: javax/swing/JEditorPane/8080972/TestJEditor.java, javax/swing/text/View/8080972/TestObjectView.java are failing In-Reply-To: <8996fca0-c22b-618f-8f4b-f3bfb2c6fec4@oracle.com> References: <8996fca0-c22b-618f-8f4b-f3bfb2c6fec4@oracle.com> Message-ID: <28dfb5bc-c1e8-86d0-acb7-30631ec70d45@oracle.com> Looks fine. On 18.11.16 21:08, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8169887 > webrev : http://cr.openjdk.java.net/~prr/8169887/ > > 8155874 changed many calls from the deprecated Class.newInstance() > to Class.getDeclaredConstructor().newInstance(). > > However in the cases where the called code may be loaded from > a different class loader (ie app code) these are not equivalent > and require a doPrivileged. > > The fix is to revert to Class.newInstance() for all cases where it > is not obvious that we will only call code from within the same > desktop module. This should be the lowest risk fix. > > Later (JDK10) we can revisit these. > > > note that the change at line 473/474 in java/beans/PropertyDescriptor.java > was actually a mistake ! I just noticed it and that is reverted to what it > was before the first fix :- > http://cr.openjdk.java.net/~prr/8155874/src/java.desktop/share/classes/java/beans/PropertyDescriptor.java.sdiff.html > > > -phil -- Best regards, Sergey. From james.graham at oracle.com Fri Nov 18 20:23:50 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 18 Nov 2016 12:23:50 -0800 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <43d71670-cbe8-c46c-1f49-f33877a8c130@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com>

<8d86bcae-6f25-170a-82a3-0b1732621e52@oracle.com> <2E02C35E-E32F-45B4-A2AE-1D7407AFCAB2@oracle.com> Message-ID: <452EAF91-0FAF-433D-8EA9-0E06D1A877FF@oracle.com> A gentle reminder, please review the code changes done as per the inputs received from reviewers. Thanks in advance. With Regards, Avik Niyogi > On 17-Nov-2016, at 4:15 pm, Avik Niyogi wrote: > > Hi All, > Please review the code changes made as suggested by reviewers for JDK9 as available for perusal in the link below > http://cr.openjdk.java.net/~aniyogi/8167160/webrev.01/ > With Regards, > Avik Niyogi > > >> On 14-Nov-2016, at 9:03 pm, Avik Niyogi > wrote: >> >> If I use UIManager.setLookAndFeel() to metalLookAndFeel then it works but for default settings on mac it is not working. >> >>> On 14-Nov-2016, at 8:03 pm, Sergey Bylokhov > wrote: >>> >>> On 14.11.16 17:18, Avik Niyogi wrote: >>>> I checked with MetalLAF as well. does not seem to work. also, tried with a native Mac app. Does not have any option for radio button focus traversal. >>> >>> Can you please clarify how you set the L&F for this test? I also checked it and the test passed on the current jdk9-client in case of "-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel" >>> >>>> >>>>> On 14-Nov-2016, at 6:22 pm, Sergey Bylokhov > wrote: >>>>> >>>>> On 14.11.16 6:43, Avik Niyogi wrote: >>>>>> This is OS X Specific. >>>>> >>>>> Are you sure? I guess the test will pass if will be run using MetalLookAndFeel. >>>>> >>>>>>> On 14-Nov-2016, at 2:18 am, Sergey Bylokhov > wrote: >>>>>>> >>>>>>> On 10.11.16 9:53, Avik Niyogi wrote: >>>>>>>> Arrow buttons for traversing a radio button group is not the expected OS X behaviour. >>>>>>> >>>>>>> This behavior is OSX specific or it is related to the Aqua L&F which is default on OSX? >>>>>>> >>>>>>>> In OS X in default OS X apps, for radio button focus traversing to work, custom actions must be set using System Preferences. >>>>>>>>> On 09-Nov-2016, at 6:51 pm, Sergey Bylokhov > wrote: >>>>>>>>> >>>>>>>>> On 09.11.16 11:06, Avik Niyogi wrote: >>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8167160* >>>>>>>>>> >>>>>>>>>> *Webrev: http://cr.openjdk.java.net/~aniyogi/8167160/webrev.00/* >>>>>>>>>> >>>>>>>>>> *Issue: *The test case : >>>>>>>>>> javax/swing/JRadioButton/8033699/bug8033699.java fails on OS X >>>>>>>>>> >>>>>>>>>> *Cause: * The test case does not apply for OS X and should work for >>>>>>>>>> windows and Linux >>>>>>>>> >>>>>>>>> What is the reason why the test does not work on OSX? >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Nov 21 11:53:20 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 21 Nov 2016 17:23:20 +0530 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: <81f197d4-64a5-ad61-596d-38a56b47eddb@oracle.com> References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> <3d8c699e-32d7-263e-2bec-7b2eb9bedb6d@oracle.com> <72763349-c88a-7f5b-4a09-08ad993a1cc7@oracle.com> <9e3f46f0-d4a3-4d62-8c6a-46e06a8e2d31@default> <81f197d4-64a5-ad61-596d-38a56b47eddb@oracle.com> Message-ID: <0d38fc83-c20e-7743-8c76-71983ea83606@oracle.com> Any further feedback on this? Regards Prasanta On 11/18/2016 4:41 PM, Prasanta Sadhukhan wrote: > Updated test to access swing component on EDT and dispose frame at end > of test. > > Also, updated test to check background color (cccccc) and not white. > But it seems robot.getPixelColor() gives a spurious color for the 1st > location irrespective of what is the location, so used "match" > variable so that if there is more matches (bg color equals to cccccc) > then make test passed. > http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.02/ > > Regards > Prasanta > On 11/18/2016 2:37 PM, Ajit Ghaisas wrote: >> The test summary says that "Tests if background is correctly painted >> when has css margins" >> In test, -background-color: #cccccc - is set as CSS, but a negative >> check is made with Color.white to fail the test. >> I think, we can improve the test to check for color set in CSS and >> fail if it is not set. >> >> Regards, >> Ajit >> >> >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Friday, November 18, 2016 2:23 PM >> To: Prasanta Sadhukhan; Alexandr Scherbatiy; Avik Niyogi; >> swing-dev at openjdk.java.net >> Subject: Re: [9] RFR JDK-7190578: Nimbus: css test for >> 4936917 fails >> >> On 18.11.16 11:44, Prasanta Sadhukhan wrote: >>> Any further objection on this? If not, can I get +1 ? >> It seems that there are some issues in the test: >> - The Swing components accessed on the main thread instead of >> EDT(JEditorPane,JFrame); >> - The JFrame should be disposed at the end of the test(when the >> test passed or failed). >> >>> Regards >>> Prasanta >>> On 11/16/2016 9:12 PM, Prasanta Sadhukhan wrote: >>>> Ok. Removed html file and updated test not to use JApplet. Please find >>>> the updated webrev >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.01/ >>>> >>>> >>>> Regards >>>> Prasanta >>>> On 11/16/2016 7:55 PM, Sergey Bylokhov wrote: >>>>> It seems that the test has the main() method and ".html" file is not >>>>> necessary? >>>>> >>>>> On 16.11.16 12:38, Prasanta Sadhukhan wrote: >>>>>> I intended to open this testcase so remove dependancy on Util >>>>>> library. >>>>>> I tested with other LAFs and it passed. >> > From alexandr.scherbatiy at oracle.com Mon Nov 21 13:59:02 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 21 Nov 2016 16:59:02 +0300 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <70400080-9986-687e-4c26-513c9158a925@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> <4ef3364d-c41b-0790-8eeb-b2b28d657761@oracle.com> <43d71670-cbe8-c46c-1f49-f33877a8c130@oracle.com> <70400080-9986-687e-4c26-513c9158a925@oracle.com> Message-ID: <4071c36f-fd4f-ce3d-9f6b-6280da83f96a@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8162350/webrev.04 - isFloatingPointScale(AffineTransform) is moved from the SunGraphics2D to the SwingUtilities2 class. Thanks, Alexandr. On 11/18/2016 11:23 PM, Jim Graham wrote: > Hi ALexandr, > > This looks great. > > BTW, when I suggested moving the FPscale test into SG2D I was > suggesting that to avoid having to copy the transform out of it via > getTransform(), but you've found a different solution to that issue > (i.e. the new getTransform(g) method) so it no longer matters where > that utility static function is located. You can move it back to one > of the Swing classes. > > In terms of the logic of choosing which repaint function to use, it > looks like you use the old-style function if the scales don't match, > but won't that cause rendering anomalies? The new code is still an > improvement for the standard HiDPI case, and I'm guessing that > mismatched scales probably never tends to happen, but we might want to > flag it for further investigation. > > +1 relative to whether you want to move the FPscale test back out of > SG2D or not... > > ...jim > > On 11/18/16 1:44 AM, Alexandr Scherbatiy wrote: >> >> Thank you. I see that using the integer device-pixel translations >> preserves the component painting in the same way for >> floating point scales. >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8162350/webrev.03 >> >> - translation adjustment is removed >> - Region.clipRound() is used for pixels coordinates rounding. >> >> Thanks, >> Alexandr. >> >> On 11/16/2016 1:52 AM, Jim Graham wrote: >>> Let me clarify something... >>> >>> On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote: >>>> Let's consider the following use case: >>>> scale = 1.5 >>>> A component calls fillRect(1, 1, 1, 1). >>>> This is (1.5, 1.5, 3.0, 3.0) in the device space >>>> which fills (1, 1, 3, 3) and covers 2x2 pixels >>> >>> Agreed. >>> >>>> Now the area (1, 1, 1, 1) needs to be repainted >>>> create a backbuffer >>>> translate(-1, -1) // move the top left corner of the area to >>>> the zero point >>>> draw the component into the backbuffer: >>>> fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, >>>> 1) -> after scaling (0.0, 0.0, 1.5, 1.5 ) in the >>>> device space >>>> which fills (0, 0, 1, 1) and covers 1x1 pixels >>> >>> If you did g.setTransform(identity), g.translate(-1, -1), (then >>> restore the scale) then the analysis is as follows: >>> >>> g.setTransform(identity) => [1 0 0] [0 1 0] >>> g.translate(-1, -1) => [1 0 -1] [0 1 -1] >>> g.scale(1.5, 1.5) => [1.5 0 -1] [0 1.5 -1] >>> g.fillRect(1, 1, 1, 1) >>> => coordinates are (1.5-1, 1.5-1, 3-1, 3-1) >>> => (.5, .5, 2, 2) >>> => fills (0, 0, 2, 2) >>> => which covers 2x2 pixels >>> >>> If you did g.translate(-1, -1) on the scaled transform then the >>> analysis is as follows: >>> >>> g.transform is [1.5 0 0] [0 1.5 0] >>> g.translate(-1, -1) is [1.5 0 -1.5] [0 1.5 -1.5] >>> g.fillRect(1, 1, 1, 1) >>> => coordinates are (1.5-1.5, 1.5-1.5, 3-1.5, 3-1.5) >>> => (0, 0, 1.5, 1.5) >>> => fill (0, 0, 1, 1) >>> => covers 1x1 pixels >>> >>> The second operation is what you are describing above and that would >>> be an inappropriate way to perform damage repair >>> because you used a scaled translation which did not result in an >>> integer coordinate translation. >>> >>> Please re-read my previous analysis that shows what happens when you >>> use integer device-pixel translations which are >>> translations that happen using integers on a non-scaled transform. >>> Note that you can add a scale *AFTER* you apply >>> the integer device pixel translation and it will not affect the >>> integer-ness of the translation. You can see above >>> that the difference in how the translate command is issues affects >>> where the translation components of the matrix end >>> up being -1,-1 or -1.5,-1.5... >>> >>> ...jim >> From alexandr.scherbatiy at oracle.com Mon Nov 21 14:52:50 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 21 Nov 2016 17:52:50 +0300 Subject: RFR: 8169887: javax/swing/JEditorPane/8080972/TestJEditor.java, javax/swing/text/View/8080972/TestObjectView.java are failing In-Reply-To: <28dfb5bc-c1e8-86d0-acb7-30631ec70d45@oracle.com> References: <8996fca0-c22b-618f-8f4b-f3bfb2c6fec4@oracle.com> <28dfb5bc-c1e8-86d0-acb7-30631ec70d45@oracle.com> Message-ID: <2cd87851-02ec-e5a4-9a82-1e3827154a7f@oracle.com> The fix looks good to me. Thanks, Alexandr. On 11/18/2016 9:21 PM, Sergey Bylokhov wrote: > Looks fine. > > On 18.11.16 21:08, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169887 >> webrev : http://cr.openjdk.java.net/~prr/8169887/ >> >> 8155874 changed many calls from the deprecated Class.newInstance() >> to Class.getDeclaredConstructor().newInstance(). >> >> However in the cases where the called code may be loaded from >> a different class loader (ie app code) these are not equivalent >> and require a doPrivileged. >> >> The fix is to revert to Class.newInstance() for all cases where it >> is not obvious that we will only call code from within the same >> desktop module. This should be the lowest risk fix. >> >> Later (JDK10) we can revisit these. >> >> >> note that the change at line 473/474 in >> java/beans/PropertyDescriptor.java >> was actually a mistake ! I just noticed it and that is reverted to >> what it >> was before the first fix :- >> http://cr.openjdk.java.net/~prr/8155874/src/java.desktop/share/classes/java/beans/PropertyDescriptor.java.sdiff.html >> >> >> >> -phil > > From james.graham at oracle.com Mon Nov 21 19:27:11 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 21 Nov 2016 11:27:11 -0800 Subject: [9] Review request for 8162350 RepaintManager shifts repainted region when the floating point UI scale is used In-Reply-To: <4071c36f-fd4f-ce3d-9f6b-6280da83f96a@oracle.com> References: <88705586-0a68-10d2-ff88-de92f2a65ca4@oracle.com>

<8da8b3a8-1387-a309-715c-cebfdea8aded@oracle.com> <9d638874-75ad-6a2c-cce0-10dad221aef7@oracle.com> <4ef3364d-c41b-0790-8eeb-b2b28d657761@oracle.com> <43d71670-cbe8-c46c-1f49-f33877a8c130@oracle.com> <70400080-9986-687e-4c26-513c9158a925@oracle.com> <4071c36f-fd4f-ce3d-9f6b-6280da83f96a@oracle.com> Message-ID: <1a96ce94-203e-d573-298c-3cd657470674@oracle.com> Hi Alexandr, Looks fine. +1 ...jim On 11/21/16 5:59 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8162350/webrev.04 > > - isFloatingPointScale(AffineTransform) is moved from the SunGraphics2D to the SwingUtilities2 class. > > Thanks, > Alexandr. > > On 11/18/2016 11:23 PM, Jim Graham wrote: >> Hi ALexandr, >> >> This looks great. >> >> BTW, when I suggested moving the FPscale test into SG2D I was suggesting that to avoid having to copy the transform >> out of it via getTransform(), but you've found a different solution to that issue (i.e. the new getTransform(g) >> method) so it no longer matters where that utility static function is located. You can move it back to one of the >> Swing classes. >> >> In terms of the logic of choosing which repaint function to use, it looks like you use the old-style function if the >> scales don't match, but won't that cause rendering anomalies? The new code is still an improvement for the standard >> HiDPI case, and I'm guessing that mismatched scales probably never tends to happen, but we might want to flag it for >> further investigation. >> >> +1 relative to whether you want to move the FPscale test back out of SG2D or not... >> >> ...jim >> >> On 11/18/16 1:44 AM, Alexandr Scherbatiy wrote: >>> >>> Thank you. I see that using the integer device-pixel translations preserves the component painting in the same way for >>> floating point scales. >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8162350/webrev.03 >>> >>> - translation adjustment is removed >>> - Region.clipRound() is used for pixels coordinates rounding. >>> >>> Thanks, >>> Alexandr. >>> >>> On 11/16/2016 1:52 AM, Jim Graham wrote: >>>> Let me clarify something... >>>> >>>> On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote: >>>>> Let's consider the following use case: >>>>> scale = 1.5 >>>>> A component calls fillRect(1, 1, 1, 1). >>>>> This is (1.5, 1.5, 3.0, 3.0) in the device space >>>>> which fills (1, 1, 3, 3) and covers 2x2 pixels >>>> >>>> Agreed. >>>> >>>>> Now the area (1, 1, 1, 1) needs to be repainted >>>>> create a backbuffer >>>>> translate(-1, -1) // move the top left corner of the area to the zero point >>>>> draw the component into the backbuffer: >>>>> fillRect(1, 1, 1, 1) -> after translation fillRect(0, 0, 1, 1) -> after scaling (0.0, 0.0, 1.5, 1.5 ) in the >>>>> device space >>>>> which fills (0, 0, 1, 1) and covers 1x1 pixels >>>> >>>> If you did g.setTransform(identity), g.translate(-1, -1), (then restore the scale) then the analysis is as follows: >>>> >>>> g.setTransform(identity) => [1 0 0] [0 1 0] >>>> g.translate(-1, -1) => [1 0 -1] [0 1 -1] >>>> g.scale(1.5, 1.5) => [1.5 0 -1] [0 1.5 -1] >>>> g.fillRect(1, 1, 1, 1) >>>> => coordinates are (1.5-1, 1.5-1, 3-1, 3-1) >>>> => (.5, .5, 2, 2) >>>> => fills (0, 0, 2, 2) >>>> => which covers 2x2 pixels >>>> >>>> If you did g.translate(-1, -1) on the scaled transform then the analysis is as follows: >>>> >>>> g.transform is [1.5 0 0] [0 1.5 0] >>>> g.translate(-1, -1) is [1.5 0 -1.5] [0 1.5 -1.5] >>>> g.fillRect(1, 1, 1, 1) >>>> => coordinates are (1.5-1.5, 1.5-1.5, 3-1.5, 3-1.5) >>>> => (0, 0, 1.5, 1.5) >>>> => fill (0, 0, 1, 1) >>>> => covers 1x1 pixels >>>> >>>> The second operation is what you are describing above and that would be an inappropriate way to perform damage repair >>>> because you used a scaled translation which did not result in an integer coordinate translation. >>>> >>>> Please re-read my previous analysis that shows what happens when you use integer device-pixel translations which are >>>> translations that happen using integers on a non-scaled transform. Note that you can add a scale *AFTER* you apply >>>> the integer device pixel translation and it will not affect the integer-ness of the translation. You can see above >>>> that the difference in how the translate command is issues affects where the translation components of the matrix end >>>> up being -1,-1 or -1.5,-1.5... >>>> >>>> ...jim >>> > From Sergey.Bylokhov at oracle.com Mon Nov 21 22:28:46 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Nov 2016 01:28:46 +0300 Subject: [9] RFR JDK-7190578: Nimbus: css test for 4936917 fails In-Reply-To: <81f197d4-64a5-ad61-596d-38a56b47eddb@oracle.com> References: <5a4f1bde-289a-1e83-ca0a-721ce2463f63@oracle.com> <372dbf8b-65b1-d3a1-29db-03c0d88b4d66@oracle.com> <3d8c699e-32d7-263e-2bec-7b2eb9bedb6d@oracle.com> <72763349-c88a-7f5b-4a09-08ad993a1cc7@oracle.com> <9e3f46f0-d4a3-4d62-8c6a-46e06a8e2d31@default> <81f197d4-64a5-ad61-596d-38a56b47eddb@oracle.com> Message-ID: Hi, Prasanta Note that editorPane still accessed on non-EDT: .... blockTillDisplayed(editorPane); .... Point p = editorPane.getLocationOnScreen(); On 18.11.16 14:11, Prasanta Sadhukhan wrote: > Updated test to access swing component on EDT and dispose frame at end > of test. > > Also, updated test to check background color (cccccc) and not white. But > it seems robot.getPixelColor() gives a spurious color for the 1st > location irrespective of what is the location, so used "match" variable > so that if there is more matches (bg color equals to cccccc) then make > test passed. > http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.02/ > > Regards > Prasanta > On 11/18/2016 2:37 PM, Ajit Ghaisas wrote: >> The test summary says that "Tests if background is correctly painted >> when has css margins" >> In test, -background-color: #cccccc - is set as CSS, but a negative >> check is made with Color.white to fail the test. >> I think, we can improve the test to check for color set in CSS and >> fail if it is not set. >> >> Regards, >> Ajit >> >> >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: Friday, November 18, 2016 2:23 PM >> To: Prasanta Sadhukhan; Alexandr Scherbatiy; Avik Niyogi; >> swing-dev at openjdk.java.net >> Subject: Re: [9] RFR JDK-7190578: Nimbus: css test for >> 4936917 fails >> >> On 18.11.16 11:44, Prasanta Sadhukhan wrote: >>> Any further objection on this? If not, can I get +1 ? >> It seems that there are some issues in the test: >> - The Swing components accessed on the main thread instead of >> EDT(JEditorPane,JFrame); >> - The JFrame should be disposed at the end of the test(when the >> test passed or failed). >> >>> Regards >>> Prasanta >>> On 11/16/2016 9:12 PM, Prasanta Sadhukhan wrote: >>>> Ok. Removed html file and updated test not to use JApplet. Please find >>>> the updated webrev >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/7190578/webrev.01/ >>>> >>>> >>>> Regards >>>> Prasanta >>>> On 11/16/2016 7:55 PM, Sergey Bylokhov wrote: >>>>> It seems that the test has the main() method and ".html" file is not >>>>> necessary? >>>>> >>>>> On 16.11.16 12:38, Prasanta Sadhukhan wrote: >>>>>> I intended to open this testcase so remove dependancy on Util >>>>>> library. >>>>>> I tested with other LAFs and it passed. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Nov 21 22:31:11 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 Nov 2016 01:31:11 +0300 Subject: 8167160: [TEST_BUG][PIT] failure of javax/swing/JRadioButton/8033699/bug8033699.java In-Reply-To: References: <54F8E73A-9704-4C9B-A19B-03D448663D0A@oracle.com> <86cc1e3b-d22f-12c5-a6b9-db8b9246c341@oracle.com>

<12910FAC-7DC0-4A33-AA72-049361B2A380@oracle.com>