From alexandr.scherbatiy at oracle.com Thu Sep 1 08:25:45 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 1 Sep 2016 11:25:45 +0300 Subject: [9] Review request for 8164032 JViewport backing store image is not scaled on HiDPI display In-Reply-To: References: <061b9a2e-3fba-d26c-32a2-21db010cd292@oracle.com> <31edad12-a1aa-4d0d-5b0d-192f04ff9d84@oracle.com> <5a428d73-0d45-3794-61f2-f9f02337d180@oracle.com> <85fd32fb-fb34-414d-8905-721496666d19@oracle.com> Message-ID: Hi Sergey, According to your previous comments: - VolatileImage.validate(GraphicsConfiguration) does not return IMAGE_INCOMPATIBLE for a graphics configuration which default transform was changed. This is because the BufImgVolatileSurfaceManager has acceleration disabled and it skips check to the valid graphics configuration. I have filled an issue on it: JDK-8165212 VolatileImage is compatible with GraphicsConfiguration which transform is changed - JViewport.backingStoreImage field is protected so it is not possible to change its type. Moreover, it is not clear can a someone override JViewport and use backingStoreImage as a buffered image so he does not expect that the image content can be lost. Could we just file a new issue that the backing store image can be changed to VolatileImage in JViewport and return to discussion where graphics scale changing is checked: http://cr.openjdk.java.net/~alexsch/8164032/webrev.02 Thanks, Alexandr. On 8/30/2016 3:54 PM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8164032/webrev.04/ > > The Component.createVolatileImage() is used to create a backing store > volatile image. > > On 8/29/2016 4:18 PM, Sergey Bylokhov wrote: >> On 19.08.16 10:15, Alexandr Scherbatiy wrote: >>> On 8/18/2016 3:05 PM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.02 >>>> >>>> The backing store image is recreated for the case where scaled sizes >>>> are changed. >>> >>> A version where a VolatileImage is used as a backing store image: >>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.03/ >> >> The VI case looks simpler. I guess it can be simplified even more: >> Peobably this code is unnecessary? >> } else if (vImg instanceof SunVolatileImage) { >> 753 SunVolatileImage svImg = (SunVolatileImage) >> vImg; >> 754 if >> (!graphicsConfig.equals(svImg.getGraphicsConfig())) { >> 755 backingStoreImage = null; >> 756 } >> 757 } >> >> My understanding is that if VI.validate!=IMAGE_INCOMPATIBLE then we >> can use it for drawing even if the GC is different? > Different graphics configurations can have different default > transforms. The backing store image should be recreated in this case. > > Thanks, > Alexandr. >> Probably we can reuse Component.createVolatileImage() instead of >> createImage()? >> >> Also can you please check a performance of these two solutions? >> >> >>> >>> Thanks, >>> Alexandr. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/17/2016 5:05 PM, Sergey Bylokhov wrote: >>>>> On 17.08.16 14:02, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.01 >>>>>> >>>>>> The generic transform is used for the backing store image scaling. >>>>> >>>>> As far as I understand the current fix will not work if the scale was >>>>> changed(the JViewport will use old buffer)? >>>>> >>>>> It seems that the new local AbstractMultiResolutionImage contain only >>>>> one image variant inside and looks quite similar to the >>>>> VolatileImage, probably we can change this cache from BufferedImage >>>>> to VolatileImage? In this case the scale of the VI will be the same >>>>> as "g": >>>>> g.getDeviceConfiguration().createCompatibleVolatileImage() >>>>> >>>>> >>>>>> On 8/15/2016 4:58 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Alexandr. >>>>>>> I doubt that getScaleX/getScaleY can be used here because the scale >>>>>>> can be generic(translate+rotate+scale). How this cache will work if >>>>>>> transform will be changed after we save "backingStoreImage"? >>>>>>> >>>>>>> On 15.08.16 16:16, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8164032 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8164032/webrev.00 >>>>>>>> >>>>>>>> The fix scales the JViewport backing store image when graphics >>>>>>>> transform is not identity. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > From semyon.sadetsky at oracle.com Thu Sep 1 08:31:38 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 1 Sep 2016 11:31:38 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> Message-ID: <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> Hi Alexander, It is a good style to add a note recommending what to use instead of the method which is being deprecated. I did not get for what the useFloatingPointAPI property was introduced and moreover is set to false by default. If the old API is used then it doesn't matter which value it has because the float values will receive ints. And for the new API I would expect everything having the float precision, and it is unclear what may be the reason to switch it off back to integer. Especially if " This allows to draw text properly using graphics with scaled transform." so an improper mode is the default? --Semyon On 19.08.2016 11:03, Alexandr Scherbatiy wrote: > On 8/19/2016 2:25 AM, Philip Race wrote: >> OK .. I do not know enough about how modelToView is used by Swing >> to know what is really needed here. Someone with a bit more Swing >> background needs to chime in. I was encouraged that the *API* surface >> of the changes was much smaller than it had seemed from the webrev >> but maybe that is because you did not include everything. For example >> although they are just subclassing the method overrides in PasswordView >> since that is a public class would become part of the spec .. would >> they not ? >> Just like the "int" counterparts today :- >> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >> >> Put another way I was looking for what the content of the CCC would be. > Here is the updated version of the public API change which includes > overridden deprecated methods: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 > > Thanks, > Alexandr. >> >> -phil. >> >> >> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>> On 15/08/16 21:43, Phil Race wrote: >>>> Why is the caret support added in here ? Same for the modelToView >>>> That will just hold this up as the reasoning behind needing those >>>> changes is not something >>>> I have yet been able to convince myself about - even after reading >>>> your last email. >>> >>> The main change for the Caret public API (methods >>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D p)) >>> is not included in the current fix. I only moved the new methods >>> JTextComponent.modelToView2D(int pos)/viewToModel2D(Point2D pt) from >>> the fix for the Caret to this fix. These methods are used not only >>> for caret but in other cases like mouse handling, text dragging and >>> others. >>> >>> Thanks, >>> Alexandr. >>> >>> >>>> >>>> -phil. >>>> >>>> >>>> >>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix? >>>>> webrev which contains only change in public API: >>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>> webrev with contains all changes: >>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>> >>>>> - methods with int coordinates are deprecated >>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>> methods are added to the PlainView and WrappedPlainView classes >>>>> - JTextComponent.modelToView2D(int pos)/viewToModel2D(Point2D >>>>> pt) public methods from fix JDK-8163124 Add floating point API >>>>> support to javax.swing.text.Caret >>>>> are added >>>>> - some @implSpec descriptions are removed from the new text >>>>> drawing methods with floating point arguments >>>>> - Built-in L&Fs are updated to use floating point API in >>>>> standard Java text components >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> See comments inline. >>>>>> >>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>> I have a lot of doubts about this as well as trouble getting my >>>>>>> head around all of it. >>>>>>> >>>>>>> Given that apps need to 'buy in' to the floating point I am not >>>>>>> sure what we are gaining >>>>>>> but I need to make sure I understand the problem. >>>>>>> >>>>>>> It affects only the methods that the 3rd party code can over-ride >>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>> >>>>>>> There are just two protected methods that matter :- >>>>>>> PlainView.drawSelectedText(..) >>>>>>> and >>>>>>> PlainView.drawUnselectedText(..) >>>>>>> >>>>>>> The hidpi precison matters since they are drawing a sub-range of >>>>>>> the text. >>>>>>> Is there any other method that matters / is used in this way ? >>>>>> I have found the following methods which relate to text >>>>>> drawing, can be overridden and could have floating point coordinates: >>>>>> >>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>> >>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>> >>>>>> There is also a method which relates to a caret position in a text: >>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>> This requires additional investigation because DefaultCaret >>>>>> extends Rectangle and so its coordinates can't be float. >>>>>> >>>>>>> >>>>>>> Since 3rd party code is not over-riding these they will get the JDK >>>>>>> super-class version, thus losing any customisation they might >>>>>>> have done >>>>>>> in the no-longer-called int version. >>>>>>> >>>>>>> Assuming that is correct, what customisation would be lost and >>>>>>> how much does it matter? >>>>>> >>>>>> The example is javax.swing.text.PasswordView class which >>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) methods >>>>>> and draws echo chars instead of text. >>>>>> The similar can be done in a custom component: >>>>>> -------- >>>>>> public class CustomPasswordField extends FieldView { >>>>>> >>>>>> @Override >>>>>> protected int drawSelectedText(Graphics g, int x, int y, int >>>>>> p0, int p1) throws BadLocationException { >>>>>> // draw echo chars >>>>>> } >>>>>> } >>>>>> -------- >>>>>> >>>>>> Switching to support new methods with floating point coordinates >>>>>> will lead that real text will be shown for old applications in >>>>>> password fields. >>>>>>> >>>>>>> My prefernce is to deprecate the int versions and always call >>>>>>> the float versions >>>>>>> rather than the opt-in approach. >>>>>>> >>>>>>> Actually my real preference would be to come up with something >>>>>>> that does >>>>>>> not involve drawing the text in chunks like this. >>>>>>> >>>>>>> ie Swing should use AttributedCharacterIterator .. it looks like >>>>>>> the code to >>>>>>> do this might already be there ! >>>>>>> >>>>>>> 106 private float drawElement(int lineIndex, Element elem, >>>>>>> Graphics g, >>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>> 108 throws BadLocationException >>>>>>> 109 { >>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>> 113 >>>>>>> 114 if (lineIndex == 0) { >>>>>>> 115 x += firstLineOffset; >>>>>>> 116 } >>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>> 119 g.setColor(unselected); >>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>> 121 p0-elem.getStartOffset(), >>>>>>> 122 p1-elem.getStartOffset()); >>>>>>> 123 } else { >>>>>>> >>>>>>> In fact what *that* illustrates is that applications already >>>>>>> cannot expect >>>>>>> their over-ridden methods to be called, so this fix is trying to >>>>>>> fix something >>>>>>> that can't be fixed. >>>>>> The javadoc for the "protected PlainView.drawLine(...)" method is: >>>>>> --------- >>>>>> /** >>>>>> * Renders a line of text, suppressing whitespace at the end >>>>>> * and expanding any tabs. This is implemented to make calls >>>>>> * to the methods {@code drawUnselectedText} and >>>>>> * {@code drawSelectedText} so that the way selected and >>>>>> * unselected text are rendered can be customized. >>>>>> --------- >>>>>> >>>>>> Applications can rely on this behaviour and stopping to call the >>>>>> drawSelectedText(...)/drawUnselectedText(...) methods with int >>>>>> coordinates will be incompatible change. >>>>>> >>>>>>> >>>>>>> So why can't we do that ? Just deprecate those int methods, >>>>>>> don't add >>>>>>> the float methods and use ACI .. >>>>>> New float methods allow to easily migrate on new API for >>>>>> applications without significant changes. >>>>>> >>>>>>> BTW getTabSize() is supposed to be a character count isn't it ? >>>>>>> Not a pixel >>>>>>> count. So why does it need a float version. >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>> >>>>>> - methods with int coordinates which can be overridden are >>>>>> deprecated >>>>>> - getFractionalTabSize() method is removed >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> -phil >>>>>>> >>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>> Suppose an application is only partially fixed to use/override >>>>>>>>> the floating point methods. Perhaps it uses a library that has >>>>>>>>> not been fixed. >>>>>>>>> >>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>> >>>>>>>> Here is a slightly updated version which adds public >>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to the >>>>>>>> PlainView and WrappedPlainView classes: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>> >>>>>>>> Using the floating point API is disabled by default and >>>>>>>> enabled for standard Swing text component classes. This has >>>>>>>> advantage that selection will work for text component in users >>>>>>>> applications on HiDPI display. >>>>>>>> >>>>>>>> But it still has the same problem. Applications which use >>>>>>>> custom View classes needs to updated them to implement >>>>>>>> corresponding text drawing methods with floating point >>>>>>>> arguments and enable the floating point API usage. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> Alan >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I tried to merge this fix with the 8132119 Provide public >>>>>>>>>> API for text related methods in SwingUtilities2 >>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>> >>>>>>>>>> For each method that uses integer coordinates the fix adds a >>>>>>>>>> pair with floating point arguments. >>>>>>>>>> The fix 8156217 uses only methods with floating point values >>>>>>>>>> to correctly handle a selected text. >>>>>>>>>> This leads that overridden method with integer arguments in >>>>>>>>>> user code is not called anymore. >>>>>>>>>> >>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>> - Add a property that enables to use methods with floating >>>>>>>>>> point arguments in Swing. >>>>>>>>>> By default it is false and all work as before. The issue >>>>>>>>>> with selected text is reproduced. >>>>>>>>>> An application with enabled property does not have issue >>>>>>>>>> with the selected text but a user should override >>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>> corresponding methods with integer values. >>>>>>>>>> >>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>> >>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image rendering for >>>>>>>>>> HiDPI displays >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> I tried to look deeper in the code and it seems there is a >>>>>>>>>>>> rounding issue when float values are summed up. >>>>>>>>>>>> >>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the 'a' char >>>>>>>>>>>> advance is 10 in a dev space. >>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 as >>>>>>>>>>>> double value and 6.6666665 when it is cast to float in user >>>>>>>>>>>> space. >>>>>>>>>>>> The width of a string which consists of 15 'a' chars is 15 >>>>>>>>>>>> * 6.6666665 = 100.000000. >>>>>>>>>>>> But the same width calculated as sum of each glyph advance >>>>>>>>>>>> in StandardGlyphVector.initPositions() method is 99.999992. >>>>>>>>>>>> -------------- >>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>> int N = 15; >>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N * >>>>>>>>>>>> advance); >>>>>>>>>>>> float sum = 0; >>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>> sum += advance; >>>>>>>>>>>> } >>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>> -------------- >>>>>>>>>>>> >>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>> 99.999998 is shifted one pixel left which affects the text >>>>>>>>>>>> selection code in Swing: >>>>>>>>>>>> ------------------------ >>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); // >>>>>>>>>>>> non-selected text >>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), >>>>>>>>>>>> x + selectedTextPosition, y); // selected text is shifted >>>>>>>>>>>> to one pixel left >>>>>>>>>>>> ------------------------ >>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>> If the graphics has scale 1.5 and zero translate the >>>>>>>>>>> transformed coordinates are: >>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>> >>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>> >>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to one >>>>>>>>>>> pixel left >>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>> >>>>>>>>>>> A position 99.999992 in user space is rounded to 151 in dev >>>>>>>>>>> space. >>>>>>>>>>> A position 100.000000 in user space is rounded to 152 in >>>>>>>>>>> dev space. >>>>>>>>>>> >>>>>>>>>>> And this difference can depend on the translate even it has >>>>>>>>>>> integer value in user space because it is multiplied on the >>>>>>>>>>> graphics scale. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I applied this and it is *much* better but there still >>>>>>>>>>>>>> seem to be some tiny quirks. >>>>>>>>>>>>>> When I drag the mouse to select text down and then up >>>>>>>>>>>>>> again, as I pass the >>>>>>>>>>>>>> original mouse click point vertically, repaint seem to >>>>>>>>>>>>>> jiggle vertically by a pixel. >>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>> the target y. I think I may see the same in left/right >>>>>>>>>>>>>> dragging along a line too. >>>>>>>>>>>>>> So I think this is repaint and not text related. Can you >>>>>>>>>>>>>> take a look. >>>>>>>>>>>>> >>>>>>>>>>>>> I am able to reproduce this only using a floating >>>>>>>>>>>>> point scale. >>>>>>>>>>>>> It looks like 2d issue. I used a test which draws a >>>>>>>>>>>>> text in two pieces. The second piece of the text is >>>>>>>>>>>>> shifted from the first piece by the floating point size of >>>>>>>>>>>>> the the first piece of the text. >>>>>>>>>>>>> ----------- >>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>>>>>>>>> selectedTextPosition, y); >>>>>>>>>>>>> ----------- >>>>>>>>>>>>> >>>>>>>>>>>>> The second piece of the text can be shifted in the 2 cases: >>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>>>>>>>> >>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing position >>>>>>>>>>>>> and with float pointing scale is shifted >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is the second part of the fix related to the fact >>>>>>>>>>>>>>> that char width can be fractional in user space. >>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used for the >>>>>>>>>>>>>>> fractional string width calculation by Swing in user space. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Sep 1 11:21:18 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 1 Sep 2016 14:21:18 +0300 Subject: [9] Review request for 8160160: The menu displayed nothing with the option"-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". In-Reply-To: <9abb3797-a7c2-34d7-3a26-0df4f9df5f17@oracle.com> References: <18da8062-6386-bc91-b146-0c03329c6f83@oracle.com> <21e7f336-570d-4898-4dbf-00e945ce377a@oracle.com> <9abb3797-a7c2-34d7-3a26-0df4f9df5f17@oracle.com> Message-ID: <06069937-3447-85ee-27e2-fb8429f08bb6@oracle.com> The proposed variant is better because if WM effects are switched off we will receive this bug again. On 8/31/2016 10:29 PM, Sergey Bylokhov wrote: > Did you try to force HW popups for GTK l&f? The current proposal will > lead to the situation when popup will have different border depending > on location in/out of the frame. > > On 31.08.16 10:54, Semyon Sadetsky wrote: >> Hi Sergey, >> >> This is a valid concern. The fix is updated: >> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.02/ >> >> --Semyon >> >> >> On 8/30/2016 11:10 PM, Sergey Bylokhov wrote: >>> Hi, Semyon. >>> I suggest to double check the HW menu/popups, they should have the >>> correct border, because they should use the top level window, which >>> should contains correct shadow effect. Note that after the fix we >>> should not have two borers in such cases. >>> >>> On 29.08.16 20:11, Alexandr Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/29/2016 7:08 PM, Semyon Sadetsky wrote: >>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.01/ >>>>> >>>>> return type of ENGINE.finishPainting() changed to Buffered image. >>>>> >>>>> img.getRGB() returns a primitive not an object. >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 8/29/2016 3:45 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> >>>>>> On 8/29/2016 1:12 PM, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review fix for JDK9: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.00/ >>>>>>> >>>>>>> The menu border is not painted by GTK Adwaita theme and makes popup >>>>>>> menu invisible at some circumstances. To resolve this the GTK menu >>>>>>> border color is compared to the menu background color and if the >>>>>>> same the border is painted by means of java graphics using a bit >>>>>>> different color tone. >>>>>> - BufferedImage img = (BufferedImage) ENGINE.finishPainting(); >>>>>> if the ENGINE.finishPainting() always returns BufferedImage it >>>>>> would be better to change the return type to BufferedImage. >>>>>> >>>>>> - border == img.getRGB(w / 2, h / 2) >>>>>> Could we rely on that img.getRGB(0, h / 2) returns the same object >>>>>> as the img.getRGB(w / 2, h / 2)? May be it is use equals() methods >>>>>> for comparing in this case. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Thu Sep 1 12:07:33 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 1 Sep 2016 15:07:33 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> Message-ID: On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: > > Hi Alexander, > > It is a good style to add a note recommending what to use instead of > the method which is being deprecated. > Could you review the updated public API there "replaced by" notes are added to the deprecated methods: http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 > > I did not get for what the useFloatingPointAPI property was introduced > and moreover is set to false by default. If the old API is used then > it doesn't matter which value it has because the float values will > receive ints. And for the new API I would expect everything having the > float precision, and it is unclear what may be the reason to switch it > off back to integer. Especially if > > " This allows to draw text properly using graphics with scaled transform." > > so an improper mode is the default? > This is has been discussed below. For example new drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) with floating point coordinates is added to the PlainView which has the same method with int coordinates. Suppose someone has a custom password component which uses and old methods with int coordinates. -------- public class CustomPasswordField extends FieldView { @Override protected int drawSelectedText(Graphics g, int x, int y, int p0, int p1) throws BadLocationException { // draw echo chars } } -------- If we start to call drawSelectedText() with floating point values the customization of old components will not be used and the CustomPasswordField from the example starts to show real text instead of echo chars. This is incompatible change with previous JDK releases. The solution is to switch to new floating point API only when it is known that a component properly overrides new methods with floating point arguments. After that the PlainView.useFloatingPointAPI flag can be set to true. For example, BasicPasswordFieldUI sets the PasswordView.useFloatingPointAPI flag to true because it is sure that drawSelectedText() methods with floating point arguments is overridden. So Swing standard text components are switched to use new floating point API. Thanks, Alexandr. > --Semyon > > > On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >> On 8/19/2016 2:25 AM, Philip Race wrote: >>> OK .. I do not know enough about how modelToView is used by Swing >>> to know what is really needed here. Someone with a bit more Swing >>> background needs to chime in. I was encouraged that the *API* surface >>> of the changes was much smaller than it had seemed from the webrev >>> but maybe that is because you did not include everything. For example >>> although they are just subclassing the method overrides in PasswordView >>> since that is a public class would become part of the spec .. would >>> they not ? >>> Just like the "int" counterparts today :- >>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>> >>> Put another way I was looking for what the content of the CCC would be. >> Here is the updated version of the public API change which >> includes overridden deprecated methods: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >> >> Thanks, >> Alexandr. >>> >>> -phil. >>> >>> >>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>> On 15/08/16 21:43, Phil Race wrote: >>>>> Why is the caret support added in here ? Same for the modelToView >>>>> That will just hold this up as the reasoning behind needing those >>>>> changes is not something >>>>> I have yet been able to convince myself about - even after reading >>>>> your last email. >>>> >>>> The main change for the Caret public API (methods >>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D p)) >>>> is not included in the current fix. I only moved the new methods >>>> JTextComponent.modelToView2D(int pos)/viewToModel2D(Point2D pt) >>>> from the fix for the Caret to this fix. These methods are used not >>>> only for caret but in other cases like mouse handling, text >>>> dragging and others. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>>> >>>>> -phil. >>>>> >>>>> >>>>> >>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix? >>>>>> webrev which contains only change in public API: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>> webrev with contains all changes: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>> >>>>>> - methods with int coordinates are deprecated >>>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>> methods are added to the PlainView and WrappedPlainView classes >>>>>> - JTextComponent.modelToView2D(int pos)/viewToModel2D(Point2D >>>>>> pt) public methods from fix JDK-8163124 Add floating point API >>>>>> support to javax.swing.text.Caret >>>>>> are added >>>>>> - some @implSpec descriptions are removed from the new text >>>>>> drawing methods with floating point arguments >>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>> standard Java text components >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> See comments inline. >>>>>>> >>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>> I have a lot of doubts about this as well as trouble getting my >>>>>>>> head around all of it. >>>>>>>> >>>>>>>> Given that apps need to 'buy in' to the floating point I am not >>>>>>>> sure what we are gaining >>>>>>>> but I need to make sure I understand the problem. >>>>>>>> >>>>>>>> It affects only the methods that the 3rd party code can over-ride >>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>> >>>>>>>> There are just two protected methods that matter :- >>>>>>>> PlainView.drawSelectedText(..) >>>>>>>> and >>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>> >>>>>>>> The hidpi precison matters since they are drawing a sub-range >>>>>>>> of the text. >>>>>>>> Is there any other method that matters / is used in this way ? >>>>>>> I have found the following methods which relate to text >>>>>>> drawing, can be overridden and could have floating point >>>>>>> coordinates: >>>>>>> >>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>> >>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>> >>>>>>> There is also a method which relates to a caret position in a text: >>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>> This requires additional investigation because DefaultCaret >>>>>>> extends Rectangle and so its coordinates can't be float. >>>>>>> >>>>>>>> >>>>>>>> Since 3rd party code is not over-riding these they will get the JDK >>>>>>>> super-class version, thus losing any customisation they might >>>>>>>> have done >>>>>>>> in the no-longer-called int version. >>>>>>>> >>>>>>>> Assuming that is correct, what customisation would be lost and >>>>>>>> how much does it matter? >>>>>>> >>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>> and draws echo chars instead of text. >>>>>>> The similar can be done in a custom component: >>>>>>> -------- >>>>>>> public class CustomPasswordField extends FieldView { >>>>>>> >>>>>>> @Override >>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>> int p0, int p1) throws BadLocationException { >>>>>>> // draw echo chars >>>>>>> } >>>>>>> } >>>>>>> -------- >>>>>>> >>>>>>> Switching to support new methods with floating point coordinates >>>>>>> will lead that real text will be shown for old applications in >>>>>>> password fields. >>>>>>>> >>>>>>>> My prefernce is to deprecate the int versions and always call >>>>>>>> the float versions >>>>>>>> rather than the opt-in approach. >>>>>>>> >>>>>>>> Actually my real preference would be to come up with something >>>>>>>> that does >>>>>>>> not involve drawing the text in chunks like this. >>>>>>>> >>>>>>>> ie Swing should use AttributedCharacterIterator .. it looks >>>>>>>> like the code to >>>>>>>> do this might already be there ! >>>>>>>> >>>>>>>> 106 private float drawElement(int lineIndex, Element elem, >>>>>>>> Graphics g, >>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>> 108 throws BadLocationException >>>>>>>> 109 { >>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>> 113 >>>>>>>> 114 if (lineIndex == 0) { >>>>>>>> 115 x += firstLineOffset; >>>>>>>> 116 } >>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>> 119 g.setColor(unselected); >>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>> 123 } else { >>>>>>>> >>>>>>>> In fact what *that* illustrates is that applications already >>>>>>>> cannot expect >>>>>>>> their over-ridden methods to be called, so this fix is trying >>>>>>>> to fix something >>>>>>>> that can't be fixed. >>>>>>> The javadoc for the "protected PlainView.drawLine(...)" method is: >>>>>>> --------- >>>>>>> /** >>>>>>> * Renders a line of text, suppressing whitespace at the end >>>>>>> * and expanding any tabs. This is implemented to make calls >>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>> * unselected text are rendered can be customized. >>>>>>> --------- >>>>>>> >>>>>>> Applications can rely on this behaviour and stopping to call >>>>>>> the drawSelectedText(...)/drawUnselectedText(...) methods with >>>>>>> int coordinates will be incompatible change. >>>>>>> >>>>>>>> >>>>>>>> So why can't we do that ? Just deprecate those int methods, >>>>>>>> don't add >>>>>>>> the float methods and use ACI .. >>>>>>> New float methods allow to easily migrate on new API for >>>>>>> applications without significant changes. >>>>>>> >>>>>>>> BTW getTabSize() is supposed to be a character count isn't it ? >>>>>>>> Not a pixel >>>>>>>> count. So why does it need a float version. >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>> >>>>>>> - methods with int coordinates which can be overridden are >>>>>>> deprecated >>>>>>> - getFractionalTabSize() method is removed >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> -phil >>>>>>>> >>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>> use/override the floating point methods. Perhaps it uses a >>>>>>>>>> library that has not been fixed. >>>>>>>>>> >>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>> >>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to >>>>>>>>> the PlainView and WrappedPlainView classes: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>> >>>>>>>>> Using the floating point API is disabled by default and >>>>>>>>> enabled for standard Swing text component classes. This has >>>>>>>>> advantage that selection will work for text component in users >>>>>>>>> applications on HiDPI display. >>>>>>>>> >>>>>>>>> But it still has the same problem. Applications which use >>>>>>>>> custom View classes needs to updated them to implement >>>>>>>>> corresponding text drawing methods with floating point >>>>>>>>> arguments and enable the floating point API usage. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Alan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I tried to merge this fix with the 8132119 Provide public >>>>>>>>>>> API for text related methods in SwingUtilities2 >>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>> >>>>>>>>>>> For each method that uses integer coordinates the fix adds >>>>>>>>>>> a pair with floating point arguments. >>>>>>>>>>> The fix 8156217 uses only methods with floating point >>>>>>>>>>> values to correctly handle a selected text. >>>>>>>>>>> This leads that overridden method with integer arguments in >>>>>>>>>>> user code is not called anymore. >>>>>>>>>>> >>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>> - Add a property that enables to use methods with floating >>>>>>>>>>> point arguments in Swing. >>>>>>>>>>> By default it is false and all work as before. The issue >>>>>>>>>>> with selected text is reproduced. >>>>>>>>>>> An application with enabled property does not have issue >>>>>>>>>>> with the selected text but a user should override >>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>> >>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>> >>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image rendering for >>>>>>>>>>> HiDPI displays >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to look deeper in the code and it seems there is a >>>>>>>>>>>>> rounding issue when float values are summed up. >>>>>>>>>>>>> >>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the 'a' >>>>>>>>>>>>> char advance is 10 in a dev space. >>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 as >>>>>>>>>>>>> double value and 6.6666665 when it is cast to float in >>>>>>>>>>>>> user space. >>>>>>>>>>>>> The width of a string which consists of 15 'a' chars is 15 >>>>>>>>>>>>> * 6.6666665 = 100.000000. >>>>>>>>>>>>> But the same width calculated as sum of each glyph advance >>>>>>>>>>>>> in StandardGlyphVector.initPositions() method is 99.999992. >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N >>>>>>>>>>>>> * advance); >>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>> } >>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> >>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects the text >>>>>>>>>>>>> selection code in Swing: >>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); // >>>>>>>>>>>>> non-selected text >>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), >>>>>>>>>>>>> x + selectedTextPosition, y); // selected text is shifted >>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>> ------------------------ >>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>> If the graphics has scale 1.5 and zero translate the >>>>>>>>>>>> transformed coordinates are: >>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>> >>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>> >>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to one >>>>>>>>>>>> pixel left >>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>> >>>>>>>>>>>> A position 99.999992 in user space is rounded to 151 in >>>>>>>>>>>> dev space. >>>>>>>>>>>> A position 100.000000 in user space is rounded to 152 in >>>>>>>>>>>> dev space. >>>>>>>>>>>> >>>>>>>>>>>> And this difference can depend on the translate even it >>>>>>>>>>>> has integer value in user space because it is multiplied on >>>>>>>>>>>> the graphics scale. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I applied this and it is *much* better but there still >>>>>>>>>>>>>>> seem to be some tiny quirks. >>>>>>>>>>>>>>> When I drag the mouse to select text down and then up >>>>>>>>>>>>>>> again, as I pass the >>>>>>>>>>>>>>> original mouse click point vertically, repaint seem to >>>>>>>>>>>>>>> jiggle vertically by a pixel. >>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>> the target y. I think I may see the same in left/right >>>>>>>>>>>>>>> dragging along a line too. >>>>>>>>>>>>>>> So I think this is repaint and not text related. Can you >>>>>>>>>>>>>>> take a look. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am able to reproduce this only using a floating >>>>>>>>>>>>>> point scale. >>>>>>>>>>>>>> It looks like 2d issue. I used a test which draws a >>>>>>>>>>>>>> text in two pieces. The second piece of the text is >>>>>>>>>>>>>> shifted from the first piece by the floating point size >>>>>>>>>>>>>> of the the first piece of the text. >>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>>>>>>>>>> selectedTextPosition, y); >>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> The second piece of the text can be shifted in the 2 cases: >>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing position >>>>>>>>>>>>>> and with float pointing scale is shifted >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is the second part of the fix related to the >>>>>>>>>>>>>>>> fact that char width can be fractional in user space. >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used for the >>>>>>>>>>>>>>>> fractional string width calculation by Swing in user >>>>>>>>>>>>>>>> space. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Sep 1 13:38:39 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 1 Sep 2016 16:38:39 +0300 Subject: [9] Review request for 8163167: [PIT] javax/swing/JTextArea/ScrollbarFlicker/ScrollFlickerTest.java always fail In-Reply-To: <4af938e3-b86c-406a-b499-b1e8a08a67cf@oracle.com> References: <6d2444db-6cef-c6fb-1714-10431462bc3c@oracle.com> <9cc78350-edb6-7904-4a44-e5bd27532f33@oracle.com> <948780ff-fdb8-0b57-8714-8d3a6599ad5f@oracle.com> <224dab41-d43f-5a8c-f027-196e6bdac4a8@oracle.com> <68ca4d96-12da-0cf9-c843-f0e8dc74b814@oracle.com> <923e8f8c-60f8-9070-e0bd-cafeda47ecac@oracle.com> <233d8b57-7adc-497b-7004-bb1b4a427bd1@oracle.com> <30f462f7-2348-3249-d0cc-a7818356b7b4@oracle.com> <7378e929-31d4-0c3a-267a-f85ebf9d303e@oracle.com> <4af938e3-b86c-406a-b499-b1e8a08a67cf@oracle.com> Message-ID: <2aa30c0d-231a-f052-d351-f5ecdb8ccf5d@oracle.com> On 31.08.2016 21:01, Sergey Bylokhov wrote: > On 31.08.16 15:48, Semyon Sadetsky wrote: >>>> As I already mentioned it can cause several layout iterations >>>> depending >>>> on the scroll policy, L&F, etc. So, once again, it is expected >>>> behavior, >>>> and moreover it is unrelated to the current fix. >>> >>> The bug is that we call notification more time than expected, we >>> should calculate how many times it should be called and check this in >>> the test. >> The test is only checks flicker effect. These 6 notifications do not >> cause flicker. So, the test is correct. > > If the test is correct why you tries to change it? The test found a > bug when we get more notifications than expected. The issue was to count normal notifications from revalidation. Now the counter starts to count after the layout is done. > >>> I assume that each notification should be called when the size of >>> JViewport or View were changed? >>> >>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 23.08.16 11:59, Alexander Scherbatiy wrote: >>>>>>>>>>>> The fix looks good to me. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 23/08/16 11:40, Semyon Sadetsky wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8163167 >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8163167/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> The cause of this test bug is revalidating JScrollPane >>>>>>>>>>>>> layout may >>>>>>>>>>>>> take >>>>>>>>>>>>> various number of iterations on different L&Fs. >>>>>>>>>>>>> >>>>>>>>>>>>> To fix the test the counter listener is added after the >>>>>>>>>>>>> layout >>>>>>>>>>>>> revalidation has been started. >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Thu Sep 1 15:15:44 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 1 Sep 2016 18:15:44 +0300 Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> Message-ID: On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: > > Hi*,* > > Please review fix for JDK 9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8009477 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ > > > *Cause:*PageUp/PageDown key is used to scroll by block, > > MinorTickSpacing set by the user is not consider as the Block size. > > *Fix:* MinorTickSpacing(non-zero value) set by the user is set as > Block size. > For the case there only majorTickSpacing is set should it be used for a block increment? Thanks, Alexandr. > > Regards, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Sep 1 15:49:44 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 1 Sep 2016 18:49:44 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> Message-ID: <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> Alexander, did you consider possibility to check if method is really over-riden then to use the old API? --Semyon On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: > On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >> >> Hi Alexander, >> >> It is a good style to add a note recommending what to use instead of >> the method which is being deprecated. >> > Could you review the updated public API there "replaced by" notes > are added to the deprecated methods: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >> >> I did not get for what the useFloatingPointAPI property was >> introduced and moreover is set to false by default. If the old API is >> used then it doesn't matter which value it has because the float >> values will receive ints. And for the new API I would expect >> everything having the float precision, and it is unclear what may be >> the reason to switch it off back to integer. Especially if >> >> " This allows to draw text properly using graphics with scaled >> transform." >> >> so an improper mode is the default? >> > This is has been discussed below. For example new > drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) with > floating point coordinates is added to the PlainView which has the > same method with int coordinates. Suppose someone has a custom > password component which uses and old methods with int coordinates. > -------- > public class CustomPasswordField extends FieldView { > > @Override > protected int drawSelectedText(Graphics g, int x, int y, int p0, > int p1) throws BadLocationException { > // draw echo chars > } > } > -------- > > If we start to call drawSelectedText() with floating point values the > customization of old components will not be used and the > CustomPasswordField from the example starts to show real text instead > of echo chars. This is incompatible change with previous JDK releases. > > The solution is to switch to new floating point API only when it is > known that a component properly overrides new methods with floating > point arguments. After that the PlainView.useFloatingPointAPI flag can > be set to true. > > For example, BasicPasswordFieldUI sets the > PasswordView.useFloatingPointAPI flag to true because it is sure that > drawSelectedText() methods with floating point arguments is > overridden. So Swing standard text components are switched to use new > floating point API. > > Thanks, > Alexandr. > >> --Semyon >> >> >> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>> OK .. I do not know enough about how modelToView is used by Swing >>>> to know what is really needed here. Someone with a bit more Swing >>>> background needs to chime in. I was encouraged that the *API* surface >>>> of the changes was much smaller than it had seemed from the webrev >>>> but maybe that is because you did not include everything. For example >>>> although they are just subclassing the method overrides in PasswordView >>>> since that is a public class would become part of the spec .. would >>>> they not ? >>>> Just like the "int" counterparts today :- >>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>> >>>> Put another way I was looking for what the content of the CCC would be. >>> Here is the updated version of the public API change which >>> includes overridden deprecated methods: >>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>> >>> Thanks, >>> Alexandr. >>>> >>>> -phil. >>>> >>>> >>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>> Why is the caret support added in here ? Same for the modelToView >>>>>> That will just hold this up as the reasoning behind needing those >>>>>> changes is not something >>>>>> I have yet been able to convince myself about - even after >>>>>> reading your last email. >>>>> >>>>> The main change for the Caret public API (methods >>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>> p)) is not included in the current fix. I only moved the new >>>>> methods JTextComponent.modelToView2D(int >>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret to this >>>>> fix. These methods are used not only for caret but in other cases >>>>> like mouse handling, text dragging and others. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> >>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix? >>>>>>> webrev which contains only change in public API: >>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>> webrev with contains all changes: >>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>> >>>>>>> - methods with int coordinates are deprecated >>>>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>> methods are added to the PlainView and WrappedPlainView classes >>>>>>> - JTextComponent.modelToView2D(int pos)/viewToModel2D(Point2D >>>>>>> pt) public methods from fix JDK-8163124 Add floating point API >>>>>>> support to javax.swing.text.Caret >>>>>>> are added >>>>>>> - some @implSpec descriptions are removed from the new text >>>>>>> drawing methods with floating point arguments >>>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>>> standard Java text components >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> See comments inline. >>>>>>>> >>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>> I have a lot of doubts about this as well as trouble getting >>>>>>>>> my head around all of it. >>>>>>>>> >>>>>>>>> Given that apps need to 'buy in' to the floating point I am >>>>>>>>> not sure what we are gaining >>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>> >>>>>>>>> It affects only the methods that the 3rd party code can over-ride >>>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>>> >>>>>>>>> There are just two protected methods that matter :- >>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>> and >>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>> >>>>>>>>> The hidpi precison matters since they are drawing a sub-range >>>>>>>>> of the text. >>>>>>>>> Is there any other method that matters / is used in this way ? >>>>>>>> I have found the following methods which relate to text >>>>>>>> drawing, can be overridden and could have floating point >>>>>>>> coordinates: >>>>>>>> >>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>> >>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>> >>>>>>>> There is also a method which relates to a caret position in a text: >>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>> This requires additional investigation because DefaultCaret >>>>>>>> extends Rectangle and so its coordinates can't be float. >>>>>>>> >>>>>>>>> >>>>>>>>> Since 3rd party code is not over-riding these they will get >>>>>>>>> the JDK >>>>>>>>> super-class version, thus losing any customisation they might >>>>>>>>> have done >>>>>>>>> in the no-longer-called int version. >>>>>>>>> >>>>>>>>> Assuming that is correct, what customisation would be lost and >>>>>>>>> how much does it matter? >>>>>>>> >>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>> and draws echo chars instead of text. >>>>>>>> The similar can be done in a custom component: >>>>>>>> -------- >>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>> >>>>>>>> @Override >>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>> // draw echo chars >>>>>>>> } >>>>>>>> } >>>>>>>> -------- >>>>>>>> >>>>>>>> Switching to support new methods with floating point >>>>>>>> coordinates will lead that real text will be shown for old >>>>>>>> applications in password fields. >>>>>>>>> >>>>>>>>> My prefernce is to deprecate the int versions and always call >>>>>>>>> the float versions >>>>>>>>> rather than the opt-in approach. >>>>>>>>> >>>>>>>>> Actually my real preference would be to come up with something >>>>>>>>> that does >>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>> >>>>>>>>> ie Swing should use AttributedCharacterIterator .. it looks >>>>>>>>> like the code to >>>>>>>>> do this might already be there ! >>>>>>>>> >>>>>>>>> 106 private float drawElement(int lineIndex, Element elem, >>>>>>>>> Graphics g, >>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>> 108 throws BadLocationException >>>>>>>>> 109 { >>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>> 113 >>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>> 115 x += firstLineOffset; >>>>>>>>> 116 } >>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>> 119 g.setColor(unselected); >>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>> 123 } else { >>>>>>>>> >>>>>>>>> In fact what *that* illustrates is that applications already >>>>>>>>> cannot expect >>>>>>>>> their over-ridden methods to be called, so this fix is trying >>>>>>>>> to fix something >>>>>>>>> that can't be fixed. >>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" method is: >>>>>>>> --------- >>>>>>>> /** >>>>>>>> * Renders a line of text, suppressing whitespace at the end >>>>>>>> * and expanding any tabs. This is implemented to make calls >>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>> * unselected text are rendered can be customized. >>>>>>>> --------- >>>>>>>> >>>>>>>> Applications can rely on this behaviour and stopping to call >>>>>>>> the drawSelectedText(...)/drawUnselectedText(...) methods with >>>>>>>> int coordinates will be incompatible change. >>>>>>>> >>>>>>>>> >>>>>>>>> So why can't we do that ? Just deprecate those int methods, >>>>>>>>> don't add >>>>>>>>> the float methods and use ACI .. >>>>>>>> New float methods allow to easily migrate on new API for >>>>>>>> applications without significant changes. >>>>>>>> >>>>>>>>> BTW getTabSize() is supposed to be a character count isn't it >>>>>>>>> ? Not a pixel >>>>>>>>> count. So why does it need a float version. >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>> >>>>>>>> - methods with int coordinates which can be overridden are >>>>>>>> deprecated >>>>>>>> - getFractionalTabSize() method is removed >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> -phil >>>>>>>>> >>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>> use/override the floating point methods. Perhaps it uses a >>>>>>>>>>> library that has not been fixed. >>>>>>>>>>> >>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>> >>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to >>>>>>>>>> the PlainView and WrappedPlainView classes: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>> >>>>>>>>>> Using the floating point API is disabled by default and >>>>>>>>>> enabled for standard Swing text component classes. This has >>>>>>>>>> advantage that selection will work for text component in >>>>>>>>>> users applications on HiDPI display. >>>>>>>>>> >>>>>>>>>> But it still has the same problem. Applications which use >>>>>>>>>> custom View classes needs to updated them to implement >>>>>>>>>> corresponding text drawing methods with floating point >>>>>>>>>> arguments and enable the floating point API usage. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Alan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide public >>>>>>>>>>>> API for text related methods in SwingUtilities2 >>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>> >>>>>>>>>>>> For each method that uses integer coordinates the fix adds >>>>>>>>>>>> a pair with floating point arguments. >>>>>>>>>>>> The fix 8156217 uses only methods with floating point >>>>>>>>>>>> values to correctly handle a selected text. >>>>>>>>>>>> This leads that overridden method with integer arguments >>>>>>>>>>>> in user code is not called anymore. >>>>>>>>>>>> >>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>> - Add a property that enables to use methods with floating >>>>>>>>>>>> point arguments in Swing. >>>>>>>>>>>> By default it is false and all work as before. The issue >>>>>>>>>>>> with selected text is reproduced. >>>>>>>>>>>> An application with enabled property does not have issue >>>>>>>>>>>> with the selected text but a user should override >>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>> >>>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>> >>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image rendering for >>>>>>>>>>>> HiDPI displays >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to look deeper in the code and it seems there is >>>>>>>>>>>>>> a rounding issue when float values are summed up. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the 'a' >>>>>>>>>>>>>> char advance is 10 in a dev space. >>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 as >>>>>>>>>>>>>> double value and 6.6666665 when it is cast to float in >>>>>>>>>>>>>> user space. >>>>>>>>>>>>>> The width of a string which consists of 15 'a' chars is >>>>>>>>>>>>>> 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() method is >>>>>>>>>>>>>> 99.999992. >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N >>>>>>>>>>>>>> * advance); >>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>> } >>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects the >>>>>>>>>>>>>> text selection code in Swing: >>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); // >>>>>>>>>>>>>> non-selected text >>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // selected >>>>>>>>>>>>>> text is shifted to one pixel left >>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate the >>>>>>>>>>>>> transformed coordinates are: >>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>> >>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>> >>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to one >>>>>>>>>>>>> pixel left >>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>> >>>>>>>>>>>>> A position 99.999992 in user space is rounded to 151 in >>>>>>>>>>>>> dev space. >>>>>>>>>>>>> A position 100.000000 in user space is rounded to 152 in >>>>>>>>>>>>> dev space. >>>>>>>>>>>>> >>>>>>>>>>>>> And this difference can depend on the translate even it >>>>>>>>>>>>> has integer value in user space because it is multiplied >>>>>>>>>>>>> on the graphics scale. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I applied this and it is *much* better but there still >>>>>>>>>>>>>>>> seem to be some tiny quirks. >>>>>>>>>>>>>>>> When I drag the mouse to select text down and then up >>>>>>>>>>>>>>>> again, as I pass the >>>>>>>>>>>>>>>> original mouse click point vertically, repaint seem to >>>>>>>>>>>>>>>> jiggle vertically by a pixel. >>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>> the target y. I think I may see the same in left/right >>>>>>>>>>>>>>>> dragging along a line too. >>>>>>>>>>>>>>>> So I think this is repaint and not text related. Can >>>>>>>>>>>>>>>> you take a look. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am able to reproduce this only using a floating >>>>>>>>>>>>>>> point scale. >>>>>>>>>>>>>>> It looks like 2d issue. I used a test which draws a >>>>>>>>>>>>>>> text in two pieces. The second piece of the text is >>>>>>>>>>>>>>> shifted from the first piece by the floating point size >>>>>>>>>>>>>>> of the the first piece of the text. >>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>>>>>>>>>>> selectedTextPosition, y); >>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The second piece of the text can be shifted in the 2 >>>>>>>>>>>>>>> cases: >>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing position >>>>>>>>>>>>>>> and with float pointing scale is shifted >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is the second part of the fix related to the >>>>>>>>>>>>>>>>> fact that char width can be fractional in user space. >>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used for the >>>>>>>>>>>>>>>>> fractional string width calculation by Swing in user >>>>>>>>>>>>>>>>> space. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Sep 1 16:27:32 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 1 Sep 2016 19:27:32 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> Message-ID: On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: > > Alexander, did you consider possibility to check if method is really > over-riden then to use the old API? > Could you give a sample how it can be done? Thanks, Alexandr. > --Semyon > > On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>> >>> Hi Alexander, >>> >>> It is a good style to add a note recommending what to use instead of >>> the method which is being deprecated. >>> >> Could you review the updated public API there "replaced by" notes >> are added to the deprecated methods: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>> >>> I did not get for what the useFloatingPointAPI property was >>> introduced and moreover is set to false by default. If the old API >>> is used then it doesn't matter which value it has because the float >>> values will receive ints. And for the new API I would expect >>> everything having the float precision, and it is unclear what may be >>> the reason to switch it off back to integer. Especially if >>> >>> " This allows to draw text properly using graphics with scaled >>> transform." >>> >>> so an improper mode is the default? >>> >> This is has been discussed below. For example new >> drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) with >> floating point coordinates is added to the PlainView which has the >> same method with int coordinates. Suppose someone has a custom >> password component which uses and old methods with int coordinates. >> -------- >> public class CustomPasswordField extends FieldView { >> >> @Override >> protected int drawSelectedText(Graphics g, int x, int y, int p0, >> int p1) throws BadLocationException { >> // draw echo chars >> } >> } >> -------- >> >> If we start to call drawSelectedText() with floating point values the >> customization of old components will not be used and the >> CustomPasswordField from the example starts to show real text instead >> of echo chars. This is incompatible change with previous JDK releases. >> >> The solution is to switch to new floating point API only when it is >> known that a component properly overrides new methods with floating >> point arguments. After that the PlainView.useFloatingPointAPI flag >> can be set to true. >> >> For example, BasicPasswordFieldUI sets the >> PasswordView.useFloatingPointAPI flag to true because it is sure >> that drawSelectedText() methods with floating point arguments is >> overridden. So Swing standard text components are switched to use new >> floating point API. >> >> Thanks, >> Alexandr. >> >>> --Semyon >>> >>> >>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>> OK .. I do not know enough about how modelToView is used by Swing >>>>> to know what is really needed here. Someone with a bit more Swing >>>>> background needs to chime in. I was encouraged that the *API* surface >>>>> of the changes was much smaller than it had seemed from the webrev >>>>> but maybe that is because you did not include everything. For example >>>>> although they are just subclassing the method overrides in >>>>> PasswordView >>>>> since that is a public class would become part of the spec .. >>>>> would they not ? >>>>> Just like the "int" counterparts today :- >>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>> >>>>> Put another way I was looking for what the content of the CCC >>>>> would be. >>>> Here is the updated version of the public API change which >>>> includes overridden deprecated methods: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>> Why is the caret support added in here ? Same for the modelToView >>>>>>> That will just hold this up as the reasoning behind needing >>>>>>> those changes is not something >>>>>>> I have yet been able to convince myself about - even after >>>>>>> reading your last email. >>>>>> >>>>>> The main change for the Caret public API (methods >>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>> p)) is not included in the current fix. I only moved the new >>>>>> methods JTextComponent.modelToView2D(int >>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret to this >>>>>> fix. These methods are used not only for caret but in other cases >>>>>> like mouse handling, text dragging and others. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated fix? >>>>>>>> webrev which contains only change in public API: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>> webrev with contains all changes: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>> >>>>>>>> - methods with int coordinates are deprecated >>>>>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>> methods are added to the PlainView and WrappedPlainView classes >>>>>>>> - JTextComponent.modelToView2D(int pos)/viewToModel2D(Point2D >>>>>>>> pt) public methods from fix JDK-8163124 Add floating point API >>>>>>>> support to javax.swing.text.Caret >>>>>>>> are added >>>>>>>> - some @implSpec descriptions are removed from the new text >>>>>>>> drawing methods with floating point arguments >>>>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>>>> standard Java text components >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> See comments inline. >>>>>>>>> >>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>> I have a lot of doubts about this as well as trouble getting >>>>>>>>>> my head around all of it. >>>>>>>>>> >>>>>>>>>> Given that apps need to 'buy in' to the floating point I am >>>>>>>>>> not sure what we are gaining >>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>> >>>>>>>>>> It affects only the methods that the 3rd party code can >>>>>>>>>> over-ride >>>>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>>>> >>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>> and >>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>> >>>>>>>>>> The hidpi precison matters since they are drawing a sub-range >>>>>>>>>> of the text. >>>>>>>>>> Is there any other method that matters / is used in this way ? >>>>>>>>> I have found the following methods which relate to text >>>>>>>>> drawing, can be overridden and could have floating point >>>>>>>>> coordinates: >>>>>>>>> >>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>> >>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>> >>>>>>>>> There is also a method which relates to a caret position in a >>>>>>>>> text: >>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>> This requires additional investigation because DefaultCaret >>>>>>>>> extends Rectangle and so its coordinates can't be float. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Since 3rd party code is not over-riding these they will get >>>>>>>>>> the JDK >>>>>>>>>> super-class version, thus losing any customisation they might >>>>>>>>>> have done >>>>>>>>>> in the no-longer-called int version. >>>>>>>>>> >>>>>>>>>> Assuming that is correct, what customisation would be lost >>>>>>>>>> and how much does it matter? >>>>>>>>> >>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>> The similar can be done in a custom component: >>>>>>>>> -------- >>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>>> // draw echo chars >>>>>>>>> } >>>>>>>>> } >>>>>>>>> -------- >>>>>>>>> >>>>>>>>> Switching to support new methods with floating point >>>>>>>>> coordinates will lead that real text will be shown for old >>>>>>>>> applications in password fields. >>>>>>>>>> >>>>>>>>>> My prefernce is to deprecate the int versions and always call >>>>>>>>>> the float versions >>>>>>>>>> rather than the opt-in approach. >>>>>>>>>> >>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>> something that does >>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>> >>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it looks >>>>>>>>>> like the code to >>>>>>>>>> do this might already be there ! >>>>>>>>>> >>>>>>>>>> 106 private float drawElement(int lineIndex, Element elem, >>>>>>>>>> Graphics g, >>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>> 108 throws BadLocationException >>>>>>>>>> 109 { >>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>> 113 >>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>> 116 } >>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>> 123 } else { >>>>>>>>>> >>>>>>>>>> In fact what *that* illustrates is that applications already >>>>>>>>>> cannot expect >>>>>>>>>> their over-ridden methods to be called, so this fix is trying >>>>>>>>>> to fix something >>>>>>>>>> that can't be fixed. >>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" method is: >>>>>>>>> --------- >>>>>>>>> /** >>>>>>>>> * Renders a line of text, suppressing whitespace at the end >>>>>>>>> * and expanding any tabs. This is implemented to make calls >>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> Applications can rely on this behaviour and stopping to call >>>>>>>>> the drawSelectedText(...)/drawUnselectedText(...) methods with >>>>>>>>> int coordinates will be incompatible change. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> So why can't we do that ? Just deprecate those int methods, >>>>>>>>>> don't add >>>>>>>>>> the float methods and use ACI .. >>>>>>>>> New float methods allow to easily migrate on new API for >>>>>>>>> applications without significant changes. >>>>>>>>> >>>>>>>>>> BTW getTabSize() is supposed to be a character count isn't it >>>>>>>>>> ? Not a pixel >>>>>>>>>> count. So why does it need a float version. >>>>>>>>> Could you review the updated fix: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>> >>>>>>>>> - methods with int coordinates which can be overridden are >>>>>>>>> deprecated >>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> -phil >>>>>>>>>> >>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>> use/override the floating point methods. Perhaps it uses a >>>>>>>>>>>> library that has not been fixed. >>>>>>>>>>>> >>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>> >>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to >>>>>>>>>>> the PlainView and WrappedPlainView classes: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>> >>>>>>>>>>> Using the floating point API is disabled by default and >>>>>>>>>>> enabled for standard Swing text component classes. This has >>>>>>>>>>> advantage that selection will work for text component in >>>>>>>>>>> users applications on HiDPI display. >>>>>>>>>>> >>>>>>>>>>> But it still has the same problem. Applications which use >>>>>>>>>>> custom View classes needs to updated them to implement >>>>>>>>>>> corresponding text drawing methods with floating point >>>>>>>>>>> arguments and enable the floating point API usage. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Alan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>> >>>>>>>>>>>>> For each method that uses integer coordinates the fix >>>>>>>>>>>>> adds a pair with floating point arguments. >>>>>>>>>>>>> The fix 8156217 uses only methods with floating point >>>>>>>>>>>>> values to correctly handle a selected text. >>>>>>>>>>>>> This leads that overridden method with integer arguments >>>>>>>>>>>>> in user code is not called anymore. >>>>>>>>>>>>> >>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>> By default it is false and all work as before. The >>>>>>>>>>>>> issue with selected text is reproduced. >>>>>>>>>>>>> An application with enabled property does not have >>>>>>>>>>>>> issue with the selected text but a user should override >>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>> >>>>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>> >>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image rendering >>>>>>>>>>>>> for HiDPI displays >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I tried to look deeper in the code and it seems there is >>>>>>>>>>>>>>> a rounding issue when float values are summed up. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the 'a' >>>>>>>>>>>>>>> char advance is 10 in a dev space. >>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 as >>>>>>>>>>>>>>> double value and 6.6666665 when it is cast to float in >>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>> The width of a string which consists of 15 'a' chars is >>>>>>>>>>>>>>> 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() method is >>>>>>>>>>>>>>> 99.999992. >>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, >>>>>>>>>>>>>>> N * advance); >>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects the >>>>>>>>>>>>>>> text selection code in Swing: >>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); // >>>>>>>>>>>>>>> non-selected text >>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate the >>>>>>>>>>>>>> transformed coordinates are: >>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to one >>>>>>>>>>>>>> pixel left >>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>> >>>>>>>>>>>>>> A position 99.999992 in user space is rounded to 151 in >>>>>>>>>>>>>> dev space. >>>>>>>>>>>>>> A position 100.000000 in user space is rounded to 152 in >>>>>>>>>>>>>> dev space. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And this difference can depend on the translate even it >>>>>>>>>>>>>> has integer value in user space because it is multiplied >>>>>>>>>>>>>> on the graphics scale. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I applied this and it is *much* better but there still >>>>>>>>>>>>>>>>> seem to be some tiny quirks. >>>>>>>>>>>>>>>>> When I drag the mouse to select text down and then up >>>>>>>>>>>>>>>>> again, as I pass the >>>>>>>>>>>>>>>>> original mouse click point vertically, repaint seem to >>>>>>>>>>>>>>>>> jiggle vertically by a pixel. >>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>> the target y. I think I may see the same in left/right >>>>>>>>>>>>>>>>> dragging along a line too. >>>>>>>>>>>>>>>>> So I think this is repaint and not text related. Can >>>>>>>>>>>>>>>>> you take a look. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am able to reproduce this only using a floating >>>>>>>>>>>>>>>> point scale. >>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which draws a >>>>>>>>>>>>>>>> text in two pieces. The second piece of the text is >>>>>>>>>>>>>>>> shifted from the first piece by the floating point size >>>>>>>>>>>>>>>> of the the first piece of the text. >>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>>>>>>>>>>>> selectedTextPosition, y); >>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The second piece of the text can be shifted in the 2 >>>>>>>>>>>>>>>> cases: >>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing position >>>>>>>>>>>>>>>> and with float pointing scale is shifted >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This is the second part of the fix related to the >>>>>>>>>>>>>>>>>> fact that char width can be fractional in user space. >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used for >>>>>>>>>>>>>>>>>> the fractional string width calculation by Swing in >>>>>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Sep 1 17:26:39 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 1 Sep 2016 20:26:39 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> Message-ID: On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: > On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >> >> Alexander, did you consider possibility to check if method is really >> over-riden then to use the old API? >> > Could you give a sample how it can be done? I think it is possible to use a reflection to found the latest overridden method which uses int coordinates and check does it has a corresponding overridden method with floating point arguments. But I doubt that it is a good solution. Thanks, Alexandr. > > Thanks, > Alexandr. > >> --Semyon >> >> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>> >>>> Hi Alexander, >>>> >>>> It is a good style to add a note recommending what to use instead >>>> of the method which is being deprecated. >>>> >>> Could you review the updated public API there "replaced by" notes >>> are added to the deprecated methods: >>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>> >>>> I did not get for what the useFloatingPointAPI property was >>>> introduced and moreover is set to false by default. If the old API >>>> is used then it doesn't matter which value it has because the float >>>> values will receive ints. And for the new API I would expect >>>> everything having the float precision, and it is unclear what may >>>> be the reason to switch it off back to integer. Especially if >>>> >>>> " This allows to draw text properly using graphics with scaled >>>> transform." >>>> >>>> so an improper mode is the default? >>>> >>> This is has been discussed below. For example new >>> drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) >>> with floating point coordinates is added to the PlainView which has >>> the same method with int coordinates. Suppose someone has a custom >>> password component which uses and old methods with int coordinates. >>> -------- >>> public class CustomPasswordField extends FieldView { >>> >>> @Override >>> protected int drawSelectedText(Graphics g, int x, int y, int >>> p0, int p1) throws BadLocationException { >>> // draw echo chars >>> } >>> } >>> -------- >>> >>> If we start to call drawSelectedText() with floating point values >>> the customization of old components will not be used and the >>> CustomPasswordField from the example starts to show real text >>> instead of echo chars. This is incompatible change with previous JDK >>> releases. >>> >>> The solution is to switch to new floating point API only when it is >>> known that a component properly overrides new methods with floating >>> point arguments. After that the PlainView.useFloatingPointAPI flag >>> can be set to true. >>> >>> For example, BasicPasswordFieldUI sets the >>> PasswordView.useFloatingPointAPI flag to true because it is sure >>> that drawSelectedText() methods with floating point arguments is >>> overridden. So Swing standard text components are switched to use >>> new floating point API. >>> >>> Thanks, >>> Alexandr. >>> >>>> --Semyon >>>> >>>> >>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>> OK .. I do not know enough about how modelToView is used by Swing >>>>>> to know what is really needed here. Someone with a bit more Swing >>>>>> background needs to chime in. I was encouraged that the *API* surface >>>>>> of the changes was much smaller than it had seemed from the webrev >>>>>> but maybe that is because you did not include everything. For example >>>>>> although they are just subclassing the method overrides in >>>>>> PasswordView >>>>>> since that is a public class would become part of the spec .. >>>>>> would they not ? >>>>>> Just like the "int" counterparts today :- >>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>> >>>>>> Put another way I was looking for what the content of the CCC >>>>>> would be. >>>>> Here is the updated version of the public API change which >>>>> includes overridden deprecated methods: >>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>> Why is the caret support added in here ? Same for the modelToView >>>>>>>> That will just hold this up as the reasoning behind needing >>>>>>>> those changes is not something >>>>>>>> I have yet been able to convince myself about - even after >>>>>>>> reading your last email. >>>>>>> >>>>>>> The main change for the Caret public API (methods >>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>> p)) is not included in the current fix. I only moved the new >>>>>>> methods JTextComponent.modelToView2D(int >>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret to >>>>>>> this fix. These methods are used not only for caret but in other >>>>>>> cases like mouse handling, text dragging and others. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the updated fix? >>>>>>>>> webrev which contains only change in public API: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>> webrev with contains all changes: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>> >>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>> methods are added to the PlainView and WrappedPlainView classes >>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>> javax.swing.text.Caret >>>>>>>>> are added >>>>>>>>> - some @implSpec descriptions are removed from the new text >>>>>>>>> drawing methods with floating point arguments >>>>>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>>>>> standard Java text components >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> See comments inline. >>>>>>>>>> >>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>> I have a lot of doubts about this as well as trouble getting >>>>>>>>>>> my head around all of it. >>>>>>>>>>> >>>>>>>>>>> Given that apps need to 'buy in' to the floating point I am >>>>>>>>>>> not sure what we are gaining >>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>> >>>>>>>>>>> It affects only the methods that the 3rd party code can >>>>>>>>>>> over-ride >>>>>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>>>>> >>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>> and >>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>> >>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>> sub-range of the text. >>>>>>>>>>> Is there any other method that matters / is used in this way ? >>>>>>>>>> I have found the following methods which relate to text >>>>>>>>>> drawing, can be overridden and could have floating point >>>>>>>>>> coordinates: >>>>>>>>>> >>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>> >>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>> >>>>>>>>>> There is also a method which relates to a caret position in a >>>>>>>>>> text: >>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>>> This requires additional investigation because DefaultCaret >>>>>>>>>> extends Rectangle and so its coordinates can't be float. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Since 3rd party code is not over-riding these they will get >>>>>>>>>>> the JDK >>>>>>>>>>> super-class version, thus losing any customisation they >>>>>>>>>>> might have done >>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>> >>>>>>>>>>> Assuming that is correct, what customisation would be lost >>>>>>>>>>> and how much does it matter? >>>>>>>>>> >>>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>> -------- >>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>> >>>>>>>>>> @Override >>>>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>>>> // draw echo chars >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> -------- >>>>>>>>>> >>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>> coordinates will lead that real text will be shown for old >>>>>>>>>> applications in password fields. >>>>>>>>>>> >>>>>>>>>>> My prefernce is to deprecate the int versions and always >>>>>>>>>>> call the float versions >>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>> >>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>> something that does >>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>> >>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it looks >>>>>>>>>>> like the code to >>>>>>>>>>> do this might already be there ! >>>>>>>>>>> >>>>>>>>>>> 106 private float drawElement(int lineIndex, Element elem, >>>>>>>>>>> Graphics g, >>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>> 109 { >>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>> 113 >>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>> 116 } >>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>> 123 } else { >>>>>>>>>>> >>>>>>>>>>> In fact what *that* illustrates is that applications already >>>>>>>>>>> cannot expect >>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>> trying to fix something >>>>>>>>>>> that can't be fixed. >>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>> method is: >>>>>>>>>> --------- >>>>>>>>>> /** >>>>>>>>>> * Renders a line of text, suppressing whitespace at the end >>>>>>>>>> * and expanding any tabs. This is implemented to make calls >>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>> Applications can rely on this behaviour and stopping to call >>>>>>>>>> the drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>> with int coordinates will be incompatible change. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So why can't we do that ? Just deprecate those int methods, >>>>>>>>>>> don't add >>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>> New float methods allow to easily migrate on new API for >>>>>>>>>> applications without significant changes. >>>>>>>>>> >>>>>>>>>>> BTW getTabSize() is supposed to be a character count isn't >>>>>>>>>>> it ? Not a pixel >>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>> Could you review the updated fix: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>> >>>>>>>>>> - methods with int coordinates which can be overridden >>>>>>>>>> are deprecated >>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> -phil >>>>>>>>>>> >>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>> use/override the floating point methods. Perhaps it uses a >>>>>>>>>>>>> library that has not been fixed. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>>> >>>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods to >>>>>>>>>>>> the PlainView and WrappedPlainView classes: >>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>> >>>>>>>>>>>> Using the floating point API is disabled by default and >>>>>>>>>>>> enabled for standard Swing text component classes. This has >>>>>>>>>>>> advantage that selection will work for text component in >>>>>>>>>>>> users applications on HiDPI display. >>>>>>>>>>>> >>>>>>>>>>>> But it still has the same problem. Applications which use >>>>>>>>>>>> custom View classes needs to updated them to implement >>>>>>>>>>>> corresponding text drawing methods with floating point >>>>>>>>>>>> arguments and enable the floating point API usage. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Alan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For each method that uses integer coordinates the fix >>>>>>>>>>>>>> adds a pair with floating point arguments. >>>>>>>>>>>>>> The fix 8156217 uses only methods with floating point >>>>>>>>>>>>>> values to correctly handle a selected text. >>>>>>>>>>>>>> This leads that overridden method with integer arguments >>>>>>>>>>>>>> in user code is not called anymore. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>> By default it is false and all work as before. The >>>>>>>>>>>>>> issue with selected text is reproduced. >>>>>>>>>>>>>> An application with enabled property does not have >>>>>>>>>>>>>> issue with the selected text but a user should override >>>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image rendering >>>>>>>>>>>>>> for HiDPI displays >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems there >>>>>>>>>>>>>>>> is a rounding issue when float values are summed up. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the 'a' >>>>>>>>>>>>>>>> char advance is 10 in a dev space. >>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 >>>>>>>>>>>>>>>> as double value and 6.6666665 when it is cast to float >>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' chars is >>>>>>>>>>>>>>>> 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() method >>>>>>>>>>>>>>>> is 99.999992. >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, >>>>>>>>>>>>>>>> N * advance); >>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects the >>>>>>>>>>>>>>>> text selection code in Swing: >>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, >>>>>>>>>>>>>>>> 0, index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>> // non-selected text >>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate the >>>>>>>>>>>>>>> transformed coordinates are: >>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to >>>>>>>>>>>>>>> one pixel left >>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to 151 in >>>>>>>>>>>>>>> dev space. >>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to 152 >>>>>>>>>>>>>>> in dev space. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And this difference can depend on the translate even it >>>>>>>>>>>>>>> has integer value in user space because it is multiplied >>>>>>>>>>>>>>> on the graphics scale. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I applied this and it is *much* better but there >>>>>>>>>>>>>>>>>> still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and then up >>>>>>>>>>>>>>>>>> again, as I pass the >>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint seem >>>>>>>>>>>>>>>>>> to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>> So I think this is repaint and not text related. Can >>>>>>>>>>>>>>>>>> you take a look. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am able to reproduce this only using a floating >>>>>>>>>>>>>>>>> point scale. >>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which draws >>>>>>>>>>>>>>>>> a text in two pieces. The second piece of the text is >>>>>>>>>>>>>>>>> shifted from the first piece by the floating point >>>>>>>>>>>>>>>>> size of the the first piece of the text. >>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x + >>>>>>>>>>>>>>>>> selectedTextPosition, y); >>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The second piece of the text can be shifted in the 2 >>>>>>>>>>>>>>>>> cases: >>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is the second part of the fix related to the >>>>>>>>>>>>>>>>>>> fact that char width can be fractional in user space. >>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used for >>>>>>>>>>>>>>>>>>> the fractional string width calculation by Swing in >>>>>>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Sep 1 18:17:33 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 1 Sep 2016 21:17:33 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> Message-ID: <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: > On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>> >>> Alexander, did you consider possibility to check if method is really >>> over-riden then to use the old API? >>> >> Could you give a sample how it can be done? > I think it is possible to use a reflection to found the latest > overridden method which uses int coordinates and check does it has a > corresponding overridden method with floating point arguments. But I > doubt that it is a good solution. yes. You could use: useFloatingPointAPI = PlainView.class.equals(getClass().getMethod("drawUnselectedText", ...).getDeclaringClass()); Otherwise, with high probability your new API will never be used. --Semyon > > Thanks, > Alexandr. >> >> Thanks, >> Alexandr. >> >>> --Semyon >>> >>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>> >>>>> Hi Alexander, >>>>> >>>>> It is a good style to add a note recommending what to use instead >>>>> of the method which is being deprecated. >>>>> >>>> Could you review the updated public API there "replaced by" >>>> notes are added to the deprecated methods: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>> >>>>> I did not get for what the useFloatingPointAPI property was >>>>> introduced and moreover is set to false by default. If the old API >>>>> is used then it doesn't matter which value it has because the >>>>> float values will receive ints. And for the new API I would expect >>>>> everything having the float precision, and it is unclear what may >>>>> be the reason to switch it off back to integer. Especially if >>>>> >>>>> " This allows to draw text properly using graphics with scaled >>>>> transform." >>>>> >>>>> so an improper mode is the default? >>>>> >>>> This is has been discussed below. For example new >>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) >>>> with floating point coordinates is added to the PlainView which has >>>> the same method with int coordinates. Suppose someone has a custom >>>> password component which uses and old methods with int coordinates. >>>> -------- >>>> public class CustomPasswordField extends FieldView { >>>> >>>> @Override >>>> protected int drawSelectedText(Graphics g, int x, int y, int >>>> p0, int p1) throws BadLocationException { >>>> // draw echo chars >>>> } >>>> } >>>> -------- >>>> >>>> If we start to call drawSelectedText() with floating point values >>>> the customization of old components will not be used and the >>>> CustomPasswordField from the example starts to show real text >>>> instead of echo chars. This is incompatible change with previous >>>> JDK releases. >>>> >>>> The solution is to switch to new floating point API only when it is >>>> known that a component properly overrides new methods with floating >>>> point arguments. After that the PlainView.useFloatingPointAPI flag >>>> can be set to true. >>>> >>>> For example, BasicPasswordFieldUI sets the >>>> PasswordView.useFloatingPointAPI flag to true because it is sure >>>> that drawSelectedText() methods with floating point arguments is >>>> overridden. So Swing standard text components are switched to use >>>> new floating point API. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>> OK .. I do not know enough about how modelToView is used by Swing >>>>>>> to know what is really needed here. Someone with a bit more Swing >>>>>>> background needs to chime in. I was encouraged that the *API* >>>>>>> surface >>>>>>> of the changes was much smaller than it had seemed from the webrev >>>>>>> but maybe that is because you did not include everything. For >>>>>>> example >>>>>>> although they are just subclassing the method overrides in >>>>>>> PasswordView >>>>>>> since that is a public class would become part of the spec .. >>>>>>> would they not ? >>>>>>> Just like the "int" counterparts today :- >>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>> >>>>>>> Put another way I was looking for what the content of the CCC >>>>>>> would be. >>>>>> Here is the updated version of the public API change which >>>>>> includes overridden deprecated methods: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>> Why is the caret support added in here ? Same for the modelToView >>>>>>>>> That will just hold this up as the reasoning behind needing >>>>>>>>> those changes is not something >>>>>>>>> I have yet been able to convince myself about - even after >>>>>>>>> reading your last email. >>>>>>>> >>>>>>>> The main change for the Caret public API (methods >>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>> p)) is not included in the current fix. I only moved the new >>>>>>>> methods JTextComponent.modelToView2D(int >>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret to >>>>>>>> this fix. These methods are used not only for caret but in >>>>>>>> other cases like mouse handling, text dragging and others. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you review the updated fix? >>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>> webrev with contains all changes: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>> >>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>> methods are added to the PlainView and WrappedPlainView classes >>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>> javax.swing.text.Caret >>>>>>>>>> are added >>>>>>>>>> - some @implSpec descriptions are removed from the new text >>>>>>>>>> drawing methods with floating point arguments >>>>>>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>>>>>> standard Java text components >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> See comments inline. >>>>>>>>>>> >>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>> >>>>>>>>>>>> Given that apps need to 'buy in' to the floating point I am >>>>>>>>>>>> not sure what we are gaining >>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>> >>>>>>>>>>>> It affects only the methods that the 3rd party code can >>>>>>>>>>>> over-ride >>>>>>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>>>>>> >>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>> and >>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>> >>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>> Is there any other method that matters / is used in this way ? >>>>>>>>>>> I have found the following methods which relate to text >>>>>>>>>>> drawing, can be overridden and could have floating point >>>>>>>>>>> coordinates: >>>>>>>>>>> >>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>> >>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>> >>>>>>>>>>> There is also a method which relates to a caret position in >>>>>>>>>>> a text: >>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>>>> This requires additional investigation because DefaultCaret >>>>>>>>>>> extends Rectangle and so its coordinates can't be float. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Since 3rd party code is not over-riding these they will get >>>>>>>>>>>> the JDK >>>>>>>>>>>> super-class version, thus losing any customisation they >>>>>>>>>>>> might have done >>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>> >>>>>>>>>>>> Assuming that is correct, what customisation would be lost >>>>>>>>>>>> and how much does it matter? >>>>>>>>>>> >>>>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>> -------- >>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>> >>>>>>>>>>> @Override >>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, int >>>>>>>>>>> y, int p0, int p1) throws BadLocationException { >>>>>>>>>>> // draw echo chars >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> -------- >>>>>>>>>>> >>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>> coordinates will lead that real text will be shown for old >>>>>>>>>>> applications in password fields. >>>>>>>>>>>> >>>>>>>>>>>> My prefernce is to deprecate the int versions and always >>>>>>>>>>>> call the float versions >>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>> >>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>> something that does >>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>> >>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>> looks like the code to >>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>> >>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element elem, >>>>>>>>>>>> Graphics g, >>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>> 109 { >>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>> 113 >>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>> 116 } >>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>> 123 } else { >>>>>>>>>>>> >>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>> already cannot expect >>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>> trying to fix something >>>>>>>>>>>> that can't be fixed. >>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>> method is: >>>>>>>>>>> --------- >>>>>>>>>>> /** >>>>>>>>>>> * Renders a line of text, suppressing whitespace at the end >>>>>>>>>>> * and expanding any tabs. This is implemented to make >>>>>>>>>>> calls >>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> Applications can rely on this behaviour and stopping to >>>>>>>>>>> call the drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>> methods with int coordinates will be incompatible change. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So why can't we do that ? Just deprecate those int methods, >>>>>>>>>>>> don't add >>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>> New float methods allow to easily migrate on new API for >>>>>>>>>>> applications without significant changes. >>>>>>>>>>> >>>>>>>>>>>> BTW getTabSize() is supposed to be a character count isn't >>>>>>>>>>>> it ? Not a pixel >>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>> >>>>>>>>>>> - methods with int coordinates which can be overridden >>>>>>>>>>> are deprecated >>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> -phil >>>>>>>>>>>> >>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>> use/override the floating point methods. Perhaps it uses >>>>>>>>>>>>>> a library that has not been fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>>>> >>>>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>> to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>> >>>>>>>>>>>>> Using the floating point API is disabled by default and >>>>>>>>>>>>> enabled for standard Swing text component classes. This >>>>>>>>>>>>> has advantage that selection will work for text component >>>>>>>>>>>>> in users applications on HiDPI display. >>>>>>>>>>>>> >>>>>>>>>>>>> But it still has the same problem. Applications which >>>>>>>>>>>>> use custom View classes needs to updated them to implement >>>>>>>>>>>>> corresponding text drawing methods with floating point >>>>>>>>>>>>> arguments and enable the floating point API usage. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Alan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For each method that uses integer coordinates the fix >>>>>>>>>>>>>>> adds a pair with floating point arguments. >>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating point >>>>>>>>>>>>>>> values to correctly handle a selected text. >>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>> By default it is false and all work as before. The >>>>>>>>>>>>>>> issue with selected text is reproduced. >>>>>>>>>>>>>>> An application with enabled property does not have >>>>>>>>>>>>>>> issue with the selected text but a user should override >>>>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image rendering >>>>>>>>>>>>>>> for HiDPI displays >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems there >>>>>>>>>>>>>>>>> is a rounding issue when float values are summed up. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the 'a' >>>>>>>>>>>>>>>>> char advance is 10 in a dev space. >>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 >>>>>>>>>>>>>>>>> as double value and 6.6666665 when it is cast to float >>>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' chars >>>>>>>>>>>>>>>>> is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() method >>>>>>>>>>>>>>>>> is 99.999992. >>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N * >>>>>>>>>>>>>>>>> advance); >>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects the >>>>>>>>>>>>>>>>> text selection code in Swing: >>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, >>>>>>>>>>>>>>>>> 0, index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>> // non-selected text >>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate the >>>>>>>>>>>>>>>> transformed coordinates are: >>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to >>>>>>>>>>>>>>>> one pixel left >>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to 151 >>>>>>>>>>>>>>>> in dev space. >>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to 152 >>>>>>>>>>>>>>>> in dev space. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And this difference can depend on the translate even >>>>>>>>>>>>>>>> it has integer value in user space because it is >>>>>>>>>>>>>>>> multiplied on the graphics scale. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but there >>>>>>>>>>>>>>>>>>> still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and then >>>>>>>>>>>>>>>>>>> up again, as I pass the >>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint seem >>>>>>>>>>>>>>>>>>> to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>> So I think this is repaint and not text related. Can >>>>>>>>>>>>>>>>>>> you take a look. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I am able to reproduce this only using a floating >>>>>>>>>>>>>>>>>> point scale. >>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which draws >>>>>>>>>>>>>>>>>> a text in two pieces. The second piece of the text is >>>>>>>>>>>>>>>>>> shifted from the first piece by the floating point >>>>>>>>>>>>>>>>>> size of the the first piece of the text. >>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) rect.getWidth(); >>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x >>>>>>>>>>>>>>>>>> + selectedTextPosition, y); >>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in the >>>>>>>>>>>>>>>>>> 2 cases: >>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This is the second part of the fix related to the >>>>>>>>>>>>>>>>>>>> fact that char width can be fractional in user space. >>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used for >>>>>>>>>>>>>>>>>>>> the fractional string width calculation by Swing in >>>>>>>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambarish.rapte at oracle.com Fri Sep 2 04:18:34 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 1 Sep 2016 21:18:34 -0700 (PDT) Subject: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java In-Reply-To: <2966a7ef-cf7c-7426-4fd9-68b976cb0696@oracle.com> References: <680be17d-32e9-4765-99dd-f4ae65d48c9a@default> <6de9c6cb-814a-485d-b36e-c7e3bdbac075@default> <284feaa1-14af-4111-bb17-e652ccb72e05@default> <2966a7ef-cf7c-7426-4fd9-68b976cb0696@oracle.com> Message-ID: <43517154-6fc9-40fe-b1c4-218298f30556@default> Hi Alex, Thanks for the review comments, Yes, we can use the PainterMultiResolutionCachedImage.class object as a key in the PainterMultiResolutionCachedImage.getResolutionVariant() method. But there is below concern, 1. If PainterMultiResolutionCachedImage.class object is used as key in Map cacheMap; 2. There will be only one key value pair entry in the cacheMap. 3. The ImageCache value created for the PainterMultiResolutionCachedImage class is only of size 1. 4. Hence there will be only one image present at a time in the cacheMap. 5. Each time a new image is added, previous one will get deleted. In method: ImageCache::getEntry() => if (entries.size() >= maxCount) { entries.removeLast(); } 6. This will result repeated deletion and creation of images. This requires increase in the size of ImageCache associated with PainterMultiResolutionCachedImage.class key to a certain justified value. For example, we can set the value to 8, so that at a time 8 images can be stored in the ImageCache. So for to add 9th entry, last image would be removed. I am not sure what this value can be. I think this value can be number of components. SwinSet2 demo creates 17+ such images. After deciding a good value, this change can be done, a lesser value may add to processing by re-creating images. Currently we have 2 approaches: Approach1: PainterMultiResolutionCachedImage object as key, with hashCode() & equals() method. HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.02/"http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ Approach2: PainterMultiResolutionCachedImage.class object as key, with a good justified size of ImageCache. http://cr.openjdk.java.net/~arapte/8163261/webrev.03/ BOTH the approach would result in creating same number of creating images, in a normal scenario. however depending of GC/OOM this can change, as we have soft references to images. I observed over a long run of SwingSet2, Approach2 creates less number of images, but Approach1 recreates images. Another difference would be, Approach1 will add pair entries to Map cacheMap. & Approach2 will add only ONE pair entry to Map cacheMap; But add entries to associated ImageCache. I think, approach 2 can be used with a justified size of ImageCache. In webrev.03 it is 32. Please provide, your comments. Regards, Ambarish From: Alexandr Scherbatiy Sent: Monday, August 29, 2016 6:09 PM To: Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java CachedPainter.paint0() uses the object returned by getClass() as a key for the cache. Is it possible to use PainterMultiResolutionCachedImage.class object as a key in the PainterMultiResolutionCachedImage.getResolutionVariant() method? Thanks, Alexandr. On 8/26/2016 1:34 PM, Ambarish Rapte wrote: Hi Alex & All, Please review the updated webrev : HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.02/"http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ Changes: (Copying from the previous email) I have included the change you suggested, to set component reference null after painting the component. In addition there is change in PainterMultiResolutionCachedImage to add hashCode() & equals() methods. Object of PainterMultiResolutionCachedImage is used as key in the Map cacheMap. hashCode() & equals() would avoid multiple entries of similar image objects in the cacheMap & help reduce the size of cacheMap. Verified this change by executing the SwinSet2 demo, all components get painted correctly. Also a small change in test, added check on panel reference and modified error message. Regards, Ambarish From: Ambarish Rapte Sent: Friday, August 26, 2016 12:34 PM To: Ambarish Rapte; Alexander Scherbatiy; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: RE: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java Hi All, Please hold the review for this. There are some merge conflicts with latest code so I shall update the webrev again for review. Regards, Ambarish From: Ambarish Rapte Sent: Thursday, August 25, 2016 10:19 PM To: Alexander Scherbatiy; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java Hi Alex, Thanks for the review comments, Please review the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.01/"http://cr.openjdk.java.net/~arapte/8163261/webrev.01/ I have included the change you suggested, to set component reference null after painting the component. In addition there is change in PainterMultiResolutionCachedImage to add hashCode() & equals() methods. Object of PainterMultiResolutionCachedImage is used as key in the Map cacheMap. hashCode() & equals() would avoid multiple entries of similar image objects in the cacheMap & help reduce the size of cacheMap. Verified this change by executing the SwinSet2 demo, all components get painted correctly. Also a small change in test, added check on panel reference and modified error message. Regards, Ambarish From: Alexander Scherbatiy Sent: Monday, August 22, 2016 5:47 PM To: Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java On 17/08/16 15:49, Alexandr Scherbatiy wrote: On 8/15/2016 12:43 PM, Ambarish Rapte wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8163261 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.00/"http://cr.openjdk.java.net/~arapte/8163261/webrev.00/ Issue: Reference to JButton was not getting collected by GC. Cause: A strong reference to objects was held by PainterMultiResolutionCachedImage. And the image reference was held by HashMap. Fix: Changing the HashMap to WeakHashMap. Entry to WeakHashMap gets removed after the object has no other strong reference. May be using the soft reference would be better in this case. It could be expensive to recreate a cache with images every time GC removed them. There is the code which sets a component to the PainterMultiResolutionCachedImage: CachedPainter.paint0(...) ------- if (image instanceof PainterMultiResolutionCachedImage) { ((PainterMultiResolutionCachedImage) image).setParams(c, args); } // Render to the passed in Graphics paintImage(c, g, x, y, w, h, image, args); ------- May be it is possible to clean up the component and args from the PainterMultiResolutionCachedImage after the image is drawn? Thanks, Alexandr. Regards, Ambarish -------------- next part -------------- An HTML attachment was scrubbed... URL: From prem.balakrishnan at oracle.com Fri Sep 2 05:28:04 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 1 Sep 2016 22:28:04 -0700 (PDT) Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> Message-ID: <6d867507-6e64-4a42-9054-0c6abb4e2242@default> Hi Alexandr, Thankyou for the Review. > For the case there only majorTickSpacing is set should it be used for a block increment? When setSnapToTicks(Boolean value) is set to true, All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest tick(i.e., If minor Tick not set, it considers major Tick as the nearest tick). Based on my understanding, we need to set the minimum blockincrement size for PageUp/PageDown, which should be MinorTickSpacing if available. Where as if minorTickSpacing not Set and only MajorTickSpacing is set then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / 10] should be better. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, September 01, 2016 8:46 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8009477 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ Cause: PageUp/PageDown key is used to scroll by block, MinorTickSpacing set by the user is not consider as the Block size. Fix: MinorTickSpacing(non-zero value) set by the user is set as Block size. For the case there only majorTickSpacing is set should it be used for a block increment? Thanks, Alexandr. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Fri Sep 2 08:41:56 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 2 Sep 2016 11:41:56 +0300 Subject: [9] Review request for 8160054: The FileChooser didn't displayed large font with GTK LAF option. In-Reply-To: References: <0cf97edb-d403-ad74-6f1f-5b31ca77af48@oracle.com> Message-ID: On 7/14/2016 6:31 PM, Alexandr Scherbatiy wrote: > On 6/27/2016 9:23 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8160054 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.00/ >> >> The root case is GTK LnF does not allow to change its default fonts. >> >> The proposed solution let's to use LnF font properties to change the >> defaults. > 292 if (propFont != null && !font.equals(propFont)) { > 293 // if font property got different value then return it > 294 return propFont; > 295 } > > It looks like the !font.equals(propFont) condition is not necessary > because when two fonts are equal it is right to return the propFont as > well. Please review the updated fix http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.01/ --Semyon > > Thanks, > Alexandr. >> >> --Semyon >> >> > From alexandr.scherbatiy at oracle.com Fri Sep 2 09:44:14 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 2 Sep 2016 12:44:14 +0300 Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <6d867507-6e64-4a42-9054-0c6abb4e2242@default> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> Message-ID: <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > Thankyou for the Review. > > > For the case there only majorTickSpacing is set should it be used for a block increment? > > When setSnapToTicks(Boolean value) is set to true, > > All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest > tick(i.e., If minor Tick not set, it considers major Tick as the > nearest tick). > > Based on my understanding, we need to set the minimum blockincrement > size for PageUp/PageDown, which should be MinorTickSpacing if available. > > Where as if minorTickSpacing not Set and only MajorTickSpacing is set > then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / > 10] should be better. > I see that the minorTickSpacing and majorTickSpacing are already used for the block increment in the BasicSliderUI.getTickSpacing() method when slider.getSnapToTicks() is enabled. May be a user just needs to set snapToTicks to true for a slider to get the desired block increment? Thanks, Alexandr. > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, September 01, 2016 8:46 PM > *To:* Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8009477 :PageUp and PageDown > keyboard buttons don't move slider indicator to next minor tick > > On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: > > Hi*,* > > Please review fix for JDK 9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8009477 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ > > > *Cause:*PageUp/PageDown key is used to scroll by block, > > MinorTickSpacing set by the user is not consider as the Block size. > > *Fix:* MinorTickSpacing(non-zero value) set by the user is set as > Block size. > > For the case there only majorTickSpacing is set should it be used > for a block increment? > > Thanks, > Alexandr. > > Regards, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Sep 2 09:50:10 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 2 Sep 2016 12:50:10 +0300 Subject: [9] Review request for 8160054: The FileChooser didn't displayed large font with GTK LAF option. In-Reply-To: References: <0cf97edb-d403-ad74-6f1f-5b31ca77af48@oracle.com> Message-ID: <51e7c18c-e9c0-5579-ba57-cccc11969908@oracle.com> The fix looks good to me. Thanks, Alexandr. On 9/2/2016 11:41 AM, Semyon Sadetsky wrote: > On 7/14/2016 6:31 PM, Alexandr Scherbatiy wrote: > >> On 6/27/2016 9:23 PM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8160054 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.00/ >>> >>> The root case is GTK LnF does not allow to change its default fonts. >>> >>> The proposed solution let's to use LnF font properties to change the >>> defaults. >> 292 if (propFont != null && !font.equals(propFont)) { >> 293 // if font property got different value then return it >> 294 return propFont; >> 295 } >> >> It looks like the !font.equals(propFont) condition is not necessary >> because when two fonts are equal it is right to return the propFont >> as well. > Please review the updated fix > http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.01/ > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>> >>> >> > From prem.balakrishnan at oracle.com Fri Sep 2 10:00:22 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Fri, 2 Sep 2016 03:00:22 -0700 (PDT) Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> Message-ID: <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> Hi Alexandr, Yes true, Setting getSnapToTicks() true will set block increment to minor/majorTickSpacing. But enabling getSanpToTicks will Disable Unit Increment (scrollByUnit using Up/Down Arrow keys ) Regards, Prem From: Alexandr Scherbatiy Sent: Friday, September 02, 2016 3:14 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the Review. > For the case there only majorTickSpacing is set should it be used for a block increment? When setSnapToTicks(Boolean value) is set to true, All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest tick(i.e., If minor Tick not set, it considers major Tick as the nearest tick). Based on my understanding, we need to set the minimum blockincrement size for PageUp/PageDown, which should be MinorTickSpacing if available. Where as if minorTickSpacing not Set and only MajorTickSpacing is set then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / 10] should be better. I see that the minorTickSpacing and majorTickSpacing are already used for the block increment in the BasicSliderUI.getTickSpacing() method when slider.getSnapToTicks() is enabled. May be a user just needs to set snapToTicks to true for a slider to get the desired block increment? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, September 01, 2016 8:46 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8009477 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ Cause: PageUp/PageDown key is used to scroll by block, MinorTickSpacing set by the user is not consider as the Block size. Fix: MinorTickSpacing(non-zero value) set by the user is set as Block size. For the case there only majorTickSpacing is set should it be used for a block increment? Thanks, Alexandr. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Sep 2 12:30:49 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 2 Sep 2016 15:30:49 +0300 Subject: [9] Review request for 8165234 Provide a way to not close toggle menu items on mouse click on component level Message-ID: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8165234 webrev: http://cr.openjdk.java.net/~alexsch/8165234/webrev.00 The fix JDK-8158566 adds "CheckBoxMenuItem.closeOnMouseClick" and "RadioButtonMenuItem.closeOnMouseClick" properties that control toogle menu items closing on mouse click on L&F level. The current fix allows to control menu items closing on a component level. A toogle menu item is not closed on mouse click if the corresponding property is set to false either on the L&F or component level. Thanks, Alexandr. From philip.race at oracle.com Fri Sep 2 18:59:52 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 02 Sep 2016 11:59:52 -0700 Subject: [9] Review request for 8165234 Provide a way to not close toggle menu items on mouse click on component level In-Reply-To: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> References: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> Message-ID: <57C9CC28.2040309@oracle.com> Seems fine except for a grammatical issue in the javadoc {@code true}. Setting the property to {@code false} either to {@literal L&F} I think you mean ".. either on the ..." -phil. On 09/02/2016 05:30 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8165234 > webrev: http://cr.openjdk.java.net/~alexsch/8165234/webrev.00 > > The fix JDK-8158566 adds "CheckBoxMenuItem.closeOnMouseClick" and > "RadioButtonMenuItem.closeOnMouseClick" properties > that control toogle menu items closing on mouse click on L&F level. > > The current fix allows to control menu items closing on a component > level. A toogle menu item > is not closed on mouse click if the corresponding property is set to > false either on the L&F or component level. > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Mon Sep 5 10:09:46 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 5 Sep 2016 13:09:46 +0300 Subject: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java In-Reply-To: <43517154-6fc9-40fe-b1c4-218298f30556@default> References: <680be17d-32e9-4765-99dd-f4ae65d48c9a@default> <6de9c6cb-814a-485d-b36e-c7e3bdbac075@default> <284feaa1-14af-4111-bb17-e652ccb72e05@default> <2966a7ef-cf7c-7426-4fd9-68b976cb0696@oracle.com> <43517154-6fc9-40fe-b1c4-218298f30556@default> Message-ID: On 9/2/2016 7:18 AM, Ambarish Rapte wrote: > > Hi Alex, > > Thanks for the review comments, > > Yes, we can use thePainterMultiResolutionCachedImage.class object as a > key in the PainterMultiResolutionCachedImage.getResolutionVariant() > method. > > But there is below concern, > > 1.If PainterMultiResolutionCachedImage.class object is used as key in > /Map cacheMap;/ > > 2.There will be only one key value pair entry in the /cacheMap/. > The CachedPainter.paint0() method uses getClass() as a key for the cacheMap. At least there should be more than 1 key (getClass() + PainterMultiResolutionCachedImage.class). > 3.The /ImageCache/ value created for the > /PainterMultiResolutionCachedImage class/ is only of size 1. > > 4.Hence there will be only one image present at a time in the /cacheMap/. > > 5.Each time a new image is added, previous one will get deleted. > In method: /ImageCache::getEntry() => if (entries.size() >= > maxCount) { entries.removeLast(); }/ > > 6.This will result repeated deletion and creation of images. > > This requires increase in the size of /ImageCache /associated > with/PainterMultiResolutionCachedImage.class /key to a certain > justified value. > > For example, we can set the value to 8, so that at a time 8 images can > be stored in the /ImageCache/. So for to add 9^th entry, last image > would be removed. > > I am not sure what this value can be. I think this value can be number > of components. > > SwinSet2 demo creates 17+ such images. > > After deciding a good value, this change can be done, a lesser value > may add to processing by re-creating images. > > Currently we have 2 approaches: > > Approach1: /PainterMultiResolutionCachedImage /object as key, > with/hashCode() & equals() /method/. > /http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ > > > Approach2: /PainterMultiResolutionCachedImage.class /object//as key, > with a good justified size of/ImageCache. > /http://cr.openjdk.java.net/~arapte/8163261/webrev.03/ > > Could the image cache size be increased only for the PainterMultiResolutionCachedImage.class key in the approach 2 because other keys may require only one image? Thanks, Alexandr. > > // > > // > > BOTH the approach would result in creating same number of creating > images, in a normal scenario. > > however depending of GC/OOM this can change, as we have soft > references to images. > > I observed over a long run of SwingSet2, Approach2 creates less number > of images, but Approach1 recreates images. > > Another difference would be, > > Approach1 will add pair entries to /Map ImageCache> cacheMap/. > > & > > Approach2 will add only ONE pair entry to /Map ImageCache> cacheMap;/ But add entries to associated /ImageCache/. > > I think, approach 2 can be used with a justified size of ImageCache. > In webrev.03 it is 32. > > Please provide, your comments. > > Regards, > > Ambarish > > *From:*Alexandr Scherbatiy > *Sent:* Monday, August 29, 2016 6:09 PM > *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request for 8163261: regression on > Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > > CachedPainter.paint0() uses the object returned by getClass() as a key > for the cache. > Is it possible to use PainterMultiResolutionCachedImage.class object > as a key in the > PainterMultiResolutionCachedImage.getResolutionVariant() method? > > Thanks, > Alexandr. > > On 8/26/2016 1:34 PM, Ambarish Rapte wrote: > > Hi Alex & All, > > Please review the updated webrev : > http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ > > > Changes: (Copying from the previous email) > > I have included the change you suggested, to set component > reference null after painting the component. > > In addition there is change in PainterMultiResolutionCachedImage > to add /hashCode()/ & /equals()/ methods. > > Object of /PainterMultiResolutionCachedImage/ is used as key in > the /Map cacheMap./ > > /hashCode()/ & /equals()/ would avoid multiple entries of similar > image objects in the /cacheMap/ & help reduce the size of /cacheMap./ > > // > > Verified this change by executing the /SwinSet2/ demo, all > components get painted correctly. > > Also a small change in test, added check on panel reference and > modified error message. > > Regards, > > Ambarish > > *From:*Ambarish Rapte > *Sent:* Friday, August 26, 2016 12:34 PM > *To:* Ambarish Rapte; Alexander Scherbatiy; Sergey Bylokhov; > Rajeev Chamyal; swing-dev at openjdk.java.net > > *Subject:* RE: Review Request for 8163261: regression > on Linux: > java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > Hi All, > > Please hold the review for this. > > There are some merge conflicts with latest code so I shall update > the webrev again for review. > > Regards, > > Ambarish > > *From:*Ambarish Rapte > *Sent:* Thursday, August 25, 2016 10:19 PM > *To:* Alexander Scherbatiy; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request for 8163261: regression > on Linux: > java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > Hi Alex, > > Thanks for the review comments, > > Please review the updated webrev: > http://cr.openjdk.java.net/~arapte/8163261/webrev.01/ > > > I have included the change you suggested, to set component > reference null after painting the component. > > In addition there is change in PainterMultiResolutionCachedImage > to add /hashCode()/ & /equals()/ methods. > > Object of /PainterMultiResolutionCachedImage/ is used as key in > the /Map cacheMap./ > > /hashCode()/ & /equals()/ would avoid multiple entries of similar > image objects in the /cacheMap/ & help reduce the size of /cacheMap./ > > // > > Verified this change by executing the /SwinSet2/ demo, all > components get painted correctly. > > Also a small change in test, added check on panel reference and > modified error message. > > Regards, > > Ambarish > > *From:*Alexander Scherbatiy > *Sent:* Monday, August 22, 2016 5:47 PM > *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request for 8163261: regression > on Linux: > java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > > On 17/08/16 15:49, Alexandr Scherbatiy wrote: > > On 8/15/2016 12:43 PM, Ambarish Rapte wrote: > > Hi, > > Please review fix for JDK9, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163261 > > Webrev: > http://cr.openjdk.java.net/~arapte/8163261/webrev.00/ > > > Issue: > > Reference to JButton was not getting collected by GC. > > Cause: > > A strong reference to objects was held by > PainterMultiResolutionCachedImage. > > And the image reference was held by HashMap. > > Fix: > > Changing the HashMap to WeakHashMap. Entry to > WeakHashMap gets removed after the object has no other strong > reference. > > May be using the soft reference would be better in this case. > It could be expensive to recreate a cache with images every time > GC removed them. > > > There is the code which sets a component to the > PainterMultiResolutionCachedImage: > CachedPainter.paint0(...) > ------- > if (image instanceof PainterMultiResolutionCachedImage) { > ((PainterMultiResolutionCachedImage) > image).setParams(c, args); > } > > // Render to the passed in Graphics > paintImage(c, g, x, y, w, h, image, args); > ------- > > May be it is possible to clean up the component and args from the > PainterMultiResolutionCachedImage after the image is drawn? > > > Thanks, > Alexandr. > > Regards, > > Ambarish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Sep 5 10:20:24 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 5 Sep 2016 13:20:24 +0300 Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> Message-ID: <42827df5-3948-ae9e-db4b-6c864d592457@oracle.com> On 9/2/2016 1:00 PM, Prem Balakrishnan wrote: > > Hi Alexandr, > > Yes true, Setting getSnapToTicks() true will set block increment to > minor/majorTickSpacing. > > But enabling getSanpToTicks will Disable Unit Increment (scrollByUnit > using Up/Down Arrow keys ) > It works in the following way before the fix: Use minor, major, or (max-min)/10 if snapToTicks is enabled. Use (max-min)/10 if snapToTicks is disabled. After the fix it works: Use minor or (max-min)/10 if snapToTicks is disabled. Why major tick spacing is not taken into account in this case in the same way as for the enabled snapToTicks? It seems that both minor and major tick spacing should be checked together. Thanks, Alexandr. > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Friday, September 02, 2016 3:14 PM > *To:* Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8009477 :PageUp and PageDown > keyboard buttons don't move slider indicator to next minor tick > > On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > Thankyou for the Review. > > > For the case there only majorTickSpacing is set should it be used for a block increment? > > When setSnapToTicks(Boolean value) is set to true, > > All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest > tick(i.e., If minor Tick not set, it considers major Tick as the > nearest tick). > > Based on my understanding, we need to set the minimum blockincrement > size for PageUp/PageDown, which should be MinorTickSpacing if available. > > Where as if minorTickSpacing not Set and only MajorTickSpacing is set > then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / > 10] should be better. > > I see that the minorTickSpacing and majorTickSpacing are already > used for the block increment in the BasicSliderUI.getTickSpacing() > method when slider.getSnapToTicks() is enabled. May be a user just > needs to set snapToTicks to true for a slider to get the desired block > increment? > > Thanks, > Alexandr. > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, September 01, 2016 8:46 PM > *To:* Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8009477 :PageUp and PageDown > keyboard buttons don't move slider indicator to next minor tick > > On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: > > > Hi*,* > > Please review fix for JDK 9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8009477 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ > > > *Cause:*PageUp/PageDown key is used to scroll by block, > > MinorTickSpacing set by the user is not consider as the Block size. > > *Fix:* MinorTickSpacing(non-zero value) set by the user is set as > Block size. > > For the case there only majorTickSpacing is set should it be used > for a block increment? > > Thanks, > Alexandr. > > > Regards, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Sep 5 10:51:36 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 5 Sep 2016 13:51:36 +0300 Subject: [9] Review request for 8165234 Provide a way to not close toggle menu items on mouse click on component level In-Reply-To: <57C9CC28.2040309@oracle.com> References: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> <57C9CC28.2040309@oracle.com> Message-ID: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8165234/webrev.01 On 9/2/2016 9:59 PM, Phil Race wrote: > Seems fine except for a grammatical issue in the javadoc > > {@code true}. Setting the property to {@code false} either to > {@literal L&F} > > I think you mean ".. either on the ..." The typo "either to" is updated to "either on the". Thanks, Alexandr. > > -phil. > > On 09/02/2016 05:30 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8165234 >> webrev: http://cr.openjdk.java.net/~alexsch/8165234/webrev.00 >> >> The fix JDK-8158566 adds "CheckBoxMenuItem.closeOnMouseClick" and >> "RadioButtonMenuItem.closeOnMouseClick" properties >> that control toogle menu items closing on mouse click on L&F level. >> >> The current fix allows to control menu items closing on a component >> level. A toogle menu item >> is not closed on mouse click if the corresponding property is set >> to false either on the L&F or component level. >> >> Thanks, >> Alexandr. >> > From Sergey.Bylokhov at oracle.com Mon Sep 5 15:55:02 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 5 Sep 2016 18:55:02 +0300 Subject: [9] Review request for 8160054: The FileChooser didn't displayed large font with GTK LAF option. In-Reply-To: <51e7c18c-e9c0-5579-ba57-cccc11969908@oracle.com> References: <0cf97edb-d403-ad74-6f1f-5b31ca77af48@oracle.com> <51e7c18c-e9c0-5579-ba57-cccc11969908@oracle.com> Message-ID: <6da6633d-b036-bcc4-b195-370968f11794@oracle.com> On 02.09.16 12:50, Alexandr Scherbatiy wrote: > The fix looks good to me. Probably the comment between .00 and .01 should be updated also? "// if font property got different value then return it" > On 9/2/2016 11:41 AM, Semyon Sadetsky wrote: >> On 7/14/2016 6:31 PM, Alexandr Scherbatiy wrote: >> >>> On 6/27/2016 9:23 PM, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160054 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.00/ >>>> >>>> The root case is GTK LnF does not allow to change its default fonts. >>>> >>>> The proposed solution let's to use LnF font properties to change the >>>> defaults. >>> 292 if (propFont != null && !font.equals(propFont)) { >>> 293 // if font property got different value then return it >>> 294 return propFont; >>> 295 } >>> >>> It looks like the !font.equals(propFont) condition is not necessary >>> because when two fonts are equal it is right to return the propFont >>> as well. >> Please review the updated fix >> http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.01/ >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>> >>>> >>> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Mon Sep 5 16:11:04 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 5 Sep 2016 19:11:04 +0300 Subject: [9] Review request for 8160054: The FileChooser didn't displayed large font with GTK LAF option. In-Reply-To: <6da6633d-b036-bcc4-b195-370968f11794@oracle.com> References: <0cf97edb-d403-ad74-6f1f-5b31ca77af48@oracle.com> <51e7c18c-e9c0-5579-ba57-cccc11969908@oracle.com> <6da6633d-b036-bcc4-b195-370968f11794@oracle.com> Message-ID: <0d9c4471-d048-a2ca-665f-70cfc598310f@oracle.com> On 9/5/2016 6:55 PM, Sergey Bylokhov wrote: > On 02.09.16 12:50, Alexandr Scherbatiy wrote: >> The fix looks good to me. > > Probably the comment between .00 and .01 should be updated also? > "// if font property got different value then return it" I will change it to "got a value" upon the push if you don't mind. > > >> On 9/2/2016 11:41 AM, Semyon Sadetsky wrote: >>> On 7/14/2016 6:31 PM, Alexandr Scherbatiy wrote: >>> >>>> On 6/27/2016 9:23 PM, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160054 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.00/ >>>>> >>>>> The root case is GTK LnF does not allow to change its default fonts. >>>>> >>>>> The proposed solution let's to use LnF font properties to change the >>>>> defaults. >>>> 292 if (propFont != null && !font.equals(propFont)) { >>>> 293 // if font property got different value then >>>> return it >>>> 294 return propFont; >>>> 295 } >>>> >>>> It looks like the !font.equals(propFont) condition is not necessary >>>> because when two fonts are equal it is right to return the propFont >>>> as well. >>> Please review the updated fix >>> http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.01/ >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>> >>>>> >>>> >>> >> > > From Sergey.Bylokhov at oracle.com Mon Sep 5 16:51:53 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 5 Sep 2016 19:51:53 +0300 Subject: [9] Review request for 8160054: The FileChooser didn't displayed large font with GTK LAF option. In-Reply-To: <0d9c4471-d048-a2ca-665f-70cfc598310f@oracle.com> References: <0cf97edb-d403-ad74-6f1f-5b31ca77af48@oracle.com> <51e7c18c-e9c0-5579-ba57-cccc11969908@oracle.com> <6da6633d-b036-bcc4-b195-370968f11794@oracle.com> <0d9c4471-d048-a2ca-665f-70cfc598310f@oracle.com> Message-ID: On 05.09.16 19:11, Semyon Sadetsky wrote: > > On 9/5/2016 6:55 PM, Sergey Bylokhov wrote: >> On 02.09.16 12:50, Alexandr Scherbatiy wrote: >>> The fix looks good to me. >> >> Probably the comment between .00 and .01 should be updated also? >> "// if font property got different value then return it" > I will change it to "got a value" upon the push if you don't mind. ok >> >> >>> On 9/2/2016 11:41 AM, Semyon Sadetsky wrote: >>>> On 7/14/2016 6:31 PM, Alexandr Scherbatiy wrote: >>>> >>>>> On 6/27/2016 9:23 PM, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160054 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.00/ >>>>>> >>>>>> The root case is GTK LnF does not allow to change its default fonts. >>>>>> >>>>>> The proposed solution let's to use LnF font properties to change the >>>>>> defaults. >>>>> 292 if (propFont != null && !font.equals(propFont)) { >>>>> 293 // if font property got different value then >>>>> return it >>>>> 294 return propFont; >>>>> 295 } >>>>> >>>>> It looks like the !font.equals(propFont) condition is not necessary >>>>> because when two fonts are equal it is right to return the propFont >>>>> as well. >>>> Please review the updated fix >>>> http://cr.openjdk.java.net/~ssadetsky/8160054/webrev.01/ >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From avik.niyogi at oracle.com Tue Sep 6 06:12:34 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 6 Sep 2016 11:42:34 +0530 Subject: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java Message-ID: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8163274 Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ Issue: This test javax/swing/JColorChooser/Test7194184.java throws exception due to event delay. Cause: Delay for event idling was not added. Fix: Appropriate changes for autoWaitForIdle() were added. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From prem.balakrishnan at oracle.com Tue Sep 6 06:56:58 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 5 Sep 2016 23:56:58 -0700 (PDT) Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <42827df5-3948-ae9e-db4b-6c864d592457@oracle.com> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> <42827df5-3948-ae9e-db4b-6c864d592457@oracle.com> Message-ID: <377dffcc-4ab5-4629-9e06-39e2fff4abc0@default> Hi Alexandr, Thank you for the feedback. I have updated patch as per review comments. http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.01/ Regards, Prem From: Alexandr Scherbatiy Sent: Monday, September 05, 2016 3:50 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 1:00 PM, Prem Balakrishnan wrote: Hi Alexandr, Yes true, Setting getSnapToTicks() true will set block increment to minor/majorTickSpacing. But enabling getSanpToTicks will Disable Unit Increment (scrollByUnit using Up/Down Arrow keys ) It works in the following way before the fix: Use minor, major, or (max-min)/10 if snapToTicks is enabled. Use (max-min)/10 if snapToTicks is disabled. After the fix it works: Use minor or (max-min)/10 if snapToTicks is disabled. Why major tick spacing is not taken into account in this case in the same way as for the enabled snapToTicks? It seems that both minor and major tick spacing should be checked together. Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Friday, September 02, 2016 3:14 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the Review. > For the case there only majorTickSpacing is set should it be used for a block increment? When setSnapToTicks(Boolean value) is set to true, All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest tick(i.e., If minor Tick not set, it considers major Tick as the nearest tick). Based on my understanding, we need to set the minimum blockincrement size for PageUp/PageDown, which should be MinorTickSpacing if available. Where as if minorTickSpacing not Set and only MajorTickSpacing is set then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / 10] should be better. I see that the minorTickSpacing and majorTickSpacing are already used for the block increment in the BasicSliderUI.getTickSpacing() method when slider.getSnapToTicks() is enabled. May be a user just needs to set snapToTicks to true for a slider to get the desired block increment? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, September 01, 2016 8:46 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8009477 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ Cause: PageUp/PageDown key is used to scroll by block, MinorTickSpacing set by the user is not consider as the Block size. Fix: MinorTickSpacing(non-zero value) set by the user is set as Block size. For the case there only majorTickSpacing is set should it be used for a block increment? Thanks, Alexandr. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 6 10:18:17 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 6 Sep 2016 13:18:17 +0300 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display Message-ID: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8165485 webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 The icons drawing is changed to use ovals and polygons for JRadioButton, JCheckBox, JComboBox, and JScrollBar. The screenshots [1], [2], and [3] show difference between icons drawing before and after the fix for scales 1x, 2x, and 4x. [1] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png [2] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png [3] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Tue Sep 6 10:45:30 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 6 Sep 2016 13:45:30 +0300 Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <377dffcc-4ab5-4629-9e06-39e2fff4abc0@default> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> <42827df5-3948-ae9e-db4b-6c864d592457@oracle.com> <377dffcc-4ab5-4629-9e06-39e2fff4abc0@default> Message-ID: The fix looks good to me. Thanks, Alexandr. On 9/6/2016 9:56 AM, Prem Balakrishnan wrote: > > Hi Alexandr, > > Thank you for the feedback. > > I have updated patch as per review comments. > > http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.01/ > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Monday, September 05, 2016 3:50 PM > *To:* Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8009477 :PageUp and PageDown > keyboard buttons don't move slider indicator to next minor tick > > On 9/2/2016 1:00 PM, Prem Balakrishnan wrote: > > Hi Alexandr, > > Yes true, Setting getSnapToTicks() true will set block increment to > minor/majorTickSpacing. > > But enabling getSanpToTicks will Disable Unit Increment (scrollByUnit > using Up/Down Arrow keys ) > > > It works in the following way before the fix: > Use minor, major, or (max-min)/10 if snapToTicks is enabled. Use > (max-min)/10 if snapToTicks is disabled. > > After the fix it works: Use minor or (max-min)/10 if snapToTicks is > disabled. Why major tick spacing is not taken into account in this > case in the same way as for the enabled snapToTicks? It seems that > both minor and major tick spacing should be checked together. > > Thanks, > Alexandr. > > > Regards, > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Friday, September 02, 2016 3:14 PM > *To:* Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8009477 :PageUp and PageDown > keyboard buttons don't move slider indicator to next minor tick > > On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: > > > Hi Alexandr, > > Thankyou for the Review. > > > For the case there only majorTickSpacing is set should it be used for a > block increment? > > When setSnapToTicks(Boolean value) is set to true, > > All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest > tick(i.e., If minor Tick not set, it considers major Tick as the > nearest tick). > > Based on my understanding, we need to set the minimum blockincrement > size for PageUp/PageDown, which should be MinorTickSpacing if available. > > Where as if minorTickSpacing not Set and only MajorTickSpacing is set > then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / > 10] should be better. > > I see that the minorTickSpacing and majorTickSpacing are already > used for the block increment in the BasicSliderUI.getTickSpacing() > method when slider.getSnapToTicks() is enabled. May be a user just > needs to set snapToTicks to true for a slider to get the desired block > increment? > > Thanks, > Alexandr. > > > > Regards, > > Prem > > *From:*Alexandr Scherbatiy > *Sent:* Thursday, September 01, 2016 8:46 PM > *To:* Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request: JDK-8009477 :PageUp and PageDown > keyboard buttons don't move slider indicator to next minor tick > > On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: > > > > Hi*,* > > Please review fix for JDK 9, > > *Bug:*https://bugs.openjdk.java.net/browse/JDK-8009477 > > *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ > > > *Cause:*PageUp/PageDown key is used to scroll by block, > > MinorTickSpacing set by the user is not consider as the Block size. > > *Fix:* MinorTickSpacing(non-zero value) set by the user is set as > Block size. > > For the case there only majorTickSpacing is set should it be used > for a block increment? > > Thanks, > Alexandr. > > > > Regards, > > Prem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 6 10:46:21 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 6 Sep 2016 13:46:21 +0300 Subject: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java In-Reply-To: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> References: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> Message-ID: <676bc75a-de22-402d-1b6c-acb6ed115fb8@oracle.com> The fix looks good to me. Thanks, Alexandr. On 9/6/2016 9:12 AM, Avik Niyogi wrote: > Hi All, > > Kindly review the fix for JDK9. > > *Bug: https://bugs.openjdk.java.net/browse/JDK-8163274* > > *Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ > * > > *Issue: *This test javax/swing/JColorChooser/Test7194184.java throws > exception due to event delay. > > *Cause: * Delay for event idling was not added. > > *Fix:* Appropriate changes for autoWaitForIdle() were added. > > With Regards, > Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Sep 6 15:10:48 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 6 Sep 2016 18:10:48 +0300 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> Message-ID: <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> It seems that there are some small artifacts on some of the components, please take a look to the corners of the selected checkbox. In 1x the corners have correct edges but in x2,x4 there are some missing pixels. Similar issue is in the text area(take a look to the white border). On 06.09.16 13:18, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8165485 > webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 > > The icons drawing is changed to use ovals and polygons for > JRadioButton, JCheckBox, JComboBox, and JScrollBar. > > The screenshots [1], [2], and [3] show difference between icons > drawing before and after the fix for scales 1x, 2x, and 4x. > > [1] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png > [2] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png > [3] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png > > Thanks, > Alexandr. > > -- Best regards, Sergey. From ambarish.rapte at oracle.com Tue Sep 6 15:21:21 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 6 Sep 2016 08:21:21 -0700 (PDT) Subject: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java In-Reply-To: References: <680be17d-32e9-4765-99dd-f4ae65d48c9a@default> <6de9c6cb-814a-485d-b36e-c7e3bdbac075@default> <284feaa1-14af-4111-bb17-e652ccb72e05@default> <2966a7ef-cf7c-7426-4fd9-68b976cb0696@oracle.com> <43517154-6fc9-40fe-b1c4-218298f30556@default> Message-ID: <4772766f-74ba-48be-a739-d8b5280c1b87@default> Hi Alex, 1. There will be only one key value pair entry in the cacheMap. The CachedPainter.paint0() method uses getClass() as a key for the cacheMap. At least there should be more than 1 key (getClass() + PainterMultiResolutionCachedImage.class). Sorry for the confusion here, I meant, there will be only one key value pair entry in cacheMap for all PainterMultiResolutionCachedImage images. As you mentioned there will be entries for other classes as well. Could the image cache size be increased only for the PainterMultiResolutionCachedImage.class key in the approach 2 because other keys may require only one image? Please review the updated webrev modified as you guided, http://cr.openjdk.java.net/~arapte/8163261/webrev.04/ Regards, Ambarish From: Alexandr Scherbatiy Sent: Monday, September 05, 2016 3:40 PM To: Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java On 9/2/2016 7:18 AM, Ambarish Rapte wrote: Hi Alex, Thanks for the review comments, Yes, we can use the PainterMultiResolutionCachedImage.class object as a key in the PainterMultiResolutionCachedImage.getResolutionVariant() method. But there is below concern, 2. If PainterMultiResolutionCachedImage.class object is used as key in Map cacheMap; 3. There will be only one key value pair entry in the cacheMap. The CachedPainter.paint0() method uses getClass() as a key for the cacheMap. At least there should be more than 1 key (getClass() + PainterMultiResolutionCachedImage.class). 4. The ImageCache value created for the PainterMultiResolutionCachedImage class is only of size 1. 5. Hence there will be only one image present at a time in the cacheMap. 6. Each time a new image is added, previous one will get deleted. In method: ImageCache::getEntry() => if (entries.size() >= maxCount) { entries.removeLast(); } 7. This will result repeated deletion and creation of images. This requires increase in the size of ImageCache associated with PainterMultiResolutionCachedImage.class key to a certain justified value. For example, we can set the value to 8, so that at a time 8 images can be stored in the ImageCache. So for to add 9th entry, last image would be removed. I am not sure what this value can be. I think this value can be number of components. SwinSet2 demo creates 17+ such images. After deciding a good value, this change can be done, a lesser value may add to processing by re-creating images. Currently we have 2 approaches: Approach1: PainterMultiResolutionCachedImage object as key, with hashCode() & equals() method. HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.02/"http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ Approach2: PainterMultiResolutionCachedImage.class object as key, with a good justified size of ImageCache. HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.03/"http://cr.openjdk.java.net/~arapte/8163261/webrev.03/ Could the image cache size be increased only for the PainterMultiResolutionCachedImage.class key in the approach 2 because other keys may require only one image? Thanks, Alexandr. BOTH the approach would result in creating same number of creating images, in a normal scenario. however depending of GC/OOM this can change, as we have soft references to images. I observed over a long run of SwingSet2, Approach2 creates less number of images, but Approach1 recreates images. Another difference would be, Approach1 will add pair entries to Map cacheMap. & Approach2 will add only ONE pair entry to Map cacheMap; But add entries to associated ImageCache. I think, approach 2 can be used with a justified size of ImageCache. In webrev.03 it is 32. Please provide, your comments. Regards, Ambarish From: Alexandr Scherbatiy Sent: Monday, August 29, 2016 6:09 PM To: Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java CachedPainter.paint0() uses the object returned by getClass() as a key for the cache. Is it possible to use PainterMultiResolutionCachedImage.class object as a key in the PainterMultiResolutionCachedImage.getResolutionVariant() method? Thanks, Alexandr. On 8/26/2016 1:34 PM, Ambarish Rapte wrote: Hi Alex & All, Please review the updated webrev : HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.02/"http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ Changes: (Copying from the previous email) I have included the change you suggested, to set component reference null after painting the component. In addition there is change in PainterMultiResolutionCachedImage to add hashCode() & equals() methods. Object of PainterMultiResolutionCachedImage is used as key in the Map cacheMap. hashCode() & equals() would avoid multiple entries of similar image objects in the cacheMap & help reduce the size of cacheMap. Verified this change by executing the SwinSet2 demo, all components get painted correctly. Also a small change in test, added check on panel reference and modified error message. Regards, Ambarish From: Ambarish Rapte Sent: Friday, August 26, 2016 12:34 PM To: Ambarish Rapte; Alexander Scherbatiy; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: RE: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java Hi All, Please hold the review for this. There are some merge conflicts with latest code so I shall update the webrev again for review. Regards, Ambarish From: Ambarish Rapte Sent: Thursday, August 25, 2016 10:19 PM To: Alexander Scherbatiy; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java Hi Alex, Thanks for the review comments, Please review the updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.01/"http://cr.openjdk.java.net/~arapte/8163261/webrev.01/ I have included the change you suggested, to set component reference null after painting the component. In addition there is change in PainterMultiResolutionCachedImage to add hashCode() & equals() methods. Object of PainterMultiResolutionCachedImage is used as key in the Map cacheMap. hashCode() & equals() would avoid multiple entries of similar image objects in the cacheMap & help reduce the size of cacheMap. Verified this change by executing the SwinSet2 demo, all components get painted correctly. Also a small change in test, added check on panel reference and modified error message. Regards, Ambarish From: Alexander Scherbatiy Sent: Monday, August 22, 2016 5:47 PM To: Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java On 17/08/16 15:49, Alexandr Scherbatiy wrote: On 8/15/2016 12:43 PM, Ambarish Rapte wrote: Hi, Please review fix for JDK9, Bug: https://bugs.openjdk.java.net/browse/JDK-8163261 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Earapte/8163261/webrev.00/"http://cr.openjdk.java.net/~arapte/8163261/webrev.00/ Issue: Reference to JButton was not getting collected by GC. Cause: A strong reference to objects was held by PainterMultiResolutionCachedImage. And the image reference was held by HashMap. Fix: Changing the HashMap to WeakHashMap. Entry to WeakHashMap gets removed after the object has no other strong reference. May be using the soft reference would be better in this case. It could be expensive to recreate a cache with images every time GC removed them. There is the code which sets a component to the PainterMultiResolutionCachedImage: CachedPainter.paint0(...) ------- if (image instanceof PainterMultiResolutionCachedImage) { ((PainterMultiResolutionCachedImage) image).setParams(c, args); } // Render to the passed in Graphics paintImage(c, g, x, y, w, h, image, args); ------- May be it is possible to clean up the component and args from the PainterMultiResolutionCachedImage after the image is drawn? Thanks, Alexandr. Regards, Ambarish -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 6 15:33:27 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 6 Sep 2016 18:33:27 +0300 Subject: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java In-Reply-To: <4772766f-74ba-48be-a739-d8b5280c1b87@default> References: <680be17d-32e9-4765-99dd-f4ae65d48c9a@default> <6de9c6cb-814a-485d-b36e-c7e3bdbac075@default> <284feaa1-14af-4111-bb17-e652ccb72e05@default> <2966a7ef-cf7c-7426-4fd9-68b976cb0696@oracle.com> <43517154-6fc9-40fe-b1c4-218298f30556@default> <4772766f-74ba-48be-a739-d8b5280c1b87@default> Message-ID: The fix looks good to me. Thanks, Alexandr. On 9/6/2016 6:21 PM, Ambarish Rapte wrote: > > Hi Alex, > > 1.There will be only one key value pair entry in the /cacheMap/. > > The CachedPainter.paint0() method uses getClass() as a key for the > cacheMap. At least there should be more than 1 key (getClass() + > PainterMultiResolutionCachedImage.class). > > Sorry for the confusion here, I meant, there will be only one key > value pair entry in cacheMap for all PainterMultiResolutionCachedImage > images. > > As you mentioned there will be entries for other classes as well. > > Could the image cache size be increased only for the > PainterMultiResolutionCachedImage.class key in the approach 2 because > other keys may require only one image? > Please review the updated webrev modified as you guided, > > http://cr.openjdk.java.net/~arapte/8163261/webrev.04/ > > > Regards, > > Ambarish > > *From:*Alexandr Scherbatiy > *Sent:* Monday, September 05, 2016 3:40 PM > *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request for 8163261: regression on > Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > On 9/2/2016 7:18 AM, Ambarish Rapte wrote: > > Hi Alex, > > Thanks for the review comments, > > Yes, we can use thePainterMultiResolutionCachedImage.class object as a > key in the PainterMultiResolutionCachedImage.getResolutionVariant() > method. > > But there is below concern, > > 2.If PainterMultiResolutionCachedImage.class object is used as key in > /Map cacheMap;/ > > 3.There will be only one key value pair entry in the /cacheMap/. > > The CachedPainter.paint0() method uses getClass() as a key for the > cacheMap. At least there should be more than 1 key (getClass() + > PainterMultiResolutionCachedImage.class). > > > 4.The /ImageCache/ value created for the > /PainterMultiResolutionCachedImage class/ is only of size 1. > > 5.Hence there will be only one image present at a time in the /cacheMap/. > > 6.Each time a new image is added, previous one will get deleted. > In method: /ImageCache::getEntry() => if (entries.size() >= > maxCount) { entries.removeLast(); }/ > > 7.This will result repeated deletion and creation of images. > > This requires increase in the size of /ImageCache /associated > with/PainterMultiResolutionCachedImage.class /key to a certain > justified value. > > For example, we can set the value to 8, so that at a time 8 images can > be stored in the /ImageCache/. So for to add 9^th entry, last image > would be removed. > > I am not sure what this value can be. I think this value can be number > of components. > > SwinSet2 demo creates 17+ such images. > > After deciding a good value, this change can be done, a lesser value > may add to processing by re-creating images. > > Currently we have 2 approaches: > > Approach1: /PainterMultiResolutionCachedImage /object as key, > with/hashCode() & equals() /method/. > /http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ > > > Approach2: /PainterMultiResolutionCachedImage.class /object//as key, > with a good justified size of/ImageCache. > /http://cr.openjdk.java.net/~arapte/8163261/webrev.03/ > > > Could the image cache size be increased only for the > PainterMultiResolutionCachedImage.class key in the approach 2 because > other keys may require only one image? > > Thanks, > Alexandr. > > // > > BOTH the approach would result in creating same number of creating > images, in a normal scenario. > > however depending of GC/OOM this can change, as we have soft > references to images. > > I observed over a long run of SwingSet2, Approach2 creates less number > of images, but Approach1 recreates images. > > Another difference would be, > > Approach1 will add pair entries to /Map ImageCache> cacheMap/. > > & > > Approach2 will add only ONE pair entry to /Map ImageCache> cacheMap;/ But add entries to associated /ImageCache/. > > I think, approach 2 can be used with a justified size of ImageCache. > In webrev.03 it is 32. > > Please provide, your comments. > > Regards, > > Ambarish > > *From:*Alexandr Scherbatiy > *Sent:* Monday, August 29, 2016 6:09 PM > *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request for 8163261: regression on > Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > > CachedPainter.paint0() uses the object returned by getClass() as a key > for the cache. > Is it possible to use PainterMultiResolutionCachedImage.class object > as a key in the > PainterMultiResolutionCachedImage.getResolutionVariant() method? > > Thanks, > Alexandr. > > On 8/26/2016 1:34 PM, Ambarish Rapte wrote: > > Hi Alex & All, > > Please review the updated webrev : > http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ > > > Changes: (Copying from the previous email) > > I have included the change you suggested, to set component > reference null after painting the component. > > In addition there is change in PainterMultiResolutionCachedImage > to add /hashCode()/ & /equals()/ methods. > > Object of /PainterMultiResolutionCachedImage/ is used as key in > the /Map cacheMap./ > > /hashCode()/ & /equals()/ would avoid multiple entries of similar > image objects in the /cacheMap/ & help reduce the size of /cacheMap./ > > // > > Verified this change by executing the /SwinSet2/ demo, all > components get painted correctly. > > Also a small change in test, added check on panel reference and > modified error message. > > Regards, > > Ambarish > > *From:*Ambarish Rapte > *Sent:* Friday, August 26, 2016 12:34 PM > *To:* Ambarish Rapte; Alexander Scherbatiy; Sergey Bylokhov; > Rajeev Chamyal; swing-dev at openjdk.java.net > > *Subject:* RE: Review Request for 8163261: regression > on Linux: > java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > Hi All, > > Please hold the review for this. > > There are some merge conflicts with latest code so I shall update > the webrev again for review. > > Regards, > > Ambarish > > *From:*Ambarish Rapte > *Sent:* Thursday, August 25, 2016 10:19 PM > *To:* Alexander Scherbatiy; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request for 8163261: regression > on Linux: > java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > Hi Alex, > > Thanks for the review comments, > > Please review the updated webrev: > http://cr.openjdk.java.net/~arapte/8163261/webrev.01/ > > > I have included the change you suggested, to set component > reference null after painting the component. > > In addition there is change in PainterMultiResolutionCachedImage > to add /hashCode()/ & /equals()/ methods. > > Object of /PainterMultiResolutionCachedImage/ is used as key in > the /Map cacheMap./ > > /hashCode()/ & /equals()/ would avoid multiple entries of similar > image objects in the /cacheMap/ & help reduce the size of /cacheMap./ > > // > > Verified this change by executing the /SwinSet2/ demo, all > components get painted correctly. > > Also a small change in test, added check on panel reference and > modified error message. > > Regards, > > Ambarish > > *From:*Alexander Scherbatiy > *Sent:* Monday, August 22, 2016 5:47 PM > *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; > swing-dev at openjdk.java.net > *Subject:* Re: Review Request for 8163261: regression > on Linux: > java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java > > > On 17/08/16 15:49, Alexandr Scherbatiy wrote: > > On 8/15/2016 12:43 PM, Ambarish Rapte wrote: > > Hi, > > Please review fix for JDK9, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163261 > > Webrev: > http://cr.openjdk.java.net/~arapte/8163261/webrev.00/ > > > Issue: > > Reference to JButton was not getting collected by GC. > > Cause: > > A strong reference to objects was held by > PainterMultiResolutionCachedImage. > > And the image reference was held by HashMap. > > Fix: > > Changing the HashMap to WeakHashMap. Entry to > WeakHashMap gets removed after the object has no other strong > reference. > > May be using the soft reference would be better in this case. > It could be expensive to recreate a cache with images every time > GC removed them. > > > There is the code which sets a component to the > PainterMultiResolutionCachedImage: > CachedPainter.paint0(...) > ------- > if (image instanceof PainterMultiResolutionCachedImage) { > ((PainterMultiResolutionCachedImage) > image).setParams(c, args); > } > > // Render to the passed in Graphics > paintImage(c, g, x, y, w, h, image, args); > ------- > > May be it is possible to clean up the component and args from the > PainterMultiResolutionCachedImage after the image is drawn? > > > Thanks, > Alexandr. > > Regards, > > Ambarish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Wed Sep 7 05:33:06 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 6 Sep 2016 22:33:06 -0700 (PDT) Subject: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java In-Reply-To: <676bc75a-de22-402d-1b6c-acb6ed115fb8@oracle.com> References: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> <676bc75a-de22-402d-1b6c-acb6ed115fb8@oracle.com> Message-ID: <217dd140-4a4c-465d-bb9e-85b272ebb6fd@default> Looks good to me. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 06 September 2016 16:16 To: Avik Niyogi; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java The fix looks good to me. Thanks, Alexandr. On 9/6/2016 9:12 AM, Avik Niyogi wrote: Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8163274 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8163274/webrev.00/"http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ Issue: This test javax/swing/JColorChooser/Test7194184.java throws exception due to event delay. Cause: Delay for event idling was not added. Fix: Appropriate changes for autoWaitForIdle() were added. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Wed Sep 7 06:02:48 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 7 Sep 2016 11:32:48 +0530 Subject: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java In-Reply-To: <217dd140-4a4c-465d-bb9e-85b272ebb6fd@default> References: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> <676bc75a-de22-402d-1b6c-acb6ed115fb8@oracle.com> <217dd140-4a4c-465d-bb9e-85b272ebb6fd@default> Message-ID: <91F3AAEA-7346-4413-BB12-4BCCA7BB62AD@oracle.com> Hi All, Kindly review the updated fix for JDK9 with new inputs incorporated. Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.01/ With Regards, Avik Niyogi > On 07-Sep-2016, at 11:03 am, Rajeev Chamyal wrote: > > Looks good to me. > > Regards, > Rajeev Chamyal > > From: Alexandr Scherbatiy > Sent: 06 September 2016 16:16 > To: Avik Niyogi; Rajeev Chamyal; swing-dev at openjdk.java.net > Subject: Re: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java > > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/6/2016 9:12 AM, Avik Niyogi wrote: > Hi All, > > Kindly review the fix for JDK9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163274 > > Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ > > Issue: This test javax/swing/JColorChooser/Test7194184.java throws exception due to event delay. > > Cause: Delay for event idling was not added. > > Fix: Appropriate changes for autoWaitForIdle() were added. > > With Regards, > Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Sep 7 12:10:53 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 7 Sep 2016 15:10:53 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display Message-ID: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8165594 webrev: http://cr.openjdk.java.net/~alexsch/8165594/webrev.00 The icons drawing is changed to use ovals and polygons for JRadioButton, JCheckBox, JComboBox, and JScrollBar. The screenshots [1], [2], and [3] shows difference between icons drawing before and after the fix for scales 1x, 2x, and 4x. [1] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png [2] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png [3] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Wed Sep 7 16:19:58 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 7 Sep 2016 19:19:58 +0300 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> Message-ID: <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> On 9/6/2016 6:10 PM, Sergey Bylokhov wrote: > It seems that there are some small artifacts on some of the > components, please take a look to the corners of the selected > checkbox. In 1x the corners have correct edges but in x2,x4 there are > some missing pixels. Similar issue is in the text area(take a look to > the white border). Links [1], [2], and [3] shows drawing the scroll bar buttons using different types of a line ends decoration (cap, round, and square). All of them have one or another drawing artifact with scales 2 and 4. [1] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-butt.png [2] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-round.png [3] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-square.png Thanks, Alexandr. > > On 06.09.16 13:18, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8165485 >> webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 >> >> The icons drawing is changed to use ovals and polygons for >> JRadioButton, JCheckBox, JComboBox, and JScrollBar. >> >> The screenshots [1], [2], and [3] show difference between icons >> drawing before and after the fix for scales 1x, 2x, and 4x. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png >> >> [2] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png >> >> [3] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png >> >> >> Thanks, >> Alexandr. >> >> > > From alexandr.scherbatiy at oracle.com Wed Sep 7 16:20:34 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 7 Sep 2016 19:20:34 +0300 Subject: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java In-Reply-To: <91F3AAEA-7346-4413-BB12-4BCCA7BB62AD@oracle.com> References: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> <676bc75a-de22-402d-1b6c-acb6ed115fb8@oracle.com> <217dd140-4a4c-465d-bb9e-85b272ebb6fd@default> <91F3AAEA-7346-4413-BB12-4BCCA7BB62AD@oracle.com> Message-ID: <9168fab8-ed0a-cdc2-2177-7223200f436d@oracle.com> The fix looks good to me. Thanks, Alexandr. On 9/7/2016 9:02 AM, Avik Niyogi wrote: > Hi All, > Kindly review the updated fix for JDK9 with new inputs incorporated. > *Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.01/ > * > > With Regards, > Avik Niyogi > >> On 07-Sep-2016, at 11:03 am, Rajeev Chamyal >> > wrote: >> >> Looks good to me. >> Regards, >> Rajeev Chamyal >> *From:*Alexandr Scherbatiy >> *Sent:*06 September 2016 16:16 >> *To:*Avik Niyogi; Rajeev Chamyal; swing-dev at openjdk.java.net >> >> *Subject:*Re: 8163274: [TEST_BUG][macosx] apparent >> regression: javax/swing/JColorChooser/Test7194184.java >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 9/6/2016 9:12 AM, Avik Niyogi wrote: >> >> Hi All, >> Kindly review the fix for JDK9. >> *Bug: https://bugs.openjdk.java.net/browse/JDK-8163274* >> *Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ >> * >> *Issue: *This >> test javax/swing/JColorChooser/Test7194184.java throws exception >> due to event delay. >> *Cause: * Delay for event idling was not added. >> *Fix:* Appropriate changes for autoWaitForIdle() were added. >> With Regards, >> Avik Niyogi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Sep 7 16:54:03 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 7 Sep 2016 09:54:03 -0700 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> Message-ID: <75b22fb4-b7c5-5414-2258-7b28ed09edbd@oracle.com> drawPolyline does not seem to be an option here because of the different colours. Filling custom shapes may be overkill. Round looks to me to be the best of these three. -phil. On 9/7/2016 9:19 AM, Alexandr Scherbatiy wrote: > On 9/6/2016 6:10 PM, Sergey Bylokhov wrote: >> It seems that there are some small artifacts on some of the >> components, please take a look to the corners of the selected >> checkbox. In 1x the corners have correct edges but in x2,x4 there are >> some missing pixels. Similar issue is in the text area(take a look to >> the white border). > Links [1], [2], and [3] shows drawing the scroll bar buttons using > different types of a line ends decoration (cap, round, and square). > All of them have one or another drawing artifact with scales 2 and 4. > > [1] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-butt.png > [2] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-round.png > [3] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-square.png > > Thanks, > Alexandr. >> >> On 06.09.16 13:18, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8165485 >>> webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 >>> >>> The icons drawing is changed to use ovals and polygons for >>> JRadioButton, JCheckBox, JComboBox, and JScrollBar. >>> >>> The screenshots [1], [2], and [3] show difference between icons >>> drawing before and after the fix for scales 1x, 2x, and 4x. >>> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png >>> >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png >>> >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png >>> >>> >>> Thanks, >>> Alexandr. >>> >>> >> >> > From alexandr.scherbatiy at oracle.com Wed Sep 7 17:43:00 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 7 Sep 2016 20:43:00 +0300 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: <75b22fb4-b7c5-5414-2258-7b28ed09edbd@oracle.com> References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> <75b22fb4-b7c5-5414-2258-7b28ed09edbd@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8165485/webrev.01 Round line end decoration is used to draw combo box and scroll bar icons. [1], [2], and [3] screenshots show difference between icons drawing before and after the fix for scales 1x, 2x, and 4x. [1] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_01.png [2] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_01.png [3] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_01.png Thanks, Alexandr. On 9/7/2016 7:54 PM, Phil Race wrote: > drawPolyline does not seem to be an option here because of the > different colours. > Filling custom shapes may be overkill. Round looks to me to be the > best of these three. > > -phil. > > > On 9/7/2016 9:19 AM, Alexandr Scherbatiy wrote: >> On 9/6/2016 6:10 PM, Sergey Bylokhov wrote: >>> It seems that there are some small artifacts on some of the >>> components, please take a look to the corners of the selected >>> checkbox. In 1x the corners have correct edges but in x2,x4 there >>> are some missing pixels. Similar issue is in the text area(take a >>> look to the white border). >> Links [1], [2], and [3] shows drawing the scroll bar buttons using >> different types of a line ends decoration (cap, round, and square). >> All of them have one or another drawing artifact with scales 2 and 4. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-butt.png >> [2] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-round.png >> [3] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-square.png >> >> Thanks, >> Alexandr. >>> >>> On 06.09.16 13:18, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165485 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 >>>> >>>> The icons drawing is changed to use ovals and polygons for >>>> JRadioButton, JCheckBox, JComboBox, and JScrollBar. >>>> >>>> The screenshots [1], [2], and [3] show difference between icons >>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png >>>> >>>> [2] >>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png >>>> >>>> [3] >>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png >>>> >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>> >>> >> > From avik.niyogi at oracle.com Thu Sep 8 05:29:47 2016 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Thu, 8 Sep 2016 10:59:47 +0530 Subject: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java In-Reply-To: <9168fab8-ed0a-cdc2-2177-7223200f436d@oracle.com> References: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> <676bc75a-de22-402d-1b6c-acb6ed115fb8@oracle.com> <217dd140-4a4c-465d-bb9e-85b272ebb6fd@default> <91F3AAEA-7346-4413-BB12-4BCCA7BB62AD@oracle.com> <9168fab8-ed0a-cdc2-2177-7223200f436d@oracle.com> Message-ID: A gentle reminder, please review code changes as indicated in new webrev. With Regards, Avik Niyogi > On 07-Sep-2016, at 9:50 pm, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/7/2016 9:02 AM, Avik Niyogi wrote: >> Hi All, >> Kindly review the updated fix for JDK9 with new inputs incorporated. >> Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.01/ >> >> With Regards, >> Avik Niyogi >> >>> On 07-Sep-2016, at 11:03 am, Rajeev Chamyal > wrote: >>> >>> Looks good to me. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> From: Alexandr Scherbatiy >>> Sent: 06 September 2016 16:16 >>> To: Avik Niyogi; Rajeev Chamyal; swing-dev at openjdk.java.net >>> Subject: Re: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/6/2016 9:12 AM, Avik Niyogi wrote: >>> Hi All, >>> >>> Kindly review the fix for JDK9. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163274 >>> >>> Webrev: http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ >>> >>> Issue: This test javax/swing/JColorChooser/Test7194184.java throws exception due to event delay. >>> >>> Cause: Delay for event idling was not added. >>> >>> Fix: Appropriate changes for autoWaitForIdle() were added. >>> >>> With Regards, >>> Avik Niyogi >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Sep 8 05:41:36 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 7 Sep 2016 22:41:36 -0700 (PDT) Subject: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java In-Reply-To: References: <746F377B-62AE-4FB4-BFFF-D5406603194A@oracle.com> <676bc75a-de22-402d-1b6c-acb6ed115fb8@oracle.com> <217dd140-4a4c-465d-bb9e-85b272ebb6fd@default> <91F3AAEA-7346-4413-BB12-4BCCA7BB62AD@oracle.com> <9168fab8-ed0a-cdc2-2177-7223200f436d@oracle.com> Message-ID: <80385b3c-9ecb-4604-b7a9-04fd0f6aeccd@default> Looks good to me. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 08 September 2016 11:00 To: Rajeev Chamyal Cc: Alexandr Scherbatiy; swing-dev at openjdk.java.net Subject: Re: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java A gentle reminder, please review code changes as indicated in new webrev. With Regards, Avik Niyogi On 07-Sep-2016, at 9:50 pm, Alexandr Scherbatiy wrote: The fix looks good to me. Thanks, Alexandr. On 9/7/2016 9:02 AM, Avik Niyogi wrote: Hi All, Kindly review the updated fix for JDK9 with new inputs incorporated. Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8163274/webrev.01/"http://cr.openjdk.java.net/~aniyogi/8163274/webrev.01/ With Regards, Avik Niyogi On 07-Sep-2016, at 11:03 am, Rajeev Chamyal wrote: Looks good to me. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 06 September 2016 16:16 To: Avik Niyogi; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: 8163274: [TEST_BUG][macosx] apparent regression: javax/swing/JColorChooser/Test7194184.java The fix looks good to me. Thanks, Alexandr. On 9/6/2016 9:12 AM, Avik Niyogi wrote: Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8163274 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eaniyogi/8163274/webrev.00/"http://cr.openjdk.java.net/~aniyogi/8163274/webrev.00/ Issue: This test javax/swing/JColorChooser/Test7194184.java throws exception due to event delay. Cause: Delay for event idling was not added. Fix: Appropriate changes for autoWaitForIdle() were added. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Thu Sep 8 07:59:38 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 8 Sep 2016 09:59:38 +0200 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> Message-ID: Hi Alexandr, > [1] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png The icons do not look right to me. Take look at the top-left part of the radio button. There is a white pixel between the shadow lines. And in the selected state there should be a black circle. But instead it is a square. The check sign of the checkbox is too thin. And the arrows of the combobox and the vertical scroll bar should have a single pixel at the top/bottom side. But now they have two pixels. It would be also nice to see a screen shot of the native Windows components for comparison. Personally when I would make changes like that, then my code would look like this: if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { // use the old good code. } else { // use the new code } Best regards, Andrej Golovnin > [2] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png > [3] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png > > Thanks, > Alexandr. > > From andrej.golovnin at gmail.com Thu Sep 8 08:09:00 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 8 Sep 2016 10:09:00 +0200 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> <75b22fb4-b7c5-5414-2258-7b28ed09edbd@oracle.com> Message-ID: Hi Alexandr, > [1] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_01.png > [2] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_01.png > [3] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_01.png The combobox icon does not look right for me. The shadow line goes to far at the top. Best regards, Andrej Golovnin From ajit.ghaisas at oracle.com Thu Sep 8 12:17:20 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 8 Sep 2016 05:17:20 -0700 (PDT) Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> <42827df5-3948-ae9e-db4b-6c864d592457@oracle.com> <377dffcc-4ab5-4629-9e06-39e2fff4abc0@default> Message-ID: <31618f67-5e3c-472a-ba04-56193d6062e0@default> Fix as such is fine. But, webrev needs update to address : 1. There are few typos (words : moves, previous) in test instructions. 2. A timeout can be added to the test - this will address the case when user does not press either pass or fail button 3. Please rename the test as not to contain bugID in filename. Use a meaningful name as test name. Regards, Ajit From: Alexandr Scherbatiy Sent: Tuesday, September 06, 2016 4:16 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick The fix looks good to me. Thanks, Alexandr. On 9/6/2016 9:56 AM, Prem Balakrishnan wrote: Hi Alexandr, Thank you for the feedback. I have updated patch as per review comments. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.01/ Regards, Prem From: Alexandr Scherbatiy Sent: Monday, September 05, 2016 3:50 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 1:00 PM, Prem Balakrishnan wrote: Hi Alexandr, Yes true, Setting getSnapToTicks() true will set block increment to minor/majorTickSpacing. But enabling getSanpToTicks will Disable Unit Increment (scrollByUnit using Up/Down Arrow keys ) It works in the following way before the fix: Use minor, major, or (max-min)/10 if snapToTicks is enabled. Use (max-min)/10 if snapToTicks is disabled. After the fix it works: Use minor or (max-min)/10 if snapToTicks is disabled. Why major tick spacing is not taken into account in this case in the same way as for the enabled snapToTicks? It seems that both minor and major tick spacing should be checked together. Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Friday, September 02, 2016 3:14 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the Review. > For the case there only majorTickSpacing is set should it be used for a block increment? When setSnapToTicks(Boolean value) is set to true, All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest tick(i.e., If minor Tick not set, it considers major Tick as the nearest tick). Based on my understanding, we need to set the minimum blockincrement size for PageUp/PageDown, which should be MinorTickSpacing if available. Where as if minorTickSpacing not Set and only MajorTickSpacing is set then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / 10] should be better. I see that the minorTickSpacing and majorTickSpacing are already used for the block increment in the BasicSliderUI.getTickSpacing() method when slider.getSnapToTicks() is enabled. May be a user just needs to set snapToTicks to true for a slider to get the desired block increment? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, September 01, 2016 8:46 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8009477 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ Cause: PageUp/PageDown key is used to scroll by block, MinorTickSpacing set by the user is not consider as the Block size. Fix: MinorTickSpacing(non-zero value) set by the user is set as Block size. For the case there only majorTickSpacing is set should it be used for a block increment? Thanks, Alexandr. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From prem.balakrishnan at oracle.com Thu Sep 8 13:41:36 2016 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 8 Sep 2016 06:41:36 -0700 (PDT) Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <31618f67-5e3c-472a-ba04-56193d6062e0@default> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> <42827df5-3948-ae9e-db4b-6c864d592457@oracle.com> <377dffcc-4ab5-4629-9e06-39e2fff4abc0@default> <31618f67-5e3c-472a-ba04-56193d6062e0@default> Message-ID: <9379a93c-b919-4495-897b-04e6ece1030e@default> Hi Ajit, Thank you for the feedback. I have updated patch as per review comments. http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.02/ Regards, Prem From: Ajit Ghaisas Sent: Thursday, September 08, 2016 5:47 PM To: Alexander Scherbatiy; Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: RE: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick Fix as such is fine. But, webrev needs update to address : 1. There are few typos (words : moves, previous) in test instructions. 2. A timeout can be added to the test - this will address the case when user does not press either pass or fail button 3. Please rename the test as not to contain bugID in filename. Use a meaningful name as test name. Regards, Ajit From: Alexandr Scherbatiy Sent: Tuesday, September 06, 2016 4:16 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick The fix looks good to me. Thanks, Alexandr. On 9/6/2016 9:56 AM, Prem Balakrishnan wrote: Hi Alexandr, Thank you for the feedback. I have updated patch as per review comments. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.01/ Regards, Prem From: Alexandr Scherbatiy Sent: Monday, September 05, 2016 3:50 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 1:00 PM, Prem Balakrishnan wrote: Hi Alexandr, Yes true, Setting getSnapToTicks() true will set block increment to minor/majorTickSpacing. But enabling getSanpToTicks will Disable Unit Increment (scrollByUnit using Up/Down Arrow keys ) It works in the following way before the fix: Use minor, major, or (max-min)/10 if snapToTicks is enabled. Use (max-min)/10 if snapToTicks is disabled. After the fix it works: Use minor or (max-min)/10 if snapToTicks is disabled. Why major tick spacing is not taken into account in this case in the same way as for the enabled snapToTicks? It seems that both minor and major tick spacing should be checked together. Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Friday, September 02, 2016 3:14 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the Review. > For the case there only majorTickSpacing is set should it be used for a block increment? When setSnapToTicks(Boolean value) is set to true, All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest tick(i.e., If minor Tick not set, it considers major Tick as the nearest tick). Based on my understanding, we need to set the minimum blockincrement size for PageUp/PageDown, which should be MinorTickSpacing if available. Where as if minorTickSpacing not Set and only MajorTickSpacing is set then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / 10] should be better. I see that the minorTickSpacing and majorTickSpacing are already used for the block increment in the BasicSliderUI.getTickSpacing() method when slider.getSnapToTicks() is enabled. May be a user just needs to set snapToTicks to true for a slider to get the desired block increment? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, September 01, 2016 8:46 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8009477 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ Cause: PageUp/PageDown key is used to scroll by block, MinorTickSpacing set by the user is not consider as the Block size. Fix: MinorTickSpacing(non-zero value) set by the user is set as Block size. For the case there only majorTickSpacing is set should it be used for a block increment? Thanks, Alexandr. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Sep 8 19:52:24 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 8 Sep 2016 22:52:24 +0300 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> <75b22fb4-b7c5-5414-2258-7b28ed09edbd@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8165485/webrev.02 - shadow lines are updated - round line end decoration is changed to draw just a point [1], [2], and [3] screenshots show difference between icons drawing before and after the fix for scales 1x, 2x, and 4x. [1] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_02.png [2] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_02.png [3] http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_02.png Thanks, Alexandr. On 9/7/2016 8:43 PM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165485/webrev.01 > > Round line end decoration is used to draw combo box and scroll bar > icons. > > [1], [2], and [3] screenshots show difference between icons > drawing before and after the fix for scales 1x, 2x, and 4x. > > [1] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_01.png > [2] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_01.png > [3] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_01.png > > Thanks, > Alexandr. > > On 9/7/2016 7:54 PM, Phil Race wrote: >> drawPolyline does not seem to be an option here because of the >> different colours. >> Filling custom shapes may be overkill. Round looks to me to be the >> best of these three. >> >> -phil. >> >> >> On 9/7/2016 9:19 AM, Alexandr Scherbatiy wrote: >>> On 9/6/2016 6:10 PM, Sergey Bylokhov wrote: >>>> It seems that there are some small artifacts on some of the >>>> components, please take a look to the corners of the selected >>>> checkbox. In 1x the corners have correct edges but in x2,x4 there >>>> are some missing pixels. Similar issue is in the text area(take a >>>> look to the white border). >>> Links [1], [2], and [3] shows drawing the scroll bar buttons using >>> different types of a line ends decoration (cap, round, and square). >>> All of them have one or another drawing artifact with scales 2 and 4. >>> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-butt.png >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-round.png >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-square.png >>> >>> Thanks, >>> Alexandr. >>>> >>>> On 06.09.16 13:18, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165485 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 >>>>> >>>>> The icons drawing is changed to use ovals and polygons for >>>>> JRadioButton, JCheckBox, JComboBox, and JScrollBar. >>>>> >>>>> The screenshots [1], [2], and [3] show difference between icons >>>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png >>>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png >>>>> >>>>> [3] >>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png >>>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>> >>>> >>> >> > From ajit.ghaisas at oracle.com Fri Sep 9 03:43:43 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 8 Sep 2016 20:43:43 -0700 (PDT) Subject: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick In-Reply-To: <9379a93c-b919-4495-897b-04e6ece1030e@default> References: <086628e1-7a64-4d39-a5f2-18a6da2c075b@default> <6d867507-6e64-4a42-9054-0c6abb4e2242@default> <4595f207-be1a-572a-17c4-af49d4a9923c@oracle.com> <2847832b-284d-442f-9bcc-1ef8fb99d7d8@default> <42827df5-3948-ae9e-db4b-6c864d592457@oracle.com> <377dffcc-4ab5-4629-9e06-39e2fff4abc0@default> <31618f67-5e3c-472a-ba04-56193d6062e0@default> <9379a93c-b919-4495-897b-04e6ece1030e@default> Message-ID: This version looks fine. Regards, Ajit From: Prem Balakrishnan Sent: Thursday, September 08, 2016 7:12 PM To: Ajit Ghaisas; Alexander Scherbatiy; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: RE: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick Hi Ajit, Thank you for the feedback. I have updated patch as per review comments. http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.02/ Regards, Prem From: Ajit Ghaisas Sent: Thursday, September 08, 2016 5:47 PM To: Alexander Scherbatiy; Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: RE: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick Fix as such is fine. But, webrev needs update to address : 1. There are few typos (words : moves, previous) in test instructions. 2. A timeout can be added to the test - this will address the case when user does not press either pass or fail button 3. Please rename the test as not to contain bugID in filename. Use a meaningful name as test name. Regards, Ajit From: Alexandr Scherbatiy Sent: Tuesday, September 06, 2016 4:16 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick The fix looks good to me. Thanks, Alexandr. On 9/6/2016 9:56 AM, Prem Balakrishnan wrote: Hi Alexandr, Thank you for the feedback. I have updated patch as per review comments. HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.01/ Regards, Prem From: Alexandr Scherbatiy Sent: Monday, September 05, 2016 3:50 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 1:00 PM, Prem Balakrishnan wrote: Hi Alexandr, Yes true, Setting getSnapToTicks() true will set block increment to minor/majorTickSpacing. But enabling getSanpToTicks will Disable Unit Increment (scrollByUnit using Up/Down Arrow keys ) It works in the following way before the fix: Use minor, major, or (max-min)/10 if snapToTicks is enabled. Use (max-min)/10 if snapToTicks is disabled. After the fix it works: Use minor or (max-min)/10 if snapToTicks is disabled. Why major tick spacing is not taken into account in this case in the same way as for the enabled snapToTicks? It seems that both minor and major tick spacing should be checked together. Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Friday, September 02, 2016 3:14 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 9/2/2016 8:28 AM, Prem Balakrishnan wrote: Hi Alexandr, Thankyou for the Review. > For the case there only majorTickSpacing is set should it be used for a block increment? When setSnapToTicks(Boolean value) is set to true, All the keys Left/Right, Up/Down, PageUp/PageDown snaps to nearest tick(i.e., If minor Tick not set, it considers major Tick as the nearest tick). Based on my understanding, we need to set the minimum blockincrement size for PageUp/PageDown, which should be MinorTickSpacing if available. Where as if minorTickSpacing not Set and only MajorTickSpacing is set then blockincrement=[ (slider.getMaximum() - slider.getMinimum()) / 10] should be better. I see that the minorTickSpacing and majorTickSpacing are already used for the block increment in the BasicSliderUI.getTickSpacing() method when slider.getSnapToTicks() is enabled. May be a user just needs to set snapToTicks to true for a slider to get the desired block increment? Thanks, Alexandr. Regards, Prem From: Alexandr Scherbatiy Sent: Thursday, September 01, 2016 8:46 PM To: Prem Balakrishnan; Sergey Bylokhov; Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review Request: JDK-8009477 :PageUp and PageDown keyboard buttons don't move slider indicator to next minor tick On 8/31/2016 3:36 PM, Prem Balakrishnan wrote: Hi, Please review fix for JDK 9, Bug: https://bugs.openjdk.java.net/browse/JDK-8009477 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/8009477/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/8009477/webrev.00/ Cause: PageUp/PageDown key is used to scroll by block, MinorTickSpacing set by the user is not consider as the Block size. Fix: MinorTickSpacing(non-zero value) set by the user is set as Block size. For the case there only majorTickSpacing is set should it be used for a block increment? Thanks, Alexandr. Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Fri Sep 9 06:07:34 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 9 Sep 2016 08:07:34 +0200 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> <75b22fb4-b7c5-5414-2258-7b28ed09edbd@oracle.com> Message-ID: Hi Alexandr, this looks much better now. Thanks! Best regards, Andrej Golovnin On Thu, Sep 8, 2016 at 9:52 PM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165485/webrev.02 > > - shadow lines are updated > - round line end decoration is changed to draw just a point > > [1], [2], and [3] screenshots show difference between icons > drawing before and after the fix for scales 1x, 2x, and 4x. > > [1] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_02.png > [2] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_02.png > [3] > http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_02.png > > Thanks, > Alexandr. > > > On 9/7/2016 8:43 PM, Alexandr Scherbatiy wrote: >> >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8165485/webrev.01 >> >> Round line end decoration is used to draw combo box and scroll bar >> icons. >> >> [1], [2], and [3] screenshots show difference between icons >> drawing before and after the fix for scales 1x, 2x, and 4x. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_01.png >> [2] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_01.png >> [3] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_01.png >> >> Thanks, >> Alexandr. >> >> On 9/7/2016 7:54 PM, Phil Race wrote: >>> >>> drawPolyline does not seem to be an option here because of the different >>> colours. >>> Filling custom shapes may be overkill. Round looks to me to be the best >>> of these three. >>> >>> -phil. >>> >>> >>> On 9/7/2016 9:19 AM, Alexandr Scherbatiy wrote: >>>> >>>> On 9/6/2016 6:10 PM, Sergey Bylokhov wrote: >>>>> >>>>> It seems that there are some small artifacts on some of the components, >>>>> please take a look to the corners of the selected checkbox. In 1x the >>>>> corners have correct edges but in x2,x4 there are some missing pixels. >>>>> Similar issue is in the text area(take a look to the white border). >>>> >>>> Links [1], [2], and [3] shows drawing the scroll bar buttons using >>>> different types of a line ends decoration (cap, round, and square). All of >>>> them have one or another drawing artifact with scales 2 and 4. >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-butt.png >>>> [2] >>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-round.png >>>> [3] >>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-square.png >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> >>>>> On 06.09.16 13:18, Alexandr Scherbatiy wrote: >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165485 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 >>>>>> >>>>>> The icons drawing is changed to use ovals and polygons for >>>>>> JRadioButton, JCheckBox, JComboBox, and JScrollBar. >>>>>> >>>>>> The screenshots [1], [2], and [3] show difference between icons >>>>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>>>> >>>>>> [1] >>>>>> >>>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png >>>>>> [2] >>>>>> >>>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png >>>>>> [3] >>>>>> >>>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From rajeev.chamyal at oracle.com Fri Sep 9 12:06:52 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 9 Sep 2016 05:06:52 -0700 (PDT) Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: <613ed421-289a-11c2-c256-09316262247b@oracle.com> References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> Message-ID: <72bc3219-8476-4412-a58c-4465ac6899c2@default> Hello Alexandr, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ Update: Updated webrev is fixing the issue in windows only. We have a separate bug linux and it will be fixed through a separate webrev. https://bugs.openjdk.java.net/browse/JDK-8154551 Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 14 June 2016 15:21 To: Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated the webrev as per review comments. http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ I tried drawing the image directly to paint graphics without buffered image and it was getting cropped. Did you paint it using non scaled width and height? g.drawImage(image, 0, 0, curW, curH, null); Is the g transform already scaled? XTrayIconPeer: 606 if (scaleX > 1.0 && scaleY > 1.0) { 607 resolutionVariant = ((MultiResolutionImage) image). It is better to change the condition to "image instanceof MultiResolutionImage". It is necessary to not get CCE for non multi-resolution image and the multi-resolution image should return the best resolution variant for any scale. 618 gr.drawImage(resolutionVariant, 0, 0, 619 curW, curH, observer); The width and height should be scaled here to draw to whole buffered image. WTrayIconPeer: 133 BufferedImage bufImage = new BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, 134 BufferedImage.TYPE_INT_ARGB); The size for the buffered image should be scaled in the same was as for XTrayIconPeer. It may require to update the native code as well to set proper high-resolution icon. Thanks, Alexandr. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 09 June 2016 20:43 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: Hello All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8150176/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ Issue: Wrong resolution variant image is used in Tray Icon. Fix : Applying the device transform to graphics object to select the correct image. The image could be cropped on Linux because the high resolution icon which size is bigger that the original image is drawn to the buffered image with un-scaled size curW x CurH. It is better to get a resolution variant from the multi-resolution image, draw it to a buffered image with the same scaled size and then draw the buffered image to the paint graphics using original size: ------- Image resolutionVariant = ((MultiResolutionImage) image).getResolutionVariant(scaleX * curW, scaleY * curH); BufferedImage bufImage = new BufferedImage(scaleX * curW, scaleY * curH, BufferedImage.TYPE_INT_ARGB); // ... gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, observer); // ... g.drawImage(bufImage, 0, 0, curW, curH, observer); // non scaled width and height ------- By the way, is the buffered image necessary in this case? Is it possible to draw the image directly to the paint graphics? ------- g.drawImage(image, 0, 0, curW, curH, null); ------- Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Sep 9 18:51:40 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 9 Sep 2016 21:51:40 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> References: <574DE8A6.4090908@oracle.com> <5c690460-1915-9362-fbb7-d78f2670c3b9@oracle.com> <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> Message-ID: Hello, Could you review the updated fix: all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all public API changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api - reflection is used to detect do methods with floating point API need to be called. Thanks, Alexandr. On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: > > > > On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>> >>>> Alexander, did you consider possibility to check if method is >>>> really over-riden then to use the old API? >>>> >>> Could you give a sample how it can be done? >> I think it is possible to use a reflection to found the latest >> overridden method which uses int coordinates and check does it has a >> corresponding overridden method with floating point arguments. But I >> doubt that it is a good solution. > yes. You could use: > useFloatingPointAPI = > PlainView.class.equals(getClass().getMethod("drawUnselectedText", > ...).getDeclaringClass()); > > Otherwise, with high probability your new API will never be used. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> Thanks, >>> Alexandr. >>> >>>> --Semyon >>>> >>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>> >>>>>> Hi Alexander, >>>>>> >>>>>> It is a good style to add a note recommending what to use instead >>>>>> of the method which is being deprecated. >>>>>> >>>>> Could you review the updated public API there "replaced by" >>>>> notes are added to the deprecated methods: >>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>> >>>>>> I did not get for what the useFloatingPointAPI property was >>>>>> introduced and moreover is set to false by default. If the old >>>>>> API is used then it doesn't matter which value it has because the >>>>>> float values will receive ints. And for the new API I would >>>>>> expect everything having the float precision, and it is unclear >>>>>> what may be the reason to switch it off back to integer. >>>>>> Especially if >>>>>> >>>>>> " This allows to draw text properly using graphics with scaled >>>>>> transform." >>>>>> >>>>>> so an improper mode is the default? >>>>>> >>>>> This is has been discussed below. For example new >>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) >>>>> with floating point coordinates is added to the PlainView which >>>>> has the same method with int coordinates. Suppose someone has a >>>>> custom password component which uses and old methods with int >>>>> coordinates. >>>>> -------- >>>>> public class CustomPasswordField extends FieldView { >>>>> >>>>> @Override >>>>> protected int drawSelectedText(Graphics g, int x, int y, int >>>>> p0, int p1) throws BadLocationException { >>>>> // draw echo chars >>>>> } >>>>> } >>>>> -------- >>>>> >>>>> If we start to call drawSelectedText() with floating point values >>>>> the customization of old components will not be used and the >>>>> CustomPasswordField from the example starts to show real text >>>>> instead of echo chars. This is incompatible change with previous >>>>> JDK releases. >>>>> >>>>> The solution is to switch to new floating point API only when it >>>>> is known that a component properly overrides new methods with >>>>> floating point arguments. After that the >>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>> >>>>> For example, BasicPasswordFieldUI sets the >>>>> PasswordView.useFloatingPointAPI flag to true because it is sure >>>>> that drawSelectedText() methods with floating point arguments is >>>>> overridden. So Swing standard text components are switched to use >>>>> new floating point API. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>> OK .. I do not know enough about how modelToView is used by Swing >>>>>>>> to know what is really needed here. Someone with a bit more Swing >>>>>>>> background needs to chime in. I was encouraged that the *API* >>>>>>>> surface >>>>>>>> of the changes was much smaller than it had seemed from the webrev >>>>>>>> but maybe that is because you did not include everything. For >>>>>>>> example >>>>>>>> although they are just subclassing the method overrides in >>>>>>>> PasswordView >>>>>>>> since that is a public class would become part of the spec .. >>>>>>>> would they not ? >>>>>>>> Just like the "int" counterparts today :- >>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>> >>>>>>>> Put another way I was looking for what the content of the CCC >>>>>>>> would be. >>>>>>> Here is the updated version of the public API change which >>>>>>> includes overridden deprecated methods: >>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> >>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>> Why is the caret support added in here ? Same for the modelToView >>>>>>>>>> That will just hold this up as the reasoning behind needing >>>>>>>>>> those changes is not something >>>>>>>>>> I have yet been able to convince myself about - even after >>>>>>>>>> reading your last email. >>>>>>>>> >>>>>>>>> The main change for the Caret public API (methods >>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>> p)) is not included in the current fix. I only moved the new >>>>>>>>> methods JTextComponent.modelToView2D(int >>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret to >>>>>>>>> this fix. These methods are used not only for caret but in >>>>>>>>> other cases like mouse handling, text dragging and others. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>> >>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>> methods are added to the PlainView and WrappedPlainView classes >>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>> are added >>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>>>>>>> standard Java text components >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> See comments inline. >>>>>>>>>>>> >>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>> >>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point I >>>>>>>>>>>>> am not sure what we are gaining >>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>> >>>>>>>>>>>>> It affects only the methods that the 3rd party code can >>>>>>>>>>>>> over-ride >>>>>>>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>>>>>>> >>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>> and >>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>> >>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>> Is there any other method that matters / is used in this way ? >>>>>>>>>>>> I have found the following methods which relate to text >>>>>>>>>>>> drawing, can be overridden and could have floating point >>>>>>>>>>>> coordinates: >>>>>>>>>>>> >>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>> >>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>> >>>>>>>>>>>> There is also a method which relates to a caret position in >>>>>>>>>>>> a text: >>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>>>>> This requires additional investigation because DefaultCaret >>>>>>>>>>>> extends Rectangle and so its coordinates can't be float. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Since 3rd party code is not over-riding these they will >>>>>>>>>>>>> get the JDK >>>>>>>>>>>>> super-class version, thus losing any customisation they >>>>>>>>>>>>> might have done >>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>> >>>>>>>>>>>>> Assuming that is correct, what customisation would be lost >>>>>>>>>>>>> and how much does it matter? >>>>>>>>>>>> >>>>>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>> -------- >>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>> >>>>>>>>>>>> @Override >>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, int >>>>>>>>>>>> y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>> // draw echo chars >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> -------- >>>>>>>>>>>> >>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>> coordinates will lead that real text will be shown for old >>>>>>>>>>>> applications in password fields. >>>>>>>>>>>>> >>>>>>>>>>>>> My prefernce is to deprecate the int versions and always >>>>>>>>>>>>> call the float versions >>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>> >>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>> something that does >>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>> >>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>> >>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element elem, >>>>>>>>>>>>> Graphics g, >>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>> 109 { >>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>> 113 >>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>> 116 } >>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>> >>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>> method is: >>>>>>>>>>>> --------- >>>>>>>>>>>> /** >>>>>>>>>>>> * Renders a line of text, suppressing whitespace at >>>>>>>>>>>> the end >>>>>>>>>>>> * and expanding any tabs. This is implemented to make >>>>>>>>>>>> calls >>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>> Applications can rely on this behaviour and stopping to >>>>>>>>>>>> call the drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>> methods with int coordinates will be incompatible change. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>> New float methods allow to easily migrate on new API for >>>>>>>>>>>> applications without significant changes. >>>>>>>>>>>> >>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count isn't >>>>>>>>>>>>> it ? Not a pixel >>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>> >>>>>>>>>>>> - methods with int coordinates which can be overridden >>>>>>>>>>>> are deprecated >>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> -phil >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it uses >>>>>>>>>>>>>>> a library that has not been fixed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>> to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Using the floating point API is disabled by default and >>>>>>>>>>>>>> enabled for standard Swing text component classes. This >>>>>>>>>>>>>> has advantage that selection will work for text component >>>>>>>>>>>>>> in users applications on HiDPI display. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But it still has the same problem. Applications which >>>>>>>>>>>>>> use custom View classes needs to updated them to >>>>>>>>>>>>>> implement corresponding text drawing methods with >>>>>>>>>>>>>> floating point arguments and enable the floating point >>>>>>>>>>>>>> API usage. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For each method that uses integer coordinates the fix >>>>>>>>>>>>>>>> adds a pair with floating point arguments. >>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating point >>>>>>>>>>>>>>>> values to correctly handle a selected text. >>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>> By default it is false and all work as before. The >>>>>>>>>>>>>>>> issue with selected text is reproduced. >>>>>>>>>>>>>>>> An application with enabled property does not have >>>>>>>>>>>>>>>> issue with the selected text but a user should override >>>>>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image rendering >>>>>>>>>>>>>>>> for HiDPI displays >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems there >>>>>>>>>>>>>>>>>> is a rounding issue when float values are summed up. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the >>>>>>>>>>>>>>>>>> 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = 6.666666666666667 >>>>>>>>>>>>>>>>>> as double value and 6.6666665 when it is cast to >>>>>>>>>>>>>>>>>> float in user space. >>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' chars >>>>>>>>>>>>>>>>>> is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() method >>>>>>>>>>>>>>>>>> is 99.999992. >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N * >>>>>>>>>>>>>>>>>> advance); >>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects the >>>>>>>>>>>>>>>>>> text selection code in Swing: >>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, >>>>>>>>>>>>>>>>>> 0, index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>> // non-selected text >>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate >>>>>>>>>>>>>>>>> the transformed coordinates are: >>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to >>>>>>>>>>>>>>>>> one pixel left >>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to 151 >>>>>>>>>>>>>>>>> in dev space. >>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to 152 >>>>>>>>>>>>>>>>> in dev space. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> And this difference can depend on the translate even >>>>>>>>>>>>>>>>> it has integer value in user space because it is >>>>>>>>>>>>>>>>> multiplied on the graphics scale. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but there >>>>>>>>>>>>>>>>>>>> still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and then >>>>>>>>>>>>>>>>>>>> up again, as I pass the >>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint seem >>>>>>>>>>>>>>>>>>>> to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text related. >>>>>>>>>>>>>>>>>>>> Can you take a look. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of the >>>>>>>>>>>>>>>>>>> text is shifted from the first piece by the floating >>>>>>>>>>>>>>>>>>> point size of the the first piece of the text. >>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), x >>>>>>>>>>>>>>>>>>> + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in the >>>>>>>>>>>>>>>>>>> 2 cases: >>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied translation >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related to >>>>>>>>>>>>>>>>>>>>> the fact that char width can be fractional in user >>>>>>>>>>>>>>>>>>>>> space. >>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used for >>>>>>>>>>>>>>>>>>>>> the fractional string width calculation by Swing >>>>>>>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Sep 9 23:36:28 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 09 Sep 2016 16:36:28 -0700 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: References: <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> Message-ID: <57D3477C.2090503@oracle.com> - * Returns the tab size set for the document, defaulting to 8. - * - * @implSpec This implementation calls {@link #getTabSize() getTabSize()}. - * - * @return the tab size - */ - protected float getFractionalTabSize() { - return getTabSize(); - } - It seems this was added only in 9. Since I think I remember that asking a question about it. I note it has no @since. Moot if you are really removing it but what has it to do with the rest of this change ? -phil. On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all > public API changes: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api > > - reflection is used to detect do methods with floating point API > need to be called. > > Thanks, > Alexandr. > > On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >> >> >> >> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>> >>>>> Alexander, did you consider possibility to check if method is >>>>> really over-riden then to use the old API? >>>>> >>>> Could you give a sample how it can be done? >>> I think it is possible to use a reflection to found the latest >>> overridden method which uses int coordinates and check does it has a >>> corresponding overridden method with floating point arguments. But I >>> doubt that it is a good solution. >> yes. You could use: >> useFloatingPointAPI = >> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >> ...).getDeclaringClass()); >> >> Otherwise, with high probability your new API will never be used. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> --Semyon >>>>> >>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> Hi Alexander, >>>>>>> >>>>>>> It is a good style to add a note recommending what to use >>>>>>> instead of the method which is being deprecated. >>>>>>> >>>>>> Could you review the updated public API there "replaced by" >>>>>> notes are added to the deprecated methods: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>> >>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>> introduced and moreover is set to false by default. If the old >>>>>>> API is used then it doesn't matter which value it has because >>>>>>> the float values will receive ints. And for the new API I would >>>>>>> expect everything having the float precision, and it is unclear >>>>>>> what may be the reason to switch it off back to integer. >>>>>>> Especially if >>>>>>> >>>>>>> " This allows to draw text properly using graphics with scaled >>>>>>> transform." >>>>>>> >>>>>>> so an improper mode is the default? >>>>>>> >>>>>> This is has been discussed below. For example new >>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) >>>>>> with floating point coordinates is added to the PlainView which >>>>>> has the same method with int coordinates. Suppose someone has a >>>>>> custom password component which uses and old methods with int >>>>>> coordinates. >>>>>> -------- >>>>>> public class CustomPasswordField extends FieldView { >>>>>> >>>>>> @Override >>>>>> protected int drawSelectedText(Graphics g, int x, int y, int >>>>>> p0, int p1) throws BadLocationException { >>>>>> // draw echo chars >>>>>> } >>>>>> } >>>>>> -------- >>>>>> >>>>>> If we start to call drawSelectedText() with floating point values >>>>>> the customization of old components will not be used and the >>>>>> CustomPasswordField from the example starts to show real text >>>>>> instead of echo chars. This is incompatible change with previous >>>>>> JDK releases. >>>>>> >>>>>> The solution is to switch to new floating point API only when it >>>>>> is known that a component properly overrides new methods with >>>>>> floating point arguments. After that the >>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>> >>>>>> For example, BasicPasswordFieldUI sets the >>>>>> PasswordView.useFloatingPointAPI flag to true because it is sure >>>>>> that drawSelectedText() methods with floating point arguments is >>>>>> overridden. So Swing standard text components are switched to use >>>>>> new floating point API. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> >>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>> OK .. I do not know enough about how modelToView is used by Swing >>>>>>>>> to know what is really needed here. Someone with a bit more Swing >>>>>>>>> background needs to chime in. I was encouraged that the *API* >>>>>>>>> surface >>>>>>>>> of the changes was much smaller than it had seemed from the webrev >>>>>>>>> but maybe that is because you did not include everything. For >>>>>>>>> example >>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>> PasswordView >>>>>>>>> since that is a public class would become part of the spec .. >>>>>>>>> would they not ? >>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>> >>>>>>>>> Put another way I was looking for what the content of the CCC >>>>>>>>> would be. >>>>>>>> Here is the updated version of the public API change which >>>>>>>> includes overridden deprecated methods: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>> modelToView >>>>>>>>>>> That will just hold this up as the reasoning behind needing >>>>>>>>>>> those changes is not something >>>>>>>>>>> I have yet been able to convince myself about - even after >>>>>>>>>>> reading your last email. >>>>>>>>>> >>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>> p)) is not included in the current fix. I only moved the new >>>>>>>>>> methods JTextComponent.modelToView2D(int >>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret to >>>>>>>>>> this fix. These methods are used not only for caret but in >>>>>>>>>> other cases like mouse handling, text dragging and others. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>> >>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>> - public isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>> methods are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>> are added >>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>>>>>>>> standard Java text components >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point I >>>>>>>>>>>>>> am not sure what we are gaining >>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It affects only the methods that the 3rd party code can >>>>>>>>>>>>>> over-ride >>>>>>>>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>> and >>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>> >>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>> Is there any other method that matters / is used in this >>>>>>>>>>>>>> way ? >>>>>>>>>>>>> I have found the following methods which relate to text >>>>>>>>>>>>> drawing, can be overridden and could have floating point >>>>>>>>>>>>> coordinates: >>>>>>>>>>>>> >>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>> >>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>> >>>>>>>>>>>>> There is also a method which relates to a caret position >>>>>>>>>>>>> in a text: >>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>> can't be float. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Since 3rd party code is not over-riding these they will >>>>>>>>>>>>>> get the JDK >>>>>>>>>>>>>> super-class version, thus losing any customisation they >>>>>>>>>>>>>> might have done >>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>> >>>>>>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>> -------- >>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>> >>>>>>>>>>>>> @Override >>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, int >>>>>>>>>>>>> y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> -------- >>>>>>>>>>>>> >>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>> coordinates will lead that real text will be shown for old >>>>>>>>>>>>> applications in password fields. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My prefernce is to deprecate the int versions and always >>>>>>>>>>>>>> call the float versions >>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>> something that does >>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>> >>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element elem, Graphics g, >>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>> 113 >>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>> >>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>> method is: >>>>>>>>>>>>> --------- >>>>>>>>>>>>> /** >>>>>>>>>>>>> * Renders a line of text, suppressing whitespace at >>>>>>>>>>>>> the end >>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>> make calls >>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>> --------- >>>>>>>>>>>>> >>>>>>>>>>>>> Applications can rely on this behaviour and stopping to >>>>>>>>>>>>> call the drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>> methods with int coordinates will be incompatible change. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>> New float methods allow to easily migrate on new API for >>>>>>>>>>>>> applications without significant changes. >>>>>>>>>>>>> >>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>> >>>>>>>>>>>>> - methods with int coordinates which can be overridden >>>>>>>>>>>>> are deprecated >>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>>> to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>> and enabled for standard Swing text component classes. >>>>>>>>>>>>>>> This has advantage that selection will work for text >>>>>>>>>>>>>>> component in users applications on HiDPI display. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But it still has the same problem. Applications which >>>>>>>>>>>>>>> use custom View classes needs to updated them to >>>>>>>>>>>>>>> implement corresponding text drawing methods with >>>>>>>>>>>>>>> floating point arguments and enable the floating point >>>>>>>>>>>>>>> API usage. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For each method that uses integer coordinates the fix >>>>>>>>>>>>>>>>> adds a pair with floating point arguments. >>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating point >>>>>>>>>>>>>>>>> values to correctly handle a selected text. >>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>> By default it is false and all work as before. The >>>>>>>>>>>>>>>>> issue with selected text is reproduced. >>>>>>>>>>>>>>>>> An application with enabled property does not have >>>>>>>>>>>>>>>>> issue with the selected text but a user should override >>>>>>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the >>>>>>>>>>>>>>>>>>> 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 when >>>>>>>>>>>>>>>>>>> it is cast to float in user space. >>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' chars >>>>>>>>>>>>>>>>>>> is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() >>>>>>>>>>>>>>>>>>> method is 99.999992. >>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, >>>>>>>>>>>>>>>>>>> advance, N * advance); >>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects >>>>>>>>>>>>>>>>>>> the text selection code in Swing: >>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate >>>>>>>>>>>>>>>>>> the transformed coordinates are: >>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted to >>>>>>>>>>>>>>>>>> one pixel left >>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to 151 >>>>>>>>>>>>>>>>>> in dev space. >>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> And this difference can depend on the translate even >>>>>>>>>>>>>>>>>> it has integer value in user space because it is >>>>>>>>>>>>>>>>>> multiplied on the graphics scale. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but there >>>>>>>>>>>>>>>>>>>>> still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and then >>>>>>>>>>>>>>>>>>>>> up again, as I pass the >>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text related. >>>>>>>>>>>>>>>>>>>>> Can you take a look. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of the >>>>>>>>>>>>>>>>>>>> text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of the text. >>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, >>>>>>>>>>>>>>>>>>>> 0, index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related to >>>>>>>>>>>>>>>>>>>>>> the fact that char width can be fractional in >>>>>>>>>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy.abossolo.foh at scientificware.com Sun Sep 11 08:34:36 2016 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sun, 11 Sep 2016 10:34:36 +0200 Subject: Thanks to Semyon Sadetsky. In-Reply-To: <341fc4d3-44fa-72d5-0252-234647db93f7@oracle.com> References: <341fc4d3-44fa-72d5-0252-234647db93f7@oracle.com> Message-ID: <26224d39e032211ebda8b7c9d937ae28@scientificware.com> Hi, Thank you very much for your great work. But I'm agree and not agree with your conclusion about JDK-8158209 : "Not an Issue". I'm agree : I understand your recommendations about the height and the width for the frame of the trView. I never talked about this problem because frame painting hasn't being a problem for me. I'm not agree : I made a mistake in writing the bug JDK-8158209 report : two problems in the same report. But JDK-7169915 and JDK-7072926 are really a different problem you solve in JDK-8158209. In 2012, codebug.java was designed first for these bugs. It is just an update problem, if you follow the steps discribe in JDK-7169915 and JDK-7072926 and if you read the text\html\tableView code you can understand my fix. text\html\tableView works (not public) fine and \text\tableView (public) works bad ? ? ? ? As Victor, don't worry about this fix, I'd just compare the two codes to built my fix. In attachment the documents asked by Alexandr about my fix. Yours faithfully. --------------------------------------- Hello, > Could you apply the fix to JDK 9 client repository ... I applied the fix to JDK 9 client repository http://hg.openjdk.java.net/jdk9/client : openjdk version "9-internal" OpenJDK Runtime Environment (build 9-internal+0-2016-05-28-142420.scientificware2016.9devClient) OpenJDK 64-Bit Server VM (build 9-internal+0-2016-05-28-142420.scientificware2016.9devClient, mixed mode) The webrev and JTreport/JTWork are in attachment. All works fine, except what is mentioned below. > You mentioned that there are artifacts with a table displaying in JDK > 9. I can't say when it appeared because before your fix, the table size didn't changed when we insert text and all the text stay on the same line. But, I have just notice that if, in the I18nLayoutTest.java, you - change the line setUndecorated(true) to setUndecorated(false), - run the program and enlarge the window 2 times larger than the text size, - all the text come back on the same line. There no such artifacts when i18n is false. Thanks for your help. Guy. --------------------------------------------------------------------------------------------- Le 2016-05-27 16:53, Alexandr Scherbatiy a ?crit?: > The fix should be prepared for the JDK 9 first and only after that be > backported to JDK 8u. > > Could you apply the fix to JDK 9 client repository > http://hg.openjdk.java.net/jdk9/client > and send the webrev of the fix plus the test (see > http://openjdk.java.net/guide/webrevHelp.html). > The fix shouldn't contain comments with the old code lines. I believe > that references to the bug number are also unnecessary for this case. > > You mentioned that there are artifacts with a table displaying in JDK > 9. Do they appear only after fix of they also present even without the > fix? > > Thanks, > Alexandr. > > On 5/27/2016 9:23 AM, Abossolo Foh Guy wrote: >> Hello, >> >> Please, please ... could someone examine the patch for JDK-8133864 >> that I suggested ? I really need it to implement matrix display in my >> application. I've spent long time in 2012 to find what was wrong in >> tableview. I know Victor's comment was not good but you could compare >> with the tableview implementation in the swing/text/html package which >> works fine. >> >> Beware, the display (with java 9 119) for I18nLayoutTest.java is not >> the same with i18n true (bad) or i18n false (good). With i18n true the >> table go down. >> >> Best regards. >> >> ---------------------------------------------------------------------------------------------------------------------- >> Hello, >> >> I built the recent OpenJDK8u and OpenJDK9 sources >> (openjdk_versions.txt) with the patch shown in the output_diff.txt >> attachment. >> >> I applied your patch for JDK-8133864 : Wrong display, when the >> document I18n properties is true. >> And I applied my patch for JDK-7169915 : Swing Table Layout bad >> repaint of the row. >> >> All works fine in OpenJDK8u and the document is well displayed. The >> table appears as I expected with all its lines and columns >> (JDK-8133864 solved), size and borders included even if we write some >> text inside (JDK-7169915 solved). I can modify it as I want. >> >> But with OpenJDK9, the display of the document is wrong. The table >> appears as I expected with all its lines and columns (JDK-8133864 >> solved), size and borders included (JDK-7169915 solved) but the entire >> document display is modified, the table is displayed on a new line. >> And the document became unuseable, I can't modify it as I want. >> >> This morning, I ran the same test programme (CodeBug.java in >> attachment) with the Oracle JDK9 b114 (i.e. OpenJDK9 only with your >> patch for JDK-8133864) : The table appears as I expected with all its >> lines and columns (JDK-8133864 solved) but the size and borders are >> bad repainted when we write some text inside (JDK-7169915 solved). And >> the document became unuseable too, I can't modify it as I want. >> >> My conclusion : >> 1- JDK-8133864 is solved with your PATCH. >> 2- JDK-7169915 could be solved with my PATCH. >> 3- There is regression between JDK8 and JDK9 may be in the Views >> arrangement. >> >> Best regards. >> >> ---------------------------------------------------------------------------------------------------------------------- >> Hello, >> >> Could you apply the modification I suggested 4 years ago about the Bug >> : JDK-7169915 : Swing Table Layout bad repaint of the row. >> >> The test case I had sent in 2012 is the same I used in : JDK-8133864 >> Wrong display, when the document I18n properties is true. >> >> A version of this test (called I18nLayoutTest.java) is now candidate >> as part of tests for JDK 9 (/test/javax/swing/text/TableView/) >> >> Yours faithfully. >> >> -- Abossolo Foh Guy 71 rue Guy de Maupassant 69500 Bron 06 87 01 82 27 04 72 81 89 46 -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip Type: application/zip Size: 95002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JTreport.zip Type: application/zip Size: 413201 bytes Desc: not available URL: From alexandr.scherbatiy at oracle.com Mon Sep 12 12:19:44 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 12 Sep 2016 15:19:44 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <57D3477C.2090503@oracle.com> References: <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> Message-ID: <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> Hello, Could you review the updated fix: all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all public API changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api - @since 9 tag is added to new methods. Thanks, Alexandr. On 9/10/2016 2:36 AM, Philip Race wrote: > - * Returns the tab size set for the document, defaulting to 8. > - * > - * @implSpec This implementation calls {@link #getTabSize() > getTabSize()}. > - * > - * @return the tab size > - */ > - protected float getFractionalTabSize() { > - return getTabSize(); > - } > - > > > It seems this was added only in 9. > Since I think I remember that asking a question about it. > I note it has no @since. Moot if you are really removing it but > what has it to do with the rest of this change ? > > -phil. > > On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >> public API changes: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >> >> - reflection is used to detect do methods with floating point API >> need to be called. >> >> Thanks, >> Alexandr. >> >> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>> >>> >>> >>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> Alexander, did you consider possibility to check if method is >>>>>> really over-riden then to use the old API? >>>>>> >>>>> Could you give a sample how it can be done? >>>> I think it is possible to use a reflection to found the latest >>>> overridden method which uses int coordinates and check does it has >>>> a corresponding overridden method with floating point arguments. >>>> But I doubt that it is a good solution. >>> yes. You could use: >>> useFloatingPointAPI = >>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>> ...).getDeclaringClass()); >>> >>> Otherwise, with high probability your new API will never be used. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> --Semyon >>>>>> >>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> Hi Alexander, >>>>>>>> >>>>>>>> It is a good style to add a note recommending what to use >>>>>>>> instead of the method which is being deprecated. >>>>>>>> >>>>>>> Could you review the updated public API there "replaced by" >>>>>>> notes are added to the deprecated methods: >>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>> >>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>> introduced and moreover is set to false by default. If the old >>>>>>>> API is used then it doesn't matter which value it has because >>>>>>>> the float values will receive ints. And for the new API I would >>>>>>>> expect everything having the float precision, and it is unclear >>>>>>>> what may be the reason to switch it off back to integer. >>>>>>>> Especially if >>>>>>>> >>>>>>>> " This allows to draw text properly using graphics with scaled >>>>>>>> transform." >>>>>>>> >>>>>>>> so an improper mode is the default? >>>>>>>> >>>>>>> This is has been discussed below. For example new >>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int p1) >>>>>>> with floating point coordinates is added to the PlainView which >>>>>>> has the same method with int coordinates. Suppose someone has a >>>>>>> custom password component which uses and old methods with int >>>>>>> coordinates. >>>>>>> -------- >>>>>>> public class CustomPasswordField extends FieldView { >>>>>>> >>>>>>> @Override >>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>> int p0, int p1) throws BadLocationException { >>>>>>> // draw echo chars >>>>>>> } >>>>>>> } >>>>>>> -------- >>>>>>> >>>>>>> If we start to call drawSelectedText() with floating point >>>>>>> values the customization of old components will not be used and >>>>>>> the CustomPasswordField from the example starts to show real >>>>>>> text instead of echo chars. This is incompatible change with >>>>>>> previous JDK releases. >>>>>>> >>>>>>> The solution is to switch to new floating point API only when it >>>>>>> is known that a component properly overrides new methods with >>>>>>> floating point arguments. After that the >>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>> >>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>> sure that drawSelectedText() methods with floating point >>>>>>> arguments is overridden. So Swing standard text components are >>>>>>> switched to use new floating point API. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> >>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>> OK .. I do not know enough about how modelToView is used by Swing >>>>>>>>>> to know what is really needed here. Someone with a bit more Swing >>>>>>>>>> background needs to chime in. I was encouraged that the *API* >>>>>>>>>> surface >>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>> webrev >>>>>>>>>> but maybe that is because you did not include everything. For >>>>>>>>>> example >>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>> PasswordView >>>>>>>>>> since that is a public class would become part of the spec .. >>>>>>>>>> would they not ? >>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>> >>>>>>>>>> Put another way I was looking for what the content of the CCC >>>>>>>>>> would be. >>>>>>>>> Here is the updated version of the public API change which >>>>>>>>> includes overridden deprecated methods: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>> modelToView >>>>>>>>>>>> That will just hold this up as the reasoning behind needing >>>>>>>>>>>> those changes is not something >>>>>>>>>>>> I have yet been able to convince myself about - even after >>>>>>>>>>>> reading your last email. >>>>>>>>>>> >>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>> p)) is not included in the current fix. I only moved the new >>>>>>>>>>> methods JTextComponent.modelToView2D(int >>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret to >>>>>>>>>>> this fix. These methods are used not only for caret but in >>>>>>>>>>> other cases like mouse handling, text dragging and others. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>> >>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>> - public >>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>> are added >>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API in >>>>>>>>>>>>> standard Java text components >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point I >>>>>>>>>>>>>>> am not sure what we are gaining >>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It affects only the methods that the 3rd party code can >>>>>>>>>>>>>>> over-ride >>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>> Is there any other method that matters / is used in this >>>>>>>>>>>>>>> way ? >>>>>>>>>>>>>> I have found the following methods which relate to text >>>>>>>>>>>>>> drawing, can be overridden and could have floating point >>>>>>>>>>>>>> coordinates: >>>>>>>>>>>>>> >>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>> >>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is also a method which relates to a caret position >>>>>>>>>>>>>> in a text: >>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they will >>>>>>>>>>>>>>> get the JDK >>>>>>>>>>>>>>> super-class version, thus losing any customisation they >>>>>>>>>>>>>>> might have done >>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>> -------- >>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Override >>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> -------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and always >>>>>>>>>>>>>>> call the float versions >>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>> method is: >>>>>>>>>>>>>> --------- >>>>>>>>>>>>>> /** >>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace at >>>>>>>>>>>>>> the end >>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>> make calls >>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>> --------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Applications can rely on this behaviour and stopping to >>>>>>>>>>>>>> call the drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>>> methods with int coordinates will be incompatible change. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>> >>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>> and enabled for standard Swing text component classes. >>>>>>>>>>>>>>>> This has advantage that selection will work for text >>>>>>>>>>>>>>>> component in users applications on HiDPI display. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But it still has the same problem. Applications which >>>>>>>>>>>>>>>> use custom View classes needs to updated them to >>>>>>>>>>>>>>>> implement corresponding text drawing methods with >>>>>>>>>>>>>>>> floating point arguments and enable the floating point >>>>>>>>>>>>>>>> API usage. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>> By default it is false and all work as before. The >>>>>>>>>>>>>>>>>> issue with selected text is reproduced. >>>>>>>>>>>>>>>>>> An application with enabled property does not have >>>>>>>>>>>>>>>>>> issue with the selected text but a user should override >>>>>>>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Here is a proposed solution where new public system >>>>>>>>>>>>>>>>>> property "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the >>>>>>>>>>>>>>>>>>>> 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() >>>>>>>>>>>>>>>>>>>> method is 99.999992. >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N * >>>>>>>>>>>>>>>>>>>> advance); >>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects >>>>>>>>>>>>>>>>>>>> the text selection code in Swing: >>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate >>>>>>>>>>>>>>>>>>> the transformed coordinates are: >>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but there >>>>>>>>>>>>>>>>>>>>>> still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text related. >>>>>>>>>>>>>>>>>>>>>> Can you take a look. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of the >>>>>>>>>>>>>>>>>>>>> text. >>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, >>>>>>>>>>>>>>>>>>>>> 0, index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, TEXT.length()), >>>>>>>>>>>>>>>>>>>>> x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related to >>>>>>>>>>>>>>>>>>>>>>> the fact that char width can be fractional in >>>>>>>>>>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Sep 12 13:39:54 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 12 Sep 2016 16:39:54 +0300 Subject: [PATCH] JDK-7169915 : Swing Table Layout bad repaint of the row [REGRESSION] JDK-8133864 : Wrong display, when the document I18n properties is true. In-Reply-To: <26224d39e032211ebda8b7c9d937ae28@scientificware.com> References: <341fc4d3-44fa-72d5-0252-234647db93f7@oracle.com> <26224d39e032211ebda8b7c9d937ae28@scientificware.com> Message-ID: Hello, The JDK-8133864 seems has no a regression. I found that your test works well after it (with corrections I described in JIRA for the table frame). If TableView layout is still an incorrect for you, please, attach a test that fails before and passes after your fix. Test is required for any JDK fixes and I didn't find in your webrev. --Semyon On 9/11/2016 11:34 AM, Abossolo Foh Guy wrote: > Hi, > > Thank you very much for your great work. > But I'm agree and not agree with your conclusion about JDK-8158209 : > "Not an Issue". > > I'm agree : > I understand your recommendations about the height and the width for > the frame of the trView. > I never talked about this problem because frame painting hasn't being > a problem for me. > > I'm not agree : > I made a mistake in writing the bug JDK-8158209 report : two problems > in the same report. > But JDK-7169915 and JDK-7072926 are really a different problem you > solve in JDK-8158209. > In 2012, codebug.java was designed first for these bugs. > It is just an update problem, if you follow the steps discribe in > JDK-7169915 and JDK-7072926 and if you read the text\html\tableView > code you can understand my fix. > text\html\tableView works (not public) fine and \text\tableView > (public) works bad ? ? ? ? > As Victor, don't worry about this fix, I'd just compare the two codes > to built my fix. > > In attachment the documents asked by Alexandr about my fix. > > Yours faithfully. > > --------------------------------------- > Hello, > >> Could you apply the fix to JDK 9 client repository ... > I applied the fix to JDK 9 client repository > http://hg.openjdk.java.net/jdk9/client : > > openjdk version "9-internal" > OpenJDK Runtime Environment (build > 9-internal+0-2016-05-28-142420.scientificware2016.9devClient) > OpenJDK 64-Bit Server VM (build > 9-internal+0-2016-05-28-142420.scientificware2016.9devClient, mixed mode) > > The webrev and JTreport/JTWork are in attachment. All works fine, > except what is mentioned below. > > >> You mentioned that there are artifacts with a table displaying in JDK 9. > I can't say when it appeared because before your fix, the table size > didn't changed when we insert text and all the text stay on the same > line. > But, I have just notice that if, in the I18nLayoutTest.java, you > - change the line setUndecorated(true) to setUndecorated(false), > - run the program and enlarge the window 2 times larger than the text > size, > - all the text come back on the same line. > There no such artifacts when i18n is false. > > Thanks for your help. > > Guy. > > --------------------------------------------------------------------------------------------- > > Le 2016-05-27 16:53, Alexandr Scherbatiy a ?crit : >> The fix should be prepared for the JDK 9 first and only after that be >> backported to JDK 8u. >> >> Could you apply the fix to JDK 9 client repository >> http://hg.openjdk.java.net/jdk9/client >> and send the webrev of the fix plus the test (see >> http://openjdk.java.net/guide/webrevHelp.html). >> The fix shouldn't contain comments with the old code lines. I believe >> that references to the bug number are also unnecessary for this case. >> >> You mentioned that there are artifacts with a table displaying in JDK >> 9. Do they appear only after fix of they also present even without the >> fix? >> >> Thanks, >> Alexandr. >> >> On 5/27/2016 9:23 AM, Abossolo Foh Guy wrote: >>> Hello, >>> >>> Please, please ... could someone examine the patch for JDK-8133864 >>> that I suggested ? I really need it to implement matrix display in >>> my application. I've spent long time in 2012 to find what was wrong >>> in tableview. I know Victor's comment was not good but you could >>> compare with the tableview implementation in the swing/text/html >>> package which works fine. >>> >>> Beware, the display (with java 9 119) for I18nLayoutTest.java is not >>> the same with i18n true (bad) or i18n false (good). With i18n true >>> the table go down. >>> >>> Best regards. >>> >>> ---------------------------------------------------------------------------------------------------------------------- >>> Hello, >>> >>> I built the recent OpenJDK8u and OpenJDK9 sources >>> (openjdk_versions.txt) with the patch shown in the output_diff.txt >>> attachment. >>> >>> I applied your patch for JDK-8133864 : Wrong display, when the >>> document I18n properties is true. >>> And I applied my patch for JDK-7169915 : Swing Table Layout bad >>> repaint of the row. >>> >>> All works fine in OpenJDK8u and the document is well displayed. The >>> table appears as I expected with all its lines and columns >>> (JDK-8133864 solved), size and borders included even if we write >>> some text inside (JDK-7169915 solved). I can modify it as I want. >>> >>> But with OpenJDK9, the display of the document is wrong. The table >>> appears as I expected with all its lines and columns (JDK-8133864 >>> solved), size and borders included (JDK-7169915 solved) but the >>> entire document display is modified, the table is displayed on a new >>> line. And the document became unuseable, I can't modify it as I want. >>> >>> This morning, I ran the same test programme (CodeBug.java in >>> attachment) with the Oracle JDK9 b114 (i.e. OpenJDK9 only with your >>> patch for JDK-8133864) : The table appears as I expected with all >>> its lines and columns (JDK-8133864 solved) but the size and borders >>> are bad repainted when we write some text inside (JDK-7169915 >>> solved). And the document became unuseable too, I can't modify it as >>> I want. >>> >>> My conclusion : >>> 1- JDK-8133864 is solved with your PATCH. >>> 2- JDK-7169915 could be solved with my PATCH. >>> 3- There is regression between JDK8 and JDK9 may be in the Views >>> arrangement. >>> >>> Best regards. >>> >>> ---------------------------------------------------------------------------------------------------------------------- >>> Hello, >>> >>> Could you apply the modification I suggested 4 years ago about the >>> Bug : JDK-7169915 : Swing Table Layout bad repaint of the row. >>> >>> The test case I had sent in 2012 is the same I used in : JDK-8133864 >>> Wrong display, when the document I18n properties is true. >>> >>> A version of this test (called I18nLayoutTest.java) is now candidate >>> as part of tests for JDK 9 (/test/javax/swing/text/TableView/) >>> >>> Yours faithfully. >>> >>> > From alexandr.scherbatiy at oracle.com Mon Sep 12 14:36:31 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 12 Sep 2016 17:36:31 +0300 Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: <72bc3219-8476-4412-a58c-4465ac6899c2@default> References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> <72bc3219-8476-4412-a58c-4465ac6899c2@default> Message-ID: <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> On 9/9/2016 3:06 PM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ > > WTrayIconPeer.java + gr.drawImage(image, 0, 0, (autosize ? w : image.getWidth(observer)), + (autosize ? h : image.getHeight(observer)), observer); The w and h are scaled. It looks like the image.getWidth(observer) and image.getHeight(observer) also should be scaled in the same way. MultiResolutionTrayIconTest.java + latch.await(); It is better to add a timeout here. Thanks, Alexandr. > Update: Updated webrev is fixing the issue in windows only. > > We have a separate bug linux and it will be fixed through a separate > webrev. > > https://bugs.openjdk.java.net/browse/JDK-8154551 > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 14 June 2016 15:21 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: [9] Review request for JDK-8150176 [hidpi] > wrong resolution variant of multi-res. image is used for TrayIcon > > On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. I have updated the webrev as per review > comments. > > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ > > > I tried drawing the image directly to paint graphics without > buffered image and it was getting cropped. > > > Did you paint it using non scaled width and height? > g.drawImage(image, 0, 0, curW, curH, null); > Is the g transform already scaled? > > XTrayIconPeer: > > 606 if (scaleX > 1.0 && scaleY > 1.0) { > 607 resolutionVariant = ((MultiResolutionImage) > image). > > > It is better to change the condition to "image instanceof > MultiResolutionImage". It is necessary to not get CCE for non > multi-resolution image and the multi-resolution image should return > the best resolution variant for any scale. > > 618 gr.drawImage(resolutionVariant, 0, 0, > 619 curW, curH, observer); > > The width and height should be scaled here to draw to whole buffered > image. > > WTrayIconPeer: > > 133 BufferedImage bufImage = new > BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, > 134 BufferedImage.TYPE_INT_ARGB); > > The size for the buffered image should be scaled in the same was as > for XTrayIconPeer. > It may require to update the native code as well to set proper > high-resolution icon. > > Thanks, > Alexandr. > > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 09 June 2016 20:43 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review request for JDK-8150176 > [hidpi] wrong resolution variant of multi-res. image is used for > TrayIcon > > On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: > > > Hello All, > > Please review the following fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ > > > Issue: Wrong resolution variant image is used in Tray Icon. > > Fix : Applying the device transform to graphics object to > select the correct image. > > The image could be cropped on Linux because the high > resolution icon which size is bigger that the original image is > drawn to the buffered image with un-scaled size curW x CurH. > It is better to get a resolution variant from the > multi-resolution image, draw it to a buffered image with the same > scaled size and then draw the buffered image to the paint graphics > using original size: > ------- > Image resolutionVariant = ((MultiResolutionImage) > image).getResolutionVariant(scaleX * curW, scaleY * curH); > BufferedImage bufImage = new BufferedImage(scaleX * curW, > scaleY * curH, BufferedImage.TYPE_INT_ARGB); > // ... > gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, observer); > // ... > g.drawImage(bufImage, 0, 0, curW, curH, observer); // non > scaled width and height > ------- > > By the way, is the buffered image necessary in this case? Is it > possible to draw the image directly to the paint graphics? > ------- > g.drawImage(image, 0, 0, curW, curH, null); > ------- > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Sep 12 15:20:03 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 12 Sep 2016 18:20:03 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: References: <0783bb86-b1d1-32e8-8e2f-7017d2e560ab@oracle.com> <0b5c7db3-25d8-657d-d7c1-870d725f1d1c@oracle.com> <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> Message-ID: <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> The paintTabbedPaneTabBorder() without orientation should be implemented as well because it can be accessed by public API. Thanks, Alexandr. On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: > > > On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>> What reason? Why it is not public? since I provided the code example >>>> where these methods are accessed by the user? >>> GTK toollkit painting sequence is very different. >> >> What does it mean "different"? Even in this fix you implement one of >> the method according to the spec and skip the same method for some >> unknown reason. >> >>>> >>>>> I still did not get why an overload method should have the same >>>>> behavior >>>>> as its associates. This is a brand new design principle I've never >>>>> heard >>>>> before. >>>> >>>> ........... >>> That's nice... >>> Do you have any other concerns? >> >> I still do not understand why the first method with default >> orientation is not implemented. > I guess you meant "is not over-ridden". :) Once again: because it is > never used. > From semyon.sadetsky at oracle.com Mon Sep 12 15:42:22 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 12 Sep 2016 18:42:22 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> References: <0783bb86-b1d1-32e8-8e2f-7017d2e560ab@oracle.com> <0b5c7db3-25d8-657d-d7c1-870d725f1d1c@oracle.com> <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> Message-ID: <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> GTKPainter does not implement a lot of methods which can be accessed by public API. Could you, please, explain, why this specific method is more important than, for example, paintToolBarContentBackground() or paintToggleButtonBorder(), or all other unimplemented? In general, how do you separate public API methods of the SynthPainter class into two sets: the first set that *should be* over-riden and the second set of methods that *should not be* overr-riden? Are there any systematic criterium for that differentiation? --Semyon On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: > The paintTabbedPaneTabBorder() without orientation should be > implemented as well because it can be accessed by public API. > > Thanks, > Alexandr. > > On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >> >> >> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>> What reason? Why it is not public? since I provided the code example >>>>> where these methods are accessed by the user? >>>> GTK toollkit painting sequence is very different. >>> >>> What does it mean "different"? Even in this fix you implement one of >>> the method according to the spec and skip the same method for some >>> unknown reason. >>> >>>>> >>>>>> I still did not get why an overload method should have the same >>>>>> behavior >>>>>> as its associates. This is a brand new design principle I've >>>>>> never heard >>>>>> before. >>>>> >>>>> ........... >>>> That's nice... >>>> Do you have any other concerns? >>> >>> I still do not understand why the first method with default >>> orientation is not implemented. >> I guess you meant "is not over-ridden". :) Once again: because it is >> never used. >> > From alexandr.scherbatiy at oracle.com Mon Sep 12 15:50:28 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 12 Sep 2016 18:50:28 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> References: <0783bb86-b1d1-32e8-8e2f-7017d2e560ab@oracle.com> <0b5c7db3-25d8-657d-d7c1-870d725f1d1c@oracle.com> <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> Message-ID: <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: > GTKPainter does not implement a lot of methods which can be accessed > by public API. Could you, please, explain, why this specific method is > more important than, for example, paintToolBarContentBackground() or > paintToggleButtonBorder(), or all other unimplemented? > > In general, how do you separate public API methods of the SynthPainter > class into two sets: the first set that *should be* over-riden and the > second set of methods that *should not be* overr-riden? Are there any > systematic criterium for that differentiation? All the same methods with different number of arguments which do not fall to overridden implementation should be overridden to provide proper implementation. Thanks, Alexandr. > > --Semyon > > On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >> The paintTabbedPaneTabBorder() without orientation should be >> implemented as well because it can be accessed by public API. >> >> Thanks, >> Alexandr. >> >> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>> >>> >>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>> What reason? Why it is not public? since I provided the code example >>>>>> where these methods are accessed by the user? >>>>> GTK toollkit painting sequence is very different. >>>> >>>> What does it mean "different"? Even in this fix you implement one >>>> of the method according to the spec and skip the same method for >>>> some unknown reason. >>>> >>>>>> >>>>>>> I still did not get why an overload method should have the same >>>>>>> behavior >>>>>>> as its associates. This is a brand new design principle I've >>>>>>> never heard >>>>>>> before. >>>>>> >>>>>> ........... >>>>> That's nice... >>>>> Do you have any other concerns? >>>> >>>> I still do not understand why the first method with default >>>> orientation is not implemented. >>> I guess you meant "is not over-ridden". :) Once again: because it is >>> never used. >>> >> > From semyon.sadetsky at oracle.com Mon Sep 12 16:52:54 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 12 Sep 2016 19:52:54 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> References: <0783bb86-b1d1-32e8-8e2f-7017d2e560ab@oracle.com> <0b5c7db3-25d8-657d-d7c1-870d725f1d1c@oracle.com> <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> Message-ID: <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: > On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >> GTKPainter does not implement a lot of methods which can be accessed >> by public API. Could you, please, explain, why this specific method >> is more important than, for example, paintToolBarContentBackground() >> or paintToggleButtonBorder(), or all other unimplemented? >> >> In general, how do you separate public API methods of the >> SynthPainter class into two sets: the first set that *should be* >> over-riden and the second set of methods that *should not be* >> overr-riden? Are there any systematic criterium for that >> differentiation? > All the same methods with different number of arguments which do not > fall to overridden implementation should be overridden to provide > proper implementation. Where I can read about this rule for SynthPainter? And it obviously is not true. There are a lot of methods that are not over-riden in GTKPainter. I even wrote an examples above. --Semyon > > Thanks, > Alexandr. >> >> --Semyon >> >> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>> The paintTabbedPaneTabBorder() without orientation should be >>> implemented as well because it can be accessed by public API. >>> >>> Thanks, >>> Alexandr. >>> >>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>> What reason? Why it is not public? since I provided the code >>>>>>> example >>>>>>> where these methods are accessed by the user? >>>>>> GTK toollkit painting sequence is very different. >>>>> >>>>> What does it mean "different"? Even in this fix you implement one >>>>> of the method according to the spec and skip the same method for >>>>> some unknown reason. >>>>> >>>>>>> >>>>>>>> I still did not get why an overload method should have the same >>>>>>>> behavior >>>>>>>> as its associates. This is a brand new design principle I've >>>>>>>> never heard >>>>>>>> before. >>>>>>> >>>>>>> ........... >>>>>> That's nice... >>>>>> Do you have any other concerns? >>>>> >>>>> I still do not understand why the first method with default >>>>> orientation is not implemented. >>>> I guess you meant "is not over-ridden". :) Once again: because it >>>> is never used. >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Sep 12 18:48:00 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 12 Sep 2016 21:48:00 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> References: <0783bb86-b1d1-32e8-8e2f-7017d2e560ab@oracle.com> <0b5c7db3-25d8-657d-d7c1-870d725f1d1c@oracle.com> <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> Message-ID: <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: > On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: > >> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>> GTKPainter does not implement a lot of methods which can be accessed >>> by public API. Could you, please, explain, why this specific method >>> is more important than, for example, paintToolBarContentBackground() >>> or paintToggleButtonBorder(), or all other unimplemented? >>> >>> In general, how do you separate public API methods of the >>> SynthPainter class into two sets: the first set that *should be* >>> over-riden and the second set of methods that *should not be* >>> overr-riden? Are there any systematic criterium for that >>> differentiation? >> All the same methods with different number of arguments which do >> not fall to overridden implementation should be overridden to provide >> proper implementation. > Where I can read about this rule for SynthPainter? And it obviously is > not true. This is a usual rule for public methods which can be used by an external application. > There are a lot of methods that are not over-riden in GTKPainter. I > even wrote an examples above. The SynthPainter.paintToolBarContentBackground(..., orientation) calls SynthPainter.paintToolBarContentBackground(...) without the orientation and the GTKPainter .paintToolBarContentBackground overrides the method without the orientation. So calls to gtkPainter.paintToolBarContentBackground(..., orientation) falls down to the overriden method in GTKPainter. The same is for SynthPainter.paintProgressBarBackground(..., orientation) and paintScrollBarBackground(..., orientation) methods. The SynthPainter has only one paintToggleButtonBorder() method. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>> >>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>> The paintTabbedPaneTabBorder() without orientation should be >>>> implemented as well because it can be accessed by public API. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>> What reason? Why it is not public? since I provided the code >>>>>>>> example >>>>>>>> where these methods are accessed by the user? >>>>>>> GTK toollkit painting sequence is very different. >>>>>> >>>>>> What does it mean "different"? Even in this fix you implement one >>>>>> of the method according to the spec and skip the same method for >>>>>> some unknown reason. >>>>>> >>>>>>>> >>>>>>>>> I still did not get why an overload method should have the >>>>>>>>> same behavior >>>>>>>>> as its associates. This is a brand new design principle I've >>>>>>>>> never heard >>>>>>>>> before. >>>>>>>> >>>>>>>> ........... >>>>>>> That's nice... >>>>>>> Do you have any other concerns? >>>>>> >>>>>> I still do not understand why the first method with default >>>>>> orientation is not implemented. >>>>> I guess you meant "is not over-ridden". :) Once again: because it >>>>> is never used. >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Mon Sep 12 19:42:58 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 12 Sep 2016 22:42:58 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> References: <0783bb86-b1d1-32e8-8e2f-7017d2e560ab@oracle.com> <0b5c7db3-25d8-657d-d7c1-870d725f1d1c@oracle.com> <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> Message-ID: <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: > On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >> >>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>> GTKPainter does not implement a lot of methods which can be >>>> accessed by public API. Could you, please, explain, why this >>>> specific method is more important than, for example, >>>> paintToolBarContentBackground() or paintToggleButtonBorder(), or >>>> all other unimplemented? >>>> >>>> In general, how do you separate public API methods of the >>>> SynthPainter class into two sets: the first set that *should be* >>>> over-riden and the second set of methods that *should not be* >>>> overr-riden? Are there any systematic criterium for that >>>> differentiation? >>> All the same methods with different number of arguments which do >>> not fall to overridden implementation should be overridden to >>> provide proper implementation. >> Where I can read about this rule for SynthPainter? And it obviously >> is not true. > This is a usual rule for public methods which can be used by an > external application. >> There are a lot of methods that are not over-riden in GTKPainter. I >> even wrote an examples above. > The SynthPainter.paintToolBarContentBackground(..., orientation) > calls SynthPainter.paintToolBarContentBackground(...) without the > orientation and the GTKPainter .paintToolBarContentBackground > overrides the method without the orientation. So calls to > gtkPainter.paintToolBarContentBackground(..., orientation) falls down > to the overriden method in GTKPainter. > > The same is for SynthPainter.paintProgressBarBackground(..., > orientation) and paintScrollBarBackground(..., orientation) methods. > > The SynthPainter has only one paintToggleButtonBorder() method. Interesting rule... I thought that more specific method version may have different implementation. What would you say about paintSeparatorBackground() ? It's (..., orientation) version is over-ridden while the generic version is not over-ridden. --Semyon > > Thanks, > Alexandr. > > >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>> >>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>> The paintTabbedPaneTabBorder() without orientation should be >>>>> implemented as well because it can be accessed by public API. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>> What reason? Why it is not public? since I provided the code >>>>>>>>> example >>>>>>>>> where these methods are accessed by the user? >>>>>>>> GTK toollkit painting sequence is very different. >>>>>>> >>>>>>> What does it mean "different"? Even in this fix you implement >>>>>>> one of the method according to the spec and skip the same method >>>>>>> for some unknown reason. >>>>>>> >>>>>>>>> >>>>>>>>>> I still did not get why an overload method should have the >>>>>>>>>> same behavior >>>>>>>>>> as its associates. This is a brand new design principle I've >>>>>>>>>> never heard >>>>>>>>>> before. >>>>>>>>> >>>>>>>>> ........... >>>>>>>> That's nice... >>>>>>>> Do you have any other concerns? >>>>>>> >>>>>>> I still do not understand why the first method with default >>>>>>> orientation is not implemented. >>>>>> I guess you meant "is not over-ridden". :) Once again: because it >>>>>> is never used. >>>>>> >>>>> >>>> >>> >> > From ken.x.chen at oracle.com Mon Sep 12 21:50:39 2016 From: ken.x.chen at oracle.com (Ken Chen) Date: Mon, 12 Sep 2016 14:50:39 -0700 Subject: RFR: JDK-8165799 Fix license and copyright headers under test/java/swing Message-ID: <01cc6176-48e9-29e4-f4d9-f7bb0921d35b@oracle.com> ** *Hello,* * Please review the patch below which fixes copyright in test files for awt *Bug: https://bugs.openjdk.java.net/browse/JDK-8165799* *Webrev: http://cr.openjdk.java.net/~shurailine/8165799/webrev.00/* Thanks, -Ken* -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 13 12:29:33 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Sep 2016 15:29:33 +0300 Subject: RFR: JDK-8165799 Fix license and copyright headers under test/java/swing In-Reply-To: <01cc6176-48e9-29e4-f4d9-f7bb0921d35b@oracle.com> References: <01cc6176-48e9-29e4-f4d9-f7bb0921d35b@oracle.com> Message-ID: The fix looks good to me. Thanks, Alexandr. On 9/13/2016 12:50 AM, Ken Chen wrote: > > ** > > *Hello,* > > * > > Please review the patch below which fixes copyright in test files for awt > > > *Bug: https://bugs.openjdk.java.net/browse/JDK-8165799* > > *Webrev: > http://cr.openjdk.java.net/~shurailine/8165799/webrev.00/* > > > Thanks, > > -Ken* -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Sep 13 12:50:56 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 13 Sep 2016 15:50:56 +0300 Subject: RFR: JDK-8165799 Fix license and copyright headers under test/java/swing In-Reply-To: References: <01cc6176-48e9-29e4-f4d9-f7bb0921d35b@oracle.com> Message-ID: <5178bacd-338d-64cc-a6ad-f5119a3be3e1@oracle.com> +1 --Semyon On 9/13/2016 3:29 PM, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/13/2016 12:50 AM, Ken Chen wrote: >> >> ** >> >> *Hello,* >> >> * >> >> Please review the patch below which fixes copyright in test files for awt >> >> >> *Bug: https://bugs.openjdk.java.net/browse/JDK-8165799* >> >> *Webrev: >> http://cr.openjdk.java.net/~shurailine/8165799/webrev.00/* >> >> >> Thanks, >> >> -Ken* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Sep 13 12:51:16 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 Sep 2016 15:51:16 +0300 Subject: RFR: JDK-8165799 Fix license and copyright headers under test/java/swing In-Reply-To: References: <01cc6176-48e9-29e4-f4d9-f7bb0921d35b@oracle.com> Message-ID: +1 On 13.09.16 15:29, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/13/2016 12:50 AM, Ken Chen wrote: >> >> ** >> >> *Hello,* >> >> * >> >> Please review the patch below which fixes copyright in test files for awt >> >> >> *Bug: https://bugs.openjdk.java.net/browse/JDK-8165799* >> >> *Webrev: >> http://cr.openjdk.java.net/~shurailine/8165799/webrev.00/* >> >> >> Thanks, >> >> -Ken* > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Tue Sep 13 16:21:28 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Sep 2016 19:21:28 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> References: <0b5c7db3-25d8-657d-d7c1-870d725f1d1c@oracle.com> <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> Message-ID: <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: > > > On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>> >>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>> GTKPainter does not implement a lot of methods which can be >>>>> accessed by public API. Could you, please, explain, why this >>>>> specific method is more important than, for example, >>>>> paintToolBarContentBackground() or paintToggleButtonBorder(), or >>>>> all other unimplemented? >>>>> >>>>> In general, how do you separate public API methods of the >>>>> SynthPainter class into two sets: the first set that *should be* >>>>> over-riden and the second set of methods that *should not be* >>>>> overr-riden? Are there any systematic criterium for that >>>>> differentiation? >>>> All the same methods with different number of arguments which do >>>> not fall to overridden implementation should be overridden to >>>> provide proper implementation. >>> Where I can read about this rule for SynthPainter? And it obviously >>> is not true. >> This is a usual rule for public methods which can be used by an >> external application. >>> There are a lot of methods that are not over-riden in GTKPainter. I >>> even wrote an examples above. >> The SynthPainter.paintToolBarContentBackground(..., orientation) >> calls SynthPainter.paintToolBarContentBackground(...) without the >> orientation and the GTKPainter .paintToolBarContentBackground >> overrides the method without the orientation. So calls to >> gtkPainter.paintToolBarContentBackground(..., orientation) falls down >> to the overriden method in GTKPainter. >> >> The same is for SynthPainter.paintProgressBarBackground(..., >> orientation) and paintScrollBarBackground(..., orientation) methods. >> >> The SynthPainter has only one paintToggleButtonBorder() method. > Interesting rule... I thought that more specific method version may > have different implementation. It was done for historical reason. For example before the fix JDK-5033822 "Synth ScrollBar paintTrack() dosn't support orientation" there was only paintScrollBarBackground() method without the orientation in the SynthPainter class. After the fix the paintScrollBarBackground() method with the orientation is added which default implementation just calls the same method without the orientation because old user's subclasses can override the method without the orientation an not be aware about new method version. > What would you say about paintSeparatorBackground() ? > It's (..., orientation) version is over-ridden while the generic > version is not over-ridden. I guess that it is just a bug. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >> >> >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>> >>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>> The paintTabbedPaneTabBorder() without orientation should be >>>>>> implemented as well because it can be accessed by public API. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>> What reason? Why it is not public? since I provided the code >>>>>>>>>> example >>>>>>>>>> where these methods are accessed by the user? >>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>> >>>>>>>> What does it mean "different"? Even in this fix you implement >>>>>>>> one of the method according to the spec and skip the same >>>>>>>> method for some unknown reason. >>>>>>>> >>>>>>>>>> >>>>>>>>>>> I still did not get why an overload method should have the >>>>>>>>>>> same behavior >>>>>>>>>>> as its associates. This is a brand new design principle I've >>>>>>>>>>> never heard >>>>>>>>>>> before. >>>>>>>>>> >>>>>>>>>> ........... >>>>>>>>> That's nice... >>>>>>>>> Do you have any other concerns? >>>>>>>> >>>>>>>> I still do not understand why the first method with default >>>>>>>> orientation is not implemented. >>>>>>> I guess you meant "is not over-ridden". :) Once again: because >>>>>>> it is never used. >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Tue Sep 13 16:38:40 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 13 Sep 2016 19:38:40 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> References: <7cfe9022-8940-11da-8958-edbc3d01be48@oracle.com> <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> Message-ID: <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: > On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >> >> >> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>> >>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>> GTKPainter does not implement a lot of methods which can be >>>>>> accessed by public API. Could you, please, explain, why this >>>>>> specific method is more important than, for example, >>>>>> paintToolBarContentBackground() or paintToggleButtonBorder(), or >>>>>> all other unimplemented? >>>>>> >>>>>> In general, how do you separate public API methods of the >>>>>> SynthPainter class into two sets: the first set that *should be* >>>>>> over-riden and the second set of methods that *should not be* >>>>>> overr-riden? Are there any systematic criterium for that >>>>>> differentiation? >>>>> All the same methods with different number of arguments which do >>>>> not fall to overridden implementation should be overridden to >>>>> provide proper implementation. >>>> Where I can read about this rule for SynthPainter? And it obviously >>>> is not true. >>> This is a usual rule for public methods which can be used by an >>> external application. >>>> There are a lot of methods that are not over-riden in GTKPainter. I >>>> even wrote an examples above. >>> The SynthPainter.paintToolBarContentBackground(..., orientation) >>> calls SynthPainter.paintToolBarContentBackground(...) without the >>> orientation and the GTKPainter .paintToolBarContentBackground >>> overrides the method without the orientation. So calls to >>> gtkPainter.paintToolBarContentBackground(..., orientation) falls >>> down to the overriden method in GTKPainter. >>> >>> The same is for SynthPainter.paintProgressBarBackground(..., >>> orientation) and paintScrollBarBackground(..., orientation) methods. >>> >>> The SynthPainter has only one paintToggleButtonBorder() method. >> Interesting rule... I thought that more specific method version may >> have different implementation. > It was done for historical reason. For example before the fix > JDK-5033822 "Synth ScrollBar paintTrack() dosn't support orientation" > there was only paintScrollBarBackground() method without the > orientation in the SynthPainter class. > After the fix the paintScrollBarBackground() method with the > orientation is added which default implementation just calls the same > method without the orientation because old user's subclasses can > override the method without the orientation an not be aware about new > method version. > >> What would you say about paintSeparatorBackground() ? >> It's (..., orientation) version is over-ridden while the generic >> version is not over-ridden. > I guess that it is just a bug. Not sure. GTKPainter has never been providing a systematic API from the beginning. It is not for an arbitrary external use, because the resulting painting will be unpredictable. I explained this in this thread many times. And even if I would like to provide this useless method implementation I were not able to do this because the orientation is a required parameter to paint the GTK tab border. --Semyon > > Thanks, > Alexandr. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>> >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>> >>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>> The paintTabbedPaneTabBorder() without orientation should be >>>>>>> implemented as well because it can be accessed by public API. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>> What reason? Why it is not public? since I provided the code >>>>>>>>>>> example >>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>> >>>>>>>>> What does it mean "different"? Even in this fix you implement >>>>>>>>> one of the method according to the spec and skip the same >>>>>>>>> method for some unknown reason. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I still did not get why an overload method should have the >>>>>>>>>>>> same behavior >>>>>>>>>>>> as its associates. This is a brand new design principle >>>>>>>>>>>> I've never heard >>>>>>>>>>>> before. >>>>>>>>>>> >>>>>>>>>>> ........... >>>>>>>>>> That's nice... >>>>>>>>>> Do you have any other concerns? >>>>>>>>> >>>>>>>>> I still do not understand why the first method with default >>>>>>>>> orientation is not implemented. >>>>>>>> I guess you meant "is not over-ridden". :) Once again: because >>>>>>>> it is never used. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Sep 13 17:25:14 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Sep 2016 20:25:14 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> References: <58393096-52a8-b004-729e-3150d7296153@oracle.com> <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> Message-ID: <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: > > > On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>> >>> >>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>> >>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>> GTKPainter does not implement a lot of methods which can be >>>>>>> accessed by public API. Could you, please, explain, why this >>>>>>> specific method is more important than, for example, >>>>>>> paintToolBarContentBackground() or paintToggleButtonBorder(), or >>>>>>> all other unimplemented? >>>>>>> >>>>>>> In general, how do you separate public API methods of the >>>>>>> SynthPainter class into two sets: the first set that *should be* >>>>>>> over-riden and the second set of methods that *should not be* >>>>>>> overr-riden? Are there any systematic criterium for that >>>>>>> differentiation? >>>>>> All the same methods with different number of arguments which >>>>>> do not fall to overridden implementation should be overridden to >>>>>> provide proper implementation. >>>>> Where I can read about this rule for SynthPainter? And it >>>>> obviously is not true. >>>> This is a usual rule for public methods which can be used by an >>>> external application. >>>>> There are a lot of methods that are not over-riden in GTKPainter. >>>>> I even wrote an examples above. >>>> The SynthPainter.paintToolBarContentBackground(..., orientation) >>>> calls SynthPainter.paintToolBarContentBackground(...) without the >>>> orientation and the GTKPainter .paintToolBarContentBackground >>>> overrides the method without the orientation. So calls to >>>> gtkPainter.paintToolBarContentBackground(..., orientation) falls >>>> down to the overriden method in GTKPainter. >>>> >>>> The same is for SynthPainter.paintProgressBarBackground(..., >>>> orientation) and paintScrollBarBackground(..., orientation) methods. >>>> >>>> The SynthPainter has only one paintToggleButtonBorder() method. >>> Interesting rule... I thought that more specific method version may >>> have different implementation. >> It was done for historical reason. For example before the fix >> JDK-5033822 "Synth ScrollBar paintTrack() dosn't support orientation" >> there was only paintScrollBarBackground() method without the >> orientation in the SynthPainter class. >> After the fix the paintScrollBarBackground() method with the >> orientation is added which default implementation just calls the same >> method without the orientation because old user's subclasses can >> override the method without the orientation an not be aware about new >> method version. >> >>> What would you say about paintSeparatorBackground() ? >>> It's (..., orientation) version is over-ridden while the generic >>> version is not over-ridden. >> I guess that it is just a bug. > Not sure. GTKPainter has never been providing a systematic API from > the beginning. It is not for an arbitrary external use, because the > resulting painting will be unpredictable. I explained this in this > thread many times. And even if I would like to provide this useless > method implementation It is a part of the public SynthPainter API and can be called by an external application. > I were not able to do this because the orientation is a required > parameter to paint the GTK tab border. The overridden method without the orientation can just call the overridden method with orientation passing a default orientation value. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>> The paintTabbedPaneTabBorder() without orientation should be >>>>>>>> implemented as well because it can be accessed by public API. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>> What reason? Why it is not public? since I provided the >>>>>>>>>>>> code example >>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>> >>>>>>>>>> What does it mean "different"? Even in this fix you implement >>>>>>>>>> one of the method according to the spec and skip the same >>>>>>>>>> method for some unknown reason. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I still did not get why an overload method should have the >>>>>>>>>>>>> same behavior >>>>>>>>>>>>> as its associates. This is a brand new design principle >>>>>>>>>>>>> I've never heard >>>>>>>>>>>>> before. >>>>>>>>>>>> >>>>>>>>>>>> ........... >>>>>>>>>>> That's nice... >>>>>>>>>>> Do you have any other concerns? >>>>>>>>>> >>>>>>>>>> I still do not understand why the first method with default >>>>>>>>>> orientation is not implemented. >>>>>>>>> I guess you meant "is not over-ridden". :) Once again: because >>>>>>>>> it is never used. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Tue Sep 13 17:34:54 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 13 Sep 2016 20:34:54 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> References: <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> Message-ID: On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: > On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >> >> >> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>> GTKPainter does not implement a lot of methods which can be >>>>>>>> accessed by public API. Could you, please, explain, why this >>>>>>>> specific method is more important than, for example, >>>>>>>> paintToolBarContentBackground() or paintToggleButtonBorder(), >>>>>>>> or all other unimplemented? >>>>>>>> >>>>>>>> In general, how do you separate public API methods of the >>>>>>>> SynthPainter class into two sets: the first set that *should >>>>>>>> be* over-riden and the second set of methods that *should not >>>>>>>> be* overr-riden? Are there any systematic criterium for that >>>>>>>> differentiation? >>>>>>> All the same methods with different number of arguments which >>>>>>> do not fall to overridden implementation should be overridden to >>>>>>> provide proper implementation. >>>>>> Where I can read about this rule for SynthPainter? And it >>>>>> obviously is not true. >>>>> This is a usual rule for public methods which can be used by an >>>>> external application. >>>>>> There are a lot of methods that are not over-riden in GTKPainter. >>>>>> I even wrote an examples above. >>>>> The SynthPainter.paintToolBarContentBackground(..., orientation) >>>>> calls SynthPainter.paintToolBarContentBackground(...) without the >>>>> orientation and the GTKPainter .paintToolBarContentBackground >>>>> overrides the method without the orientation. So calls to >>>>> gtkPainter.paintToolBarContentBackground(..., orientation) falls >>>>> down to the overriden method in GTKPainter. >>>>> >>>>> The same is for SynthPainter.paintProgressBarBackground(..., >>>>> orientation) and paintScrollBarBackground(..., orientation) methods. >>>>> >>>>> The SynthPainter has only one paintToggleButtonBorder() method. >>>> Interesting rule... I thought that more specific method version may >>>> have different implementation. >>> It was done for historical reason. For example before the fix >>> JDK-5033822 "Synth ScrollBar paintTrack() dosn't support orientation" >>> there was only paintScrollBarBackground() method without the >>> orientation in the SynthPainter class. >>> After the fix the paintScrollBarBackground() method with the >>> orientation is added which default implementation just calls the >>> same method without the orientation because old user's subclasses >>> can override the method without the orientation an not be aware >>> about new method version. >>> >>>> What would you say about paintSeparatorBackground() ? >>>> It's (..., orientation) version is over-ridden while the generic >>>> version is not over-ridden. >>> I guess that it is just a bug. >> Not sure. GTKPainter has never been providing a systematic API from >> the beginning. It is not for an arbitrary external use, because the >> resulting painting will be unpredictable. I explained this in this >> thread many times. And even if I would like to provide this useless >> method implementation > It is a part of the public SynthPainter API and can be called by an > external application. I can be called without any predictable result. This is the current state. It cannot be changed by the change you are proposing to add. >> I were not able to do this because the orientation is a required >> parameter to paint the GTK tab border. > The overridden method without the orientation can just call the > overridden method with orientation passing a default orientation value. And what the default value is? It is not defined. --Semyon > > Thanks, > Alexandr. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>> The paintTabbedPaneTabBorder() without orientation should be >>>>>>>>> implemented as well because it can be accessed by public API. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>> What reason? Why it is not public? since I provided the >>>>>>>>>>>>> code example >>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>> >>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>> implement one of the method according to the spec and skip >>>>>>>>>>> the same method for some unknown reason. >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I still did not get why an overload method should have >>>>>>>>>>>>>> the same behavior >>>>>>>>>>>>>> as its associates. This is a brand new design principle >>>>>>>>>>>>>> I've never heard >>>>>>>>>>>>>> before. >>>>>>>>>>>>> >>>>>>>>>>>>> ........... >>>>>>>>>>>> That's nice... >>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>> >>>>>>>>>>> I still do not understand why the first method with default >>>>>>>>>>> orientation is not implemented. >>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>> because it is never used. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From iris.clark at oracle.com Tue Sep 13 17:42:54 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 13 Sep 2016 10:42:54 -0700 (PDT) Subject: RFR: JDK-8165799 Fix license and copyright headers under test/java/swing In-Reply-To: <01cc6176-48e9-29e4-f4d9-f7bb0921d35b@oracle.com> References: <01cc6176-48e9-29e4-f4d9-f7bb0921d35b@oracle.com> Message-ID: <6fb8531b-5a29-4304-8edf-55359b8a7857@default> Hi, Ken. ? You changes look good to me. ? Thanks, Iris (not a Reviewer) ? From: Ken Chen Sent: Monday, September 12, 2016 2:51 PM To: swing-dev at openjdk.java.net Cc: Ken Chen Subject: RFR: JDK-8165799 Fix license and copyright headers under test/java/swing ? Hello, ? Please review the patch below which fixes copyright in test files for awt ? Bug: https://bugs.openjdk.java.net/browse/JDK-8165799 Webrev: http://cr.openjdk.java.net/~shurailine/8165799/webrev.00/ ? Thanks, -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 13 17:46:16 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Sep 2016 20:46:16 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: References: <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> Message-ID: On 9/13/2016 8:34 PM, Semyon Sadetsky wrote: > > > On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: >> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >>> >>> >>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>>> GTKPainter does not implement a lot of methods which can be >>>>>>>>> accessed by public API. Could you, please, explain, why this >>>>>>>>> specific method is more important than, for example, >>>>>>>>> paintToolBarContentBackground() or paintToggleButtonBorder(), >>>>>>>>> or all other unimplemented? >>>>>>>>> >>>>>>>>> In general, how do you separate public API methods of the >>>>>>>>> SynthPainter class into two sets: the first set that *should >>>>>>>>> be* over-riden and the second set of methods that *should not >>>>>>>>> be* overr-riden? Are there any systematic criterium for that >>>>>>>>> differentiation? >>>>>>>> All the same methods with different number of arguments which >>>>>>>> do not fall to overridden implementation should be overridden >>>>>>>> to provide proper implementation. >>>>>>> Where I can read about this rule for SynthPainter? And it >>>>>>> obviously is not true. >>>>>> This is a usual rule for public methods which can be used by an >>>>>> external application. >>>>>>> There are a lot of methods that are not over-riden in >>>>>>> GTKPainter. I even wrote an examples above. >>>>>> The SynthPainter.paintToolBarContentBackground(..., >>>>>> orientation) calls >>>>>> SynthPainter.paintToolBarContentBackground(...) without the >>>>>> orientation and the GTKPainter .paintToolBarContentBackground >>>>>> overrides the method without the orientation. So calls to >>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) falls >>>>>> down to the overriden method in GTKPainter. >>>>>> >>>>>> The same is for SynthPainter.paintProgressBarBackground(..., >>>>>> orientation) and paintScrollBarBackground(..., orientation) methods. >>>>>> >>>>>> The SynthPainter has only one paintToggleButtonBorder() method. >>>>> Interesting rule... I thought that more specific method version >>>>> may have different implementation. >>>> It was done for historical reason. For example before the fix >>>> JDK-5033822 "Synth ScrollBar paintTrack() dosn't support orientation" >>>> there was only paintScrollBarBackground() method without the >>>> orientation in the SynthPainter class. >>>> After the fix the paintScrollBarBackground() method with the >>>> orientation is added which default implementation just calls the >>>> same method without the orientation because old user's subclasses >>>> can override the method without the orientation an not be aware >>>> about new method version. >>>> >>>>> What would you say about paintSeparatorBackground() ? >>>>> It's (..., orientation) version is over-ridden while the generic >>>>> version is not over-ridden. >>>> I guess that it is just a bug. >>> Not sure. GTKPainter has never been providing a systematic API from >>> the beginning. It is not for an arbitrary external use, because the >>> resulting painting will be unpredictable. I explained this in this >>> thread many times. And even if I would like to provide this useless >>> method implementation >> It is a part of the public SynthPainter API and can be called by an >> external application. > I can be called without any predictable result. This is the current > state. It cannot be changed by the change you are proposing to add. The result is described in the public method javadoc. >>> I were not able to do this because the orientation is a required >>> parameter to paint the GTK tab border. >> The overridden method without the orientation can just call the >> overridden method with orientation passing a default orientation value. > And what the default value is? It is not defined. https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html Creates a new horizontal separator: Constructor JSeparator(). Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> The paintTabbedPaneTabBorder() without orientation should be >>>>>>>>>> implemented as well because it can be accessed by public API. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>>> What reason? Why it is not public? since I provided the >>>>>>>>>>>>>> code example >>>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>>> >>>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>>> implement one of the method according to the spec and skip >>>>>>>>>>>> the same method for some unknown reason. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I still did not get why an overload method should have >>>>>>>>>>>>>>> the same behavior >>>>>>>>>>>>>>> as its associates. This is a brand new design principle >>>>>>>>>>>>>>> I've never heard >>>>>>>>>>>>>>> before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ........... >>>>>>>>>>>>> That's nice... >>>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>>> >>>>>>>>>>>> I still do not understand why the first method with default >>>>>>>>>>>> orientation is not implemented. >>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>>> because it is never used. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Tue Sep 13 17:49:15 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 13 Sep 2016 20:49:15 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: References: <31dd47c4-946b-89d2-94f7-119eef866db8@oracle.com> <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> Message-ID: <0f57ef7f-a8ad-fef0-5be9-b71250c23022@oracle.com> On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote: > On 9/13/2016 8:34 PM, Semyon Sadetsky wrote: >> >> >> On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: >>> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>>>> GTKPainter does not implement a lot of methods which can be >>>>>>>>>> accessed by public API. Could you, please, explain, why this >>>>>>>>>> specific method is more important than, for example, >>>>>>>>>> paintToolBarContentBackground() or paintToggleButtonBorder(), >>>>>>>>>> or all other unimplemented? >>>>>>>>>> >>>>>>>>>> In general, how do you separate public API methods of the >>>>>>>>>> SynthPainter class into two sets: the first set that *should >>>>>>>>>> be* over-riden and the second set of methods that *should not >>>>>>>>>> be* overr-riden? Are there any systematic criterium for that >>>>>>>>>> differentiation? >>>>>>>>> All the same methods with different number of arguments >>>>>>>>> which do not fall to overridden implementation should be >>>>>>>>> overridden to provide proper implementation. >>>>>>>> Where I can read about this rule for SynthPainter? And it >>>>>>>> obviously is not true. >>>>>>> This is a usual rule for public methods which can be used by >>>>>>> an external application. >>>>>>>> There are a lot of methods that are not over-riden in >>>>>>>> GTKPainter. I even wrote an examples above. >>>>>>> The SynthPainter.paintToolBarContentBackground(..., >>>>>>> orientation) calls >>>>>>> SynthPainter.paintToolBarContentBackground(...) without the >>>>>>> orientation and the GTKPainter .paintToolBarContentBackground >>>>>>> overrides the method without the orientation. So calls to >>>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) falls >>>>>>> down to the overriden method in GTKPainter. >>>>>>> >>>>>>> The same is for SynthPainter.paintProgressBarBackground(..., >>>>>>> orientation) and paintScrollBarBackground(..., orientation) >>>>>>> methods. >>>>>>> >>>>>>> The SynthPainter has only one paintToggleButtonBorder() method. >>>>>> Interesting rule... I thought that more specific method version >>>>>> may have different implementation. >>>>> It was done for historical reason. For example before the fix >>>>> JDK-5033822 "Synth ScrollBar paintTrack() dosn't support orientation" >>>>> there was only paintScrollBarBackground() method without the >>>>> orientation in the SynthPainter class. >>>>> After the fix the paintScrollBarBackground() method with the >>>>> orientation is added which default implementation just calls the >>>>> same method without the orientation because old user's subclasses >>>>> can override the method without the orientation an not be aware >>>>> about new method version. >>>>> >>>>>> What would you say about paintSeparatorBackground() ? >>>>>> It's (..., orientation) version is over-ridden while the generic >>>>>> version is not over-ridden. >>>>> I guess that it is just a bug. >>>> Not sure. GTKPainter has never been providing a systematic API from >>>> the beginning. It is not for an arbitrary external use, because the >>>> resulting painting will be unpredictable. I explained this in this >>>> thread many times. And even if I would like to provide this useless >>>> method implementation >>> It is a part of the public SynthPainter API and can be called by >>> an external application. >> I can be called without any predictable result. This is the current >> state. It cannot be changed by the change you are proposing to add. > The result is described in the public method javadoc. >>>> I were not able to do this because the orientation is a required >>>> parameter to paint the GTK tab border. >>> The overridden method without the orientation can just call the >>> overridden method with orientation passing a default orientation value. >> And what the default value is? It is not defined. > https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html > Creates a new horizontal separator: Constructor JSeparator(). Sorry, I didn't get how the separator orientation is related to tabbed pane border. --Semyon > > Thanks, > Alexandr. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> The paintTabbedPaneTabBorder() without orientation should be >>>>>>>>>>> implemented as well because it can be accessed by public API. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>>>> What reason? Why it is not public? since I provided the >>>>>>>>>>>>>>> code example >>>>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>>>> >>>>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>>>> implement one of the method according to the spec and skip >>>>>>>>>>>>> the same method for some unknown reason. >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I still did not get why an overload method should have >>>>>>>>>>>>>>>> the same behavior >>>>>>>>>>>>>>>> as its associates. This is a brand new design principle >>>>>>>>>>>>>>>> I've never heard >>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ........... >>>>>>>>>>>>>> That's nice... >>>>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>>>> >>>>>>>>>>>>> I still do not understand why the first method with >>>>>>>>>>>>> default orientation is not implemented. >>>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>>>> because it is never used. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Sep 13 18:03:47 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Sep 2016 21:03:47 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <0f57ef7f-a8ad-fef0-5be9-b71250c23022@oracle.com> References: <5bf7d813-35e4-5848-4945-7fad4cf18d9f@oracle.com> <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> <0f57ef7f-a8ad-fef0-5be9-b71250c23022@oracle.com> Message-ID: On 9/13/2016 8:49 PM, Semyon Sadetsky wrote: > On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote: >> On 9/13/2016 8:34 PM, Semyon Sadetsky wrote: >>> >>> On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: >>>> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>>>>> GTKPainter does not implement a lot of methods which can be >>>>>>>>>>> accessed by public API. Could you, please, explain, why this >>>>>>>>>>> specific method is more important than, for example, >>>>>>>>>>> paintToolBarContentBackground() or >>>>>>>>>>> paintToggleButtonBorder(), or all other unimplemented? >>>>>>>>>>> >>>>>>>>>>> In general, how do you separate public API methods of the >>>>>>>>>>> SynthPainter class into two sets: the first set that *should >>>>>>>>>>> be* over-riden and the second set of methods that *should >>>>>>>>>>> not be* overr-riden? Are there any systematic criterium for >>>>>>>>>>> that differentiation? >>>>>>>>>> All the same methods with different number of arguments >>>>>>>>>> which do not fall to overridden implementation should be >>>>>>>>>> overridden to provide proper implementation. >>>>>>>>> Where I can read about this rule for SynthPainter? And it >>>>>>>>> obviously is not true. >>>>>>>> This is a usual rule for public methods which can be used by >>>>>>>> an external application. >>>>>>>>> There are a lot of methods that are not over-riden in >>>>>>>>> GTKPainter. I even wrote an examples above. >>>>>>>> The SynthPainter.paintToolBarContentBackground(..., >>>>>>>> orientation) calls >>>>>>>> SynthPainter.paintToolBarContentBackground(...) without the >>>>>>>> orientation and the GTKPainter .paintToolBarContentBackground >>>>>>>> overrides the method without the orientation. So calls to >>>>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) >>>>>>>> falls down to the overriden method in GTKPainter. >>>>>>>> >>>>>>>> The same is for SynthPainter.paintProgressBarBackground(..., >>>>>>>> orientation) and paintScrollBarBackground(..., orientation) >>>>>>>> methods. >>>>>>>> >>>>>>>> The SynthPainter has only one paintToggleButtonBorder() method. >>>>>>> Interesting rule... I thought that more specific method version >>>>>>> may have different implementation. >>>>>> It was done for historical reason. For example before the fix >>>>>> JDK-5033822 "Synth ScrollBar paintTrack() dosn't support >>>>>> orientation" >>>>>> there was only paintScrollBarBackground() method without the >>>>>> orientation in the SynthPainter class. >>>>>> After the fix the paintScrollBarBackground() method with the >>>>>> orientation is added which default implementation just calls the >>>>>> same method without the orientation because old user's subclasses >>>>>> can override the method without the orientation an not be aware >>>>>> about new method version. >>>>>> >>>>>>> What would you say about paintSeparatorBackground() ? >>>>>>> It's (..., orientation) version is over-ridden while the generic >>>>>>> version is not over-ridden. >>>>>> I guess that it is just a bug. >>>>> Not sure. GTKPainter has never been providing a systematic API >>>>> from the beginning. It is not for an arbitrary external use, >>>>> because the resulting painting will be unpredictable. I explained >>>>> this in this thread many times. And even if I would like to >>>>> provide this useless method implementation >>>> It is a part of the public SynthPainter API and can be called by >>>> an external application. >>> I can be called without any predictable result. This is the current >>> state. It cannot be changed by the change you are proposing to add. >> The result is described in the public method javadoc. >>>>> I were not able to do this because the orientation is a required >>>>> parameter to paint the GTK tab border. >>>> The overridden method without the orientation can just call the >>>> overridden method with orientation passing a default orientation >>>> value. >>> And what the default value is? It is not defined. >> https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html >> Creates a new horizontal separator: Constructor JSeparator(). > Sorry, I didn't get how the separator orientation is related to tabbed > pane border. https://docs.oracle.com/javase/7/docs/api/javax/swing/JTabbedPane.html#setTabPlacement(int) The default value, if not set, is SwingConstants.TOP. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> The paintTabbedPaneTabBorder() without orientation should >>>>>>>>>>>> be implemented as well because it can be accessed by public >>>>>>>>>>>> API. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>> What reason? Why it is not public? since I provided the >>>>>>>>>>>>>>>> code example >>>>>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>>>>> implement one of the method according to the spec and >>>>>>>>>>>>>> skip the same method for some unknown reason. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I still did not get why an overload method should have >>>>>>>>>>>>>>>>> the same behavior >>>>>>>>>>>>>>>>> as its associates. This is a brand new design >>>>>>>>>>>>>>>>> principle I've never heard >>>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ........... >>>>>>>>>>>>>>> That's nice... >>>>>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I still do not understand why the first method with >>>>>>>>>>>>>> default orientation is not implemented. >>>>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>>>>> because it is never used. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Wed Sep 14 08:51:44 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 14 Sep 2016 11:51:44 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: References: <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> <0f57ef7f-a8ad-fef0-5be9-b71250c23022@oracle.com> Message-ID: On 9/13/2016 9:03 PM, Alexandr Scherbatiy wrote: > On 9/13/2016 8:49 PM, Semyon Sadetsky wrote: >> On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote: >>> On 9/13/2016 8:34 PM, Semyon Sadetsky wrote: >>>> >>>> On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: >>>>> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> GTKPainter does not implement a lot of methods which can be >>>>>>>>>>>> accessed by public API. Could you, please, explain, why >>>>>>>>>>>> this specific method is more important than, for example, >>>>>>>>>>>> paintToolBarContentBackground() or >>>>>>>>>>>> paintToggleButtonBorder(), or all other unimplemented? >>>>>>>>>>>> >>>>>>>>>>>> In general, how do you separate public API methods of the >>>>>>>>>>>> SynthPainter class into two sets: the first set that >>>>>>>>>>>> *should be* over-riden and the second set of methods that >>>>>>>>>>>> *should not be* overr-riden? Are there any systematic >>>>>>>>>>>> criterium for that differentiation? >>>>>>>>>>> All the same methods with different number of arguments >>>>>>>>>>> which do not fall to overridden implementation should be >>>>>>>>>>> overridden to provide proper implementation. >>>>>>>>>> Where I can read about this rule for SynthPainter? And it >>>>>>>>>> obviously is not true. >>>>>>>>> This is a usual rule for public methods which can be used by >>>>>>>>> an external application. >>>>>>>>>> There are a lot of methods that are not over-riden in >>>>>>>>>> GTKPainter. I even wrote an examples above. >>>>>>>>> The SynthPainter.paintToolBarContentBackground(..., >>>>>>>>> orientation) calls >>>>>>>>> SynthPainter.paintToolBarContentBackground(...) without the >>>>>>>>> orientation and the GTKPainter .paintToolBarContentBackground >>>>>>>>> overrides the method without the orientation. So calls to >>>>>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) >>>>>>>>> falls down to the overriden method in GTKPainter. >>>>>>>>> >>>>>>>>> The same is for SynthPainter.paintProgressBarBackground(..., >>>>>>>>> orientation) and paintScrollBarBackground(..., orientation) >>>>>>>>> methods. >>>>>>>>> >>>>>>>>> The SynthPainter has only one paintToggleButtonBorder() method. >>>>>>>> Interesting rule... I thought that more specific method version >>>>>>>> may have different implementation. >>>>>>> It was done for historical reason. For example before the fix >>>>>>> JDK-5033822 "Synth ScrollBar paintTrack() dosn't support >>>>>>> orientation" >>>>>>> there was only paintScrollBarBackground() method without the >>>>>>> orientation in the SynthPainter class. >>>>>>> After the fix the paintScrollBarBackground() method with the >>>>>>> orientation is added which default implementation just calls the >>>>>>> same method without the orientation because old user's >>>>>>> subclasses can override the method without the orientation an >>>>>>> not be aware about new method version. >>>>>>> >>>>>>>> What would you say about paintSeparatorBackground() ? >>>>>>>> It's (..., orientation) version is over-ridden while the >>>>>>>> generic version is not over-ridden. >>>>>>> I guess that it is just a bug. >>>>>> Not sure. GTKPainter has never been providing a systematic API >>>>>> from the beginning. It is not for an arbitrary external use, >>>>>> because the resulting painting will be unpredictable. I explained >>>>>> this in this thread many times. And even if I would like to >>>>>> provide this useless method implementation >>>>> It is a part of the public SynthPainter API and can be called by >>>>> an external application. >>>> I can be called without any predictable result. This is the >>>> current state. It cannot be changed by the change you are proposing >>>> to add. >>> The result is described in the public method javadoc. >>>>>> I were not able to do this because the orientation is a required >>>>>> parameter to paint the GTK tab border. >>>>> The overridden method without the orientation can just call the >>>>> overridden method with orientation passing a default orientation >>>>> value. >>>> And what the default value is? It is not defined. >>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html >>> Creates a new horizontal separator: Constructor JSeparator(). >> Sorry, I didn't get how the separator orientation is related to >> tabbed pane border. > https://docs.oracle.com/javase/7/docs/api/javax/swing/JTabbedPane.html#setTabPlacement(int) > > The default value, if not set, is SwingConstants.TOP. It is a default for JTabbedPane but not for the LnF. JTabbedPane always has some orientation and it is used in the painter. But I cannot even imagine what should be painted if the GTK painter API is called to paint TabbedPane without orientation and why. Because orientation is mandatory in the corresponding gtk-lib call. --Semyon > > Thanks, > Alexandr. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> The paintTabbedPaneTabBorder() without orientation should >>>>>>>>>>>>> be implemented as well because it can be accessed by >>>>>>>>>>>>> public API. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>>> What reason? Why it is not public? since I provided >>>>>>>>>>>>>>>>> the code example >>>>>>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>>>>>> implement one of the method according to the spec and >>>>>>>>>>>>>>> skip the same method for some unknown reason. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I still did not get why an overload method should >>>>>>>>>>>>>>>>>> have the same behavior >>>>>>>>>>>>>>>>>> as its associates. This is a brand new design >>>>>>>>>>>>>>>>>> principle I've never heard >>>>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ........... >>>>>>>>>>>>>>>> That's nice... >>>>>>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I still do not understand why the first method with >>>>>>>>>>>>>>> default orientation is not implemented. >>>>>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>>>>>> because it is never used. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From rajeev.chamyal at oracle.com Wed Sep 14 09:01:53 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 14 Sep 2016 02:01:53 -0700 (PDT) Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> <72bc3219-8476-4412-a58c-4465ac6899c2@default> <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> Message-ID: <26da165f-0d84-4f33-8920-6ae1f7a24b32@default> Hello Alexandr, Thanks for the review. Please review the webrev updated as per review comments. http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 12 September 2016 20:07 To: Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon On 9/9/2016 3:06 PM, Rajeev Chamyal wrote: Hello Alexandr, Please review the updated webrev. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8150176/webrev.02/"http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ WTrayIconPeer.java + gr.drawImage(image, 0, 0, (autosize ? w : image.getWidth(observer)), + (autosize ? h : image.getHeight(observer)), observer); The w and h are scaled. It looks like the image.getWidth(observer) and image.getHeight(observer) also should be scaled in the same way. MultiResolutionTrayIconTest.java + latch.await(); It is better to add a timeout here. Thanks, Alexandr. Update: Updated webrev is fixing the issue in windows only. We have a separate bug linux and it will be fixed through a separate webrev. https://bugs.openjdk.java.net/browse/JDK-8154551 Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 14 June 2016 15:21 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: Hello Alexandr, Thanks for the review. I have updated the webrev as per review comments. HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8150176/webrev.01/"http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ I tried drawing the image directly to paint graphics without buffered image and it was getting cropped. Did you paint it using non scaled width and height? g.drawImage(image, 0, 0, curW, curH, null); Is the g transform already scaled? XTrayIconPeer: 606 if (scaleX > 1.0 && scaleY > 1.0) { 607 resolutionVariant = ((MultiResolutionImage) image). It is better to change the condition to "image instanceof MultiResolutionImage". It is necessary to not get CCE for non multi-resolution image and the multi-resolution image should return the best resolution variant for any scale. 618 gr.drawImage(resolutionVariant, 0, 0, 619 curW, curH, observer); The width and height should be scaled here to draw to whole buffered image. WTrayIconPeer: 133 BufferedImage bufImage = new BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, 134 BufferedImage.TYPE_INT_ARGB); The size for the buffered image should be scaled in the same was as for XTrayIconPeer. It may require to update the native code as well to set proper high-resolution icon. Thanks, Alexandr. Regards, Rajeev Chamyal From: Alexandr Scherbatiy Sent: 09 June 2016 20:43 To: Rajeev Chamyal; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net; Sergey Bylokhov Subject: Re: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: Hello All, Please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8150176/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ Issue: Wrong resolution variant image is used in Tray Icon. Fix : Applying the device transform to graphics object to select the correct image. The image could be cropped on Linux because the high resolution icon which size is bigger that the original image is drawn to the buffered image with un-scaled size curW x CurH. It is better to get a resolution variant from the multi-resolution image, draw it to a buffered image with the same scaled size and then draw the buffered image to the paint graphics using original size: ------- Image resolutionVariant = ((MultiResolutionImage) image).getResolutionVariant(scaleX * curW, scaleY * curH); BufferedImage bufImage = new BufferedImage(scaleX * curW, scaleY * curH, BufferedImage.TYPE_INT_ARGB); // ... gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, observer); // ... g.drawImage(bufImage, 0, 0, curW, curH, observer); // non scaled width and height ------- By the way, is the buffered image necessary in this case? Is it possible to draw the image directly to the paint graphics? ------- g.drawImage(image, 0, 0, curW, curH, null); ------- Thanks, Alexandr. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.ghaisas at oracle.com Wed Sep 14 10:14:54 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 14 Sep 2016 03:14:54 -0700 (PDT) Subject: [9] fix for JDK-8134612 :clipboard.getData(dataFlavor) can throw UnsupportedFlavorException for registered data flavor Message-ID: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-8134612 Issue : In this test, exportToClipboard() does not export anything to the clipboard due to incorrect text passed to TransferHandler. Obviously, when we do clipboard.getData() - it throws UnsupportedFlavorException. This is the root cause. Also, when text is imported, the text String cannot be assigned to MyStringReader class. Fix : The test is corrected to use custom dataflavor containing String to export and import from clipboard. Also, the test is enhanced to test a custom dataflavor of Color. I have referred to : https://docs.oracle.com/javase/tutorial/uiswing/dnd/dataflavor.html It passes consistently on Windows, Linux and Mac. Webrev : http://cr.openjdk.java.net/~aghaisas/8134612/webrev.00/ Request you to review. Regards, Ajit -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Wed Sep 14 10:48:15 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 14 Sep 2016 13:48:15 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. Message-ID: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8154043 webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ The new RadioButton group focus traversal algorithm introduced by JDK-8033699 doesn't take into account that group of radio buttons can be lay-outed in several lines in container. In this case the LayoutFocusTraversalPolicy may mix radio buttons of the same group with other components in its focus traversal order and break the assumption used in BasicRadioButtonUI#getFocusTransferBaseComponent() that radio buttons are sequenced in the focus policy order. The fix propose to treat a group of toggle buttons as a single focus cycle entry in the LayoutFocusTraversalPolicy which order is determined by the first toggle button in the group. --Semyon From alexandr.scherbatiy at oracle.com Wed Sep 14 14:39:58 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 14 Sep 2016 17:39:58 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> Message-ID: <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 - HiDPI icons are only drawn for scaled graphics. The screenshots [1], [2], and [3] show difference between icons drawing before and after the fix for scales 1x, 2x, and 4x. [1] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png [2] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png [3] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png Thanks, Alexandr. On 9/8/2016 10:59 AM, Andrej Golovnin wrote: > Hi Alexandr, > >> [1] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png > The icons do not look right to me. Take look at the top-left part of > the radio button. There is a white pixel between the shadow lines. And > in the selected state there should be a black circle. But instead it > is a square. The check sign of the checkbox is too thin. And the > arrows of the combobox and the vertical scroll bar should have a > single pixel at the top/bottom side. But now they have two pixels. > > It would be also nice to see a screen shot of the native Windows > components for comparison. > > Personally when I would make changes like that, then my code would > look like this: > > if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { > // use the old good code. > } else { > // use the new code > } > > Best regards, > Andrej Golovnin > >> [2] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >> [3] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >> >> Thanks, >> Alexandr. >> >> From m.kassens at teckpro.de Wed Sep 14 08:41:19 2016 From: m.kassens at teckpro.de (Manuel Kassens) Date: Wed, 14 Sep 2016 08:41:19 +0000 Subject: javax.swing.text.html.parser.NPrintWriter Message-ID: <8C07B6BA63B80C49B85670914EF338B802F953EE@exchange2k12.teckpro.local> Hi, i found an error in javax.swing.text.html.parser.NPrintWriter void javax.swing.text.html.parser.NPrintWriter.println(char[] array) public void println(char[] array) { if (this.numPrinted >= this.numLines) { return; } char[] partialArray = null; for (int i = 0; i < array.length; i++) { if (array[i] == '\n') { this.numPrinted++; } if (this.numPrinted == this.numLines) { /* ==> */ partialArray = new char[i]; /* missing code, without there will be a NPE */ System.arraycopy(array, 0, partialArray, 0, i); } } if (partialArray != null) { super.print(partialArray); } if (this.numPrinted == this.numLines) { return; } super.println(array); this.numPrinted++; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Sep 14 14:44:00 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 14 Sep 2016 17:44:00 +0300 Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: <26da165f-0d84-4f33-8920-6ae1f7a24b32@default> References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> <72bc3219-8476-4412-a58c-4465ac6899c2@default> <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> <26da165f-0d84-4f33-8920-6ae1f7a24b32@default> Message-ID: <9d8c0dc7-9594-0a3c-5b49-cf78b42b997e@oracle.com> The fix looks good to me. Thanks, Alexandr. On 9/14/2016 12:01 PM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. > > Please review the webrev updated as per review comments. > > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 12 September 2016 20:07 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov > *Subject:* Re: [9] Review request for JDK-8150176 [hidpi] > wrong resolution variant of multi-res. image is used for TrayIcon > > On 9/9/2016 3:06 PM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ > > > WTrayIconPeer.java > + gr.drawImage(image, 0, 0, (autosize ? w : > image.getWidth(observer)), > + (autosize ? h : > image.getHeight(observer)), observer); > > The w and h are scaled. It looks like the image.getWidth(observer) and > image.getHeight(observer) also should be scaled in the same way. > > MultiResolutionTrayIconTest.java > + latch.await(); > > It is better to add a timeout here. > > Thanks, > Alexandr. > > > Update: Updated webrev is fixing the issue in windows only. > > We have a separate bug linux and it will be fixed through a > separate webrev. > > https://bugs.openjdk.java.net/browse/JDK-8154551 > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 14 June 2016 15:21 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review request for JDK-8150176 > [hidpi] wrong resolution variant of multi-res. image is used for > TrayIcon > > On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: > > > Hello Alexandr, > > Thanks for the review. I have updated the webrev as per review > comments. > > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ > > > I tried drawing the image directly to paint graphics without > buffered image and it was getting cropped. > > > Did you paint it using non scaled width and height? > g.drawImage(image, 0, 0, curW, curH, null); > Is the g transform already scaled? > > XTrayIconPeer: > > 606 if (scaleX > 1.0 && scaleY > 1.0) { > > 607 resolutionVariant = > ((MultiResolutionImage) image). > > > It is better to change the condition to "image instanceof > MultiResolutionImage". It is necessary to not get CCE for non > multi-resolution image and the multi-resolution image should > return the best resolution variant for any scale. > > 618 gr.drawImage(resolutionVariant, 0, 0, > > 619 curW, curH, observer); > > The width and height should be scaled here to draw to whole > buffered image. > > WTrayIconPeer: > > 133 BufferedImage bufImage = new > BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, > 134 BufferedImage.TYPE_INT_ARGB); > > The size for the buffered image should be scaled in the same was > as for XTrayIconPeer. > It may require to update the native code as well to set proper > high-resolution icon. > > Thanks, > Alexandr. > > > > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 09 June 2016 20:43 > *To:* Rajeev Chamyal; swing-dev at openjdk.java.net > ; Sergey Bylokhov > *Subject:* Re: [9] Review request for JDK-8150176 > [hidpi] wrong resolution variant of multi-res. image is used > for TrayIcon > > On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: > > > > Hello All, > > Please review the following fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 > > Webrev: > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ > > > Issue: Wrong resolution variant image is used in Tray Icon. > > Fix : Applying the device transform to graphics object to > select the correct image. > > The image could be cropped on Linux because the high > resolution icon which size is bigger that the original image > is drawn to the buffered image with un-scaled size curW x CurH. > It is better to get a resolution variant from the > multi-resolution image, draw it to a buffered image with the > same scaled size and then draw the buffered image to the paint > graphics using original size: > ------- > Image resolutionVariant = ((MultiResolutionImage) > image).getResolutionVariant(scaleX * curW, scaleY * curH); > BufferedImage bufImage = new BufferedImage(scaleX * curW, > scaleY * curH, BufferedImage.TYPE_INT_ARGB); > // ... > gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, > observer); > // ... > g.drawImage(bufImage, 0, 0, curW, curH, observer); // non > scaled width and height > ------- > > By the way, is the buffered image necessary in this case? Is > it possible to draw the image directly to the paint graphics? > ------- > g.drawImage(image, 0, 0, curW, curH, null); > ------- > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Sep 14 15:41:19 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 14 Sep 2016 18:41:19 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: References: Message-ID: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8154043 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ > > The new RadioButton group focus traversal algorithm introduced by > JDK-8033699 doesn't take into account that group of radio buttons can > be lay-outed in several lines in container. In this case the > LayoutFocusTraversalPolicy may mix radio buttons of the same group > with other components in its focus traversal order and break the > assumption used in BasicRadioButtonUI#getFocusTransferBaseComponent() > that radio buttons are sequenced in the focus policy order. > > The fix propose to treat a group of toggle buttons as a single focus > cycle entry in the LayoutFocusTraversalPolicy which order is > determined by the first toggle button in the group. Should the test for the fix JDK-8033699 test/javax/swing/JRadioButton/8033699/bug8033699.java be updated as well? Thanks, Alexandr. > > --Semyon > > From alexandr.scherbatiy at oracle.com Wed Sep 14 16:29:16 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 14 Sep 2016 19:29:16 +0300 Subject: javax.swing.text.html.parser.NPrintWriter In-Reply-To: <8C07B6BA63B80C49B85670914EF338B802F953EE@exchange2k12.teckpro.local> References: <8C07B6BA63B80C49B85670914EF338B802F953EE@exchange2k12.teckpro.local> Message-ID: <6e35e121-1e1e-719e-5444-f2d0c48b97f5@oracle.com> Hello Manuel, Thank you for the feedback. I have filled an issue on it [1]: JDK-8166050 partialArray is not created in javax.swing.text.html.parser.NPrintWriter.println(...) method Do you have any particular test which runs into this issue? [1] https://bugs.openjdk.java.net/browse/JDK-8166050 Thanks, Alexandr. On 9/14/2016 11:41 AM, Manuel Kassens wrote: > > Hi, > > i found an error in javax > .swing > .text > .html > .parser > .NPrintWriter > > void javax .swing > .text > .html > .parser > .NPrintWriter > .println(char[] > array) > > *public**void*println(*char*[] array) { > > *if*(*this*.numPrinted>= *this*.numLines) { > > *return*; > > } > > *char*[] partialArray= *null*; > > *for*(*int*i= 0; i< array.length; i++) { > > *if*(array[i] == '\n') { > > *this*.numPrinted++; > > } > > *if*(*this*.numPrinted== *this*.numLines) { > > /* ?*/ partialArray= *new**char*[i]; */* missing code, without there > will be a NPE */* > > System./arraycopy/(array, 0, partialArray, 0, i); > > } > > } > > *if*(partialArray!= *null*) { > > *super*.print(partialArray); > > } > > *if*(*this*.numPrinted== *this*.numLines) { > > *return*; > > } > > *super*.println(array); > > *this*.numPrinted++; > > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Sep 14 16:35:36 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Sep 2016 19:35:36 +0300 Subject: javax.swing.text.html.parser.NPrintWriter In-Reply-To: <6e35e121-1e1e-719e-5444-f2d0c48b97f5@oracle.com> References: <8C07B6BA63B80C49B85670914EF338B802F953EE@exchange2k12.teckpro.local> <6e35e121-1e1e-719e-5444-f2d0c48b97f5@oracle.com> Message-ID: <43a35aa7-d7a8-556e-a360-475eac28adb5@oracle.com> I think that NPrintWriter is not public and is not used in jdk. On 14.09.16 19:29, Alexandr Scherbatiy wrote: > > Hello Manuel, > > Thank you for the feedback. I have filled an issue on it [1]: > JDK-8166050 partialArray is not created in > javax.swing.text.html.parser.NPrintWriter.println(...) method > > Do you have any particular test which runs into this issue? > > [1] https://bugs.openjdk.java.net/browse/JDK-8166050 > > Thanks, > Alexandr. > > On 9/14/2016 11:41 AM, Manuel Kassens wrote: >> >> Hi, >> >> i found an error in javax >> .swing >> .text >> .html >> .parser >> .NPrintWriter >> >> >> >> void javax .swing >> .text >> .html >> .parser >> .NPrintWriter >> .println(char[] >> array) >> >> >> >> *public**void*println(*char*[] array) { >> >> *if*(*this*.numPrinted>= *this*.numLines) { >> >> *return*; >> >> } >> >> *char*[] partialArray= *null*; >> >> *for*(*int*i= 0; i< array.length; i++) { >> >> *if*(array[i] == '\n') { >> >> *this*.numPrinted++; >> >> } >> >> *if*(*this*.numPrinted== *this*.numLines) { >> >> /* ?*/ partialArray= *new**char*[i]; */* missing code, >> without there will be a NPE */* >> >> System./arraycopy/(array, 0, partialArray, 0, i); >> >> } >> >> } >> >> *if*(partialArray!= *null*) { >> >> *super*.print(partialArray); >> >> } >> >> *if*(*this*.numPrinted== *this*.numLines) { >> >> *return*; >> >> } >> >> *super*.println(array); >> >> *this*.numPrinted++; >> >> } >> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Wed Sep 14 17:02:54 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 14 Sep 2016 20:02:54 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> Message-ID: <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> Hi Alexander, When I press the arrow button (for example in the "111" combo) several times I can see artifacts. They are well seen in scale x4. --Semyon On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 > > - HiDPI icons are only drawn for scaled graphics. > > The screenshots [1], [2], and [3] show difference between icons > drawing before and after the fix for scales 1x, 2x, and 4x. > > [1] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png > [2] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png > [3] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png > > Thanks, > Alexandr. > > On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >> Hi Alexandr, >> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>> >> The icons do not look right to me. Take look at the top-left part of >> the radio button. There is a white pixel between the shadow lines. And >> in the selected state there should be a black circle. But instead it >> is a square. The check sign of the checkbox is too thin. And the >> arrows of the combobox and the vertical scroll bar should have a >> single pixel at the top/bottom side. But now they have two pixels. >> >> It would be also nice to see a screen shot of the native Windows >> components for comparison. >> >> Personally when I would make changes like that, then my code would >> look like this: >> >> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >> // use the old good code. >> } else { >> // use the new code >> } >> >> Best regards, >> Andrej Golovnin >> >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>> >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>> >>> >>> Thanks, >>> Alexandr. >>> >>> > From alexandr.scherbatiy at oracle.com Wed Sep 14 17:52:07 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 14 Sep 2016 20:52:07 +0300 Subject: javax.swing.text.html.parser.NPrintWriter In-Reply-To: <43a35aa7-d7a8-556e-a360-475eac28adb5@oracle.com> References: <8C07B6BA63B80C49B85670914EF338B802F953EE@exchange2k12.teckpro.local> <6e35e121-1e1e-719e-5444-f2d0c48b97f5@oracle.com> <43a35aa7-d7a8-556e-a360-475eac28adb5@oracle.com> Message-ID: <92119662-fa76-e3be-0e10-6541b7e202aa@oracle.com> On 9/14/2016 7:35 PM, Sergey Bylokhov wrote: > I think that NPrintWriter is not public and is not used in jdk. May be it it has sense just to remove it? Thanks, Alexandr. > > On 14.09.16 19:29, Alexandr Scherbatiy wrote: >> >> Hello Manuel, >> >> Thank you for the feedback. I have filled an issue on it [1]: >> JDK-8166050 partialArray is not created in >> javax.swing.text.html.parser.NPrintWriter.println(...) method >> >> Do you have any particular test which runs into this issue? >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8166050 >> >> Thanks, >> Alexandr. >> >> On 9/14/2016 11:41 AM, Manuel Kassens wrote: >>> >>> Hi, >>> >>> i found an error in javax >>> .swing >>> .text >>> .html >>> .parser >>> .NPrintWriter >>> >>> >>> >>> >>> void javax .swing >>> .text >>> .html >>> .parser >>> .NPrintWriter >>> >>> .println(char[] >>> >>> array) >>> >>> >>> >>> *public**void*println(*char*[] array) { >>> >>> *if*(*this*.numPrinted>= *this*.numLines) { >>> >>> *return*; >>> >>> } >>> >>> *char*[] partialArray= *null*; >>> >>> *for*(*int*i= 0; i< array.length; i++) { >>> >>> *if*(array[i] == '\n') { >>> >>> *this*.numPrinted++; >>> >>> } >>> >>> *if*(*this*.numPrinted== *this*.numLines) { >>> >>> /* ?*/ partialArray= *new**char*[i]; */* missing code, >>> without there will be a NPE */* >>> >>> System./arraycopy/(array, 0, partialArray, 0, i); >>> >>> } >>> >>> } >>> >>> *if*(partialArray!= *null*) { >>> >>> *super*.print(partialArray); >>> >>> } >>> >>> *if*(*this*.numPrinted== *this*.numLines) { >>> >>> *return*; >>> >>> } >>> >>> *super*.println(array); >>> >>> *this*.numPrinted++; >>> >>> } >>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Wed Sep 14 18:00:12 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 14 Sep 2016 21:00:12 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> References: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> Message-ID: On 9/14/2016 6:41 PM, Alexandr Scherbatiy wrote: > On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8154043 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ >> >> The new RadioButton group focus traversal algorithm introduced by >> JDK-8033699 doesn't take into account that group of radio buttons can >> be lay-outed in several lines in container. In this case the >> LayoutFocusTraversalPolicy may mix radio buttons of the same group >> with other components in its focus traversal order and break the >> assumption used in BasicRadioButtonUI#getFocusTransferBaseComponent() >> that radio buttons are sequenced in the focus policy order. >> >> The fix propose to treat a group of toggle buttons as a single focus >> cycle entry in the LayoutFocusTraversalPolicy which order is >> determined by the first toggle button in the group. > Should the test for the fix JDK-8033699 > test/javax/swing/JRadioButton/8033699/bug8033699.java be updated as well? Is it possible to move the focus from the current radio button to the next component which does not belong to the current radio buttons group by pressing tab key? For example in the test FocusCycleRootTest from the issue description, moving the focus from the first and the second radio button to the text field 1 and from the third and the fourth radio button to the text field 2. Thanks, Alexandr. > > Thanks, > Alexandr. >> >> --Semyon >> >> > From Sergey.Bylokhov at oracle.com Wed Sep 14 18:09:21 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Sep 2016 21:09:21 +0300 Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: <9d8c0dc7-9594-0a3c-5b49-cf78b42b997e@oracle.com> References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> <72bc3219-8476-4412-a58c-4465ac6899c2@default> <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> <26da165f-0d84-4f33-8920-6ae1f7a24b32@default> <9d8c0dc7-9594-0a3c-5b49-cf78b42b997e@oracle.com> Message-ID: <7aca2def-71e6-6ca1-a587-696111af9eb5@oracle.com> Is "MultiResolutionTrayIconTest.html" should be removed? On 14.09.16 17:44, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/14/2016 12:01 PM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> >> >> Thanks for the review. >> >> Please review the webrev updated as per review comments. >> >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* 12 September 2016 20:07 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov >> *Subject:* Re: [9] Review request for JDK-8150176 [hidpi] >> wrong resolution variant of multi-res. image is used for TrayIcon >> >> >> >> On 9/9/2016 3:06 PM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ >> >> >> WTrayIconPeer.java >> + gr.drawImage(image, 0, 0, (autosize ? w : >> image.getWidth(observer)), >> + (autosize ? h : >> image.getHeight(observer)), observer); >> >> The w and h are scaled. It looks like the image.getWidth(observer) and >> image.getHeight(observer) also should be scaled in the same way. >> >> MultiResolutionTrayIconTest.java >> + latch.await(); >> >> It is better to add a timeout here. >> >> Thanks, >> Alexandr. >> >> >> >> >> >> >> Update: Updated webrev is fixing the issue in windows only. >> >> We have a separate bug linux and it will be fixed through a >> separate webrev. >> >> https://bugs.openjdk.java.net/browse/JDK-8154551 >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* 14 June 2016 15:21 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >> ; Sergey Bylokhov >> *Subject:* Re: [9] Review request for JDK-8150176 >> [hidpi] wrong resolution variant of multi-res. image is used for >> TrayIcon >> >> >> >> On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: >> >> >> Hello Alexandr, >> >> >> >> Thanks for the review. I have updated the webrev as per review >> comments. >> >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ >> >> >> I tried drawing the image directly to paint graphics without >> buffered image and it was getting cropped. >> >> >> Did you paint it using non scaled width and height? >> g.drawImage(image, 0, 0, curW, curH, null); >> Is the g transform already scaled? >> >> XTrayIconPeer: >> >> 606 if (scaleX > 1.0 && scaleY > 1.0) { >> >> 607 resolutionVariant = >> ((MultiResolutionImage) image). >> >> >> It is better to change the condition to "image instanceof >> MultiResolutionImage". It is necessary to not get CCE for non >> multi-resolution image and the multi-resolution image should >> return the best resolution variant for any scale. >> >> 618 gr.drawImage(resolutionVariant, 0, 0, >> >> 619 curW, curH, observer); >> >> The width and height should be scaled here to draw to whole >> buffered image. >> >> WTrayIconPeer: >> >> 133 BufferedImage bufImage = new >> BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, >> 134 >> BufferedImage.TYPE_INT_ARGB); >> >> The size for the buffered image should be scaled in the same was >> as for XTrayIconPeer. >> It may require to update the native code as well to set proper >> high-resolution icon. >> >> Thanks, >> Alexandr. >> >> >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* 09 June 2016 20:43 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >> ; Sergey Bylokhov >> *Subject:* Re: [9] Review request for JDK-8150176 >> [hidpi] wrong resolution variant of multi-res. image is used >> for TrayIcon >> >> >> >> On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: >> >> >> >> Hello All, >> >> >> >> Please review the following fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 >> >> Webrev: >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ >> >> >> >> >> Issue: Wrong resolution variant image is used in Tray Icon. >> >> Fix : Applying the device transform to graphics object to >> select the correct image. >> >> The image could be cropped on Linux because the high >> resolution icon which size is bigger that the original image >> is drawn to the buffered image with un-scaled size curW x CurH. >> It is better to get a resolution variant from the >> multi-resolution image, draw it to a buffered image with the >> same scaled size and then draw the buffered image to the paint >> graphics using original size: >> ------- >> Image resolutionVariant = ((MultiResolutionImage) >> image).getResolutionVariant(scaleX * curW, scaleY * curH); >> BufferedImage bufImage = new BufferedImage(scaleX * curW, >> scaleY * curH, BufferedImage.TYPE_INT_ARGB); >> // ... >> gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, >> observer); >> // ... >> g.drawImage(bufImage, 0, 0, curW, curH, observer); // non >> scaled width and height >> ------- >> >> By the way, is the buffered image necessary in this case? Is >> it possible to draw the image directly to the paint graphics? >> ------- >> g.drawImage(image, 0, 0, curW, curH, null); >> ------- >> >> Thanks, >> Alexandr. >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> >> >> >> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Sep 14 19:03:17 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Sep 2016 22:03:17 +0300 Subject: [9] Review request for 8165234 Provide a way to not close toggle menu items on mouse click on component level In-Reply-To: References: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> <57C9CC28.2040309@oracle.com> Message-ID: <30851302-18c4-b9f2-95bc-09bc0a433e11@oracle.com> Hi, Alexandr. I think we should double check how we operate on this property in case of custom L&F. Our code relies that this property is set to "true" by default. And if the custom look&feel, which knows nothing about it will be in use, then the code in SwingUtilities2 returns false. Is it expected? On 05.09.16 13:51, Alexandr Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165234/webrev.01 > > On 9/2/2016 9:59 PM, Phil Race wrote: >> Seems fine except for a grammatical issue in the javadoc >> >> {@code true}. Setting the property to {@code false} either to >> {@literal L&F} >> >> I think you mean ".. either on the ..." > The typo "either to" is updated to "either on the". > > Thanks, > Alexandr. > >> >> -phil. >> >> On 09/02/2016 05:30 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8165234 >>> webrev: http://cr.openjdk.java.net/~alexsch/8165234/webrev.00 >>> >>> The fix JDK-8158566 adds "CheckBoxMenuItem.closeOnMouseClick" and >>> "RadioButtonMenuItem.closeOnMouseClick" properties >>> that control toogle menu items closing on mouse click on L&F level. >>> >>> The current fix allows to control menu items closing on a component >>> level. A toogle menu item >>> is not closed on mouse click if the corresponding property is set >>> to false either on the L&F or component level. >>> >>> Thanks, >>> Alexandr. >>> >> > -- Best regards, Sergey. From rajeev.chamyal at oracle.com Thu Sep 15 06:24:52 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 14 Sep 2016 23:24:52 -0700 (PDT) Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: <7aca2def-71e6-6ca1-a587-696111af9eb5@oracle.com> References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> <72bc3219-8476-4412-a58c-4465ac6899c2@default> <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> <26da165f-0d84-4f33-8920-6ae1f7a24b32@default> <9d8c0dc7-9594-0a3c-5b49-cf78b42b997e@oracle.com> <7aca2def-71e6-6ca1-a587-696111af9eb5@oracle.com> Message-ID: Hello Sergey, I have removed the html file. http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ Regards, Rajeev Chamyal -----Original Message----- From: Sergey Bylokhov Sent: 14 September 2016 23:39 To: Alexandr Scherbatiy; Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon Is "MultiResolutionTrayIconTest.html" should be removed? On 14.09.16 17:44, Alexandr Scherbatiy wrote: > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/14/2016 12:01 PM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> >> >> Thanks for the review. >> >> Please review the webrev updated as per review comments. >> >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* 12 September 2016 20:07 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov >> *Subject:* Re: [9] Review request for JDK-8150176 [hidpi] >> wrong resolution variant of multi-res. image is used for TrayIcon >> >> >> >> On 9/9/2016 3:06 PM, Rajeev Chamyal wrote: >> >> Hello Alexandr, >> >> >> >> Please review the updated webrev. >> >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ >> >> >> WTrayIconPeer.java >> + gr.drawImage(image, 0, 0, (autosize ? w : >> image.getWidth(observer)), >> + (autosize ? h : >> image.getHeight(observer)), observer); >> >> The w and h are scaled. It looks like the image.getWidth(observer) >> and >> image.getHeight(observer) also should be scaled in the same way. >> >> MultiResolutionTrayIconTest.java >> + latch.await(); >> >> It is better to add a timeout here. >> >> Thanks, >> Alexandr. >> >> >> >> >> >> >> Update: Updated webrev is fixing the issue in windows only. >> >> We have a separate bug linux and it will be fixed through a >> separate webrev. >> >> https://bugs.openjdk.java.net/browse/JDK-8154551 >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* 14 June 2016 15:21 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >> ; Sergey Bylokhov >> *Subject:* Re: [9] Review request for JDK-8150176 >> [hidpi] wrong resolution variant of multi-res. image is used for >> TrayIcon >> >> >> >> On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: >> >> >> Hello Alexandr, >> >> >> >> Thanks for the review. I have updated the webrev as per review >> comments. >> >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ >> >> >> I tried drawing the image directly to paint graphics without >> buffered image and it was getting cropped. >> >> >> Did you paint it using non scaled width and height? >> g.drawImage(image, 0, 0, curW, curH, null); >> Is the g transform already scaled? >> >> XTrayIconPeer: >> >> 606 if (scaleX > 1.0 && scaleY > 1.0) { >> >> 607 resolutionVariant = >> ((MultiResolutionImage) image). >> >> >> It is better to change the condition to "image instanceof >> MultiResolutionImage". It is necessary to not get CCE for non >> multi-resolution image and the multi-resolution image should >> return the best resolution variant for any scale. >> >> 618 gr.drawImage(resolutionVariant, 0, 0, >> >> 619 curW, curH, observer); >> >> The width and height should be scaled here to draw to whole >> buffered image. >> >> WTrayIconPeer: >> >> 133 BufferedImage bufImage = new >> BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, >> 134 >> BufferedImage.TYPE_INT_ARGB); >> >> The size for the buffered image should be scaled in the same was >> as for XTrayIconPeer. >> It may require to update the native code as well to set proper >> high-resolution icon. >> >> Thanks, >> Alexandr. >> >> >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* 09 June 2016 20:43 >> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >> ; Sergey Bylokhov >> *Subject:* Re: [9] Review request for JDK-8150176 >> [hidpi] wrong resolution variant of multi-res. image is used >> for TrayIcon >> >> >> >> On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: >> >> >> >> Hello All, >> >> >> >> Please review the following fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 >> >> Webrev: >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ >> >> >> >> >> >> Issue: Wrong resolution variant image is used in Tray Icon. >> >> Fix : Applying the device transform to graphics object to >> select the correct image. >> >> The image could be cropped on Linux because the high >> resolution icon which size is bigger that the original image >> is drawn to the buffered image with un-scaled size curW x CurH. >> It is better to get a resolution variant from the >> multi-resolution image, draw it to a buffered image with the >> same scaled size and then draw the buffered image to the paint >> graphics using original size: >> ------- >> Image resolutionVariant = ((MultiResolutionImage) >> image).getResolutionVariant(scaleX * curW, scaleY * curH); >> BufferedImage bufImage = new BufferedImage(scaleX * curW, >> scaleY * curH, BufferedImage.TYPE_INT_ARGB); >> // ... >> gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, >> observer); >> // ... >> g.drawImage(bufImage, 0, 0, curW, curH, observer); // non >> scaled width and height >> ------- >> >> By the way, is the buffered image necessary in this case? Is >> it possible to draw the image directly to the paint graphics? >> ------- >> g.drawImage(image, 0, 0, curW, curH, null); >> ------- >> >> Thanks, >> Alexandr. >> >> >> >> >> Regards, >> >> Rajeev Chamyal >> >> >> >> >> >> >> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu Sep 15 08:47:52 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 15 Sep 2016 11:47:52 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: References: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> Message-ID: On 14.09.2016 21:00, Alexandr Scherbatiy wrote: > On 9/14/2016 6:41 PM, Alexandr Scherbatiy wrote: >> On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8154043 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ >>> >>> The new RadioButton group focus traversal algorithm introduced by >>> JDK-8033699 doesn't take into account that group of radio buttons >>> can be lay-outed in several lines in container. In this case the >>> LayoutFocusTraversalPolicy may mix radio buttons of the same group >>> with other components in its focus traversal order and break the >>> assumption used in >>> BasicRadioButtonUI#getFocusTransferBaseComponent() that radio >>> buttons are sequenced in the focus policy order. >>> >>> The fix propose to treat a group of toggle buttons as a single focus >>> cycle entry in the LayoutFocusTraversalPolicy which order is >>> determined by the first toggle button in the group. >> Should the test for the fix JDK-8033699 >> test/javax/swing/JRadioButton/8033699/bug8033699.java be updated as >> well? > Is it possible to move the focus from the current radio button to > the next component which does not belong to the current radio buttons > group by pressing tab key? > For example in the test FocusCycleRootTest from the issue > description, moving the focus from the first and the second radio > button to the text field 1 and from the third and the fourth radio > button to the text field 2. It is possible. But then the group will get focus second (or more) time during the cycle. Seems, this is not correct because option in the group has already been selected. Also it looks inconsistent when the second option is skipped in the cycle while the third is not. --Semyon > > Thanks, > Alexandr. >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>> >>> >> > From alexandr.scherbatiy at oracle.com Thu Sep 15 09:31:15 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 15 Sep 2016 12:31:15 +0300 Subject: [9] Review request for 8165234 Provide a way to not close toggle menu items on mouse click on component level In-Reply-To: <30851302-18c4-b9f2-95bc-09bc0a433e11@oracle.com> References: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> <57C9CC28.2040309@oracle.com> <30851302-18c4-b9f2-95bc-09bc0a433e11@oracle.com> Message-ID: <0abb68ee-e9c4-f005-eb63-ff035cd2ad3c@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8165234/webrev.02 The closeOnMouseClick property is renamed to doNotCloseOnMouseClick with the default false value. The client property is queried in the first place. If it is not set the L&F property value is used instead. Thanks, Alexandr. On 9/14/2016 10:03 PM, Sergey Bylokhov wrote: > Hi, Alexandr. > I think we should double check how we operate on this property in case > of custom L&F. Our code relies that this property is set to "true" by > default. And if the custom look&feel, which knows nothing about it > will be in use, then the code in SwingUtilities2 returns false. Is it > expected? > > On 05.09.16 13:51, Alexandr Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8165234/webrev.01 >> >> On 9/2/2016 9:59 PM, Phil Race wrote: >>> Seems fine except for a grammatical issue in the javadoc >>> >>> {@code true}. Setting the property to {@code false} either to >>> {@literal L&F} >>> >>> I think you mean ".. either on the ..." >> The typo "either to" is updated to "either on the". >> >> Thanks, >> Alexandr. >> >>> >>> -phil. >>> >>> On 09/02/2016 05:30 AM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165234 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8165234/webrev.00 >>>> >>>> The fix JDK-8158566 adds "CheckBoxMenuItem.closeOnMouseClick" and >>>> "RadioButtonMenuItem.closeOnMouseClick" properties >>>> that control toogle menu items closing on mouse click on L&F level. >>>> >>>> The current fix allows to control menu items closing on a component >>>> level. A toogle menu item >>>> is not closed on mouse click if the corresponding property is set >>>> to false either on the L&F or component level. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> > > From alexandr.scherbatiy at oracle.com Thu Sep 15 09:49:31 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 15 Sep 2016 12:49:31 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: References: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> Message-ID: <3d41ceaa-54ca-6867-b735-80395701fa78@oracle.com> On 9/15/2016 11:47 AM, Semyon Sadetsky wrote: > On 14.09.2016 21:00, Alexandr Scherbatiy wrote: >> On 9/14/2016 6:41 PM, Alexandr Scherbatiy wrote: >>> On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154043 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ >>>> >>>> The new RadioButton group focus traversal algorithm introduced by >>>> JDK-8033699 doesn't take into account that group of radio buttons >>>> can be lay-outed in several lines in container. In this case the >>>> LayoutFocusTraversalPolicy may mix radio buttons of the same group >>>> with other components in its focus traversal order and break the >>>> assumption used in >>>> BasicRadioButtonUI#getFocusTransferBaseComponent() that radio >>>> buttons are sequenced in the focus policy order. >>>> >>>> The fix propose to treat a group of toggle buttons as a single >>>> focus cycle entry in the LayoutFocusTraversalPolicy which order is >>>> determined by the first toggle button in the group. >>> Should the test for the fix JDK-8033699 >>> test/javax/swing/JRadioButton/8033699/bug8033699.java be updated as >>> well? >> Is it possible to move the focus from the current radio button to >> the next component which does not belong to the current radio buttons >> group by pressing tab key? >> For example in the test FocusCycleRootTest from the issue >> description, moving the focus from the first and the second radio >> button to the text field 1 and from the third and the fourth radio >> button to the text field 2. > It is possible. But then the group will get focus second (or more) > time during the cycle. Seems, this is not correct because option in > the group has already been selected. It is not clear is it correct that pressing an arrow key selects a radio button in a group. For example each radio button selection can trigger some action. So trying to select the latest radio button it is necessary to move the focus from the first button to the last by arrow keys so radio buttons in the middle will also be unnecessary selected. Usually the space key is responsible to a button selection. > Also it looks inconsistent when the second option is skipped in the > cycle while the third is not. This is because the tab key is pressed which can move the focus from the group and back. The arrow keys are used to move the focus in the group. It preserves the tab key behavior before the fix 8033699 except radio buttons in the group. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Thu Sep 15 10:01:24 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 15 Sep 2016 13:01:24 +0300 Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> <72bc3219-8476-4412-a58c-4465ac6899c2@default> <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> <26da165f-0d84-4f33-8920-6ae1f7a24b32@default> <9d8c0dc7-9594-0a3c-5b49-cf78b42b997e@oracle.com> <7aca2def-71e6-6ca1-a587-696111af9eb5@oracle.com> Message-ID: +1 On 15.09.16 9:24, Rajeev Chamyal wrote: > Hello Sergey, > > I have removed the html file. > http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Sergey Bylokhov > Sent: 14 September 2016 23:39 > To: Alexandr Scherbatiy; Rajeev Chamyal; swing-dev at openjdk.java.net > Subject: Re: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon > > Is "MultiResolutionTrayIconTest.html" should be removed? > > On 14.09.16 17:44, Alexandr Scherbatiy wrote: >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 9/14/2016 12:01 PM, Rajeev Chamyal wrote: >>> >>> Hello Alexandr, >>> >>> >>> >>> Thanks for the review. >>> >>> Please review the webrev updated as per review comments. >>> >>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ >>> >>> >>> >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> >>> >>> *From:*Alexandr Scherbatiy >>> *Sent:* 12 September 2016 20:07 >>> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov >>> *Subject:* Re: [9] Review request for JDK-8150176 [hidpi] >>> wrong resolution variant of multi-res. image is used for TrayIcon >>> >>> >>> >>> On 9/9/2016 3:06 PM, Rajeev Chamyal wrote: >>> >>> Hello Alexandr, >>> >>> >>> >>> Please review the updated webrev. >>> >>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ >>> >>> >>> WTrayIconPeer.java >>> + gr.drawImage(image, 0, 0, (autosize ? w : >>> image.getWidth(observer)), >>> + (autosize ? h : >>> image.getHeight(observer)), observer); >>> >>> The w and h are scaled. It looks like the image.getWidth(observer) >>> and >>> image.getHeight(observer) also should be scaled in the same way. >>> >>> MultiResolutionTrayIconTest.java >>> + latch.await(); >>> >>> It is better to add a timeout here. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >>> >>> >>> Update: Updated webrev is fixing the issue in windows only. >>> >>> We have a separate bug linux and it will be fixed through a >>> separate webrev. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8154551 >>> >>> >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> >>> >>> *From:*Alexandr Scherbatiy >>> *Sent:* 14 June 2016 15:21 >>> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >>> ; Sergey Bylokhov >>> *Subject:* Re: [9] Review request for JDK-8150176 >>> [hidpi] wrong resolution variant of multi-res. image is used for >>> TrayIcon >>> >>> >>> >>> On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: >>> >>> >>> Hello Alexandr, >>> >>> >>> >>> Thanks for the review. I have updated the webrev as per review >>> comments. >>> >>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ >>> >>> >>> I tried drawing the image directly to paint graphics without >>> buffered image and it was getting cropped. >>> >>> >>> Did you paint it using non scaled width and height? >>> g.drawImage(image, 0, 0, curW, curH, null); >>> Is the g transform already scaled? >>> >>> XTrayIconPeer: >>> >>> 606 if (scaleX > 1.0 && scaleY > 1.0) { >>> >>> 607 resolutionVariant = >>> ((MultiResolutionImage) image). >>> >>> >>> It is better to change the condition to "image instanceof >>> MultiResolutionImage". It is necessary to not get CCE for non >>> multi-resolution image and the multi-resolution image should >>> return the best resolution variant for any scale. >>> >>> 618 gr.drawImage(resolutionVariant, 0, 0, >>> >>> 619 curW, curH, observer); >>> >>> The width and height should be scaled here to draw to whole >>> buffered image. >>> >>> WTrayIconPeer: >>> >>> 133 BufferedImage bufImage = new >>> BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, >>> 134 >>> BufferedImage.TYPE_INT_ARGB); >>> >>> The size for the buffered image should be scaled in the same was >>> as for XTrayIconPeer. >>> It may require to update the native code as well to set proper >>> high-resolution icon. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >>> >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> >>> >>> *From:*Alexandr Scherbatiy >>> *Sent:* 09 June 2016 20:43 >>> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >>> ; Sergey Bylokhov >>> *Subject:* Re: [9] Review request for JDK-8150176 >>> [hidpi] wrong resolution variant of multi-res. image is used >>> for TrayIcon >>> >>> >>> >>> On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: >>> >>> >>> >>> Hello All, >>> >>> >>> >>> Please review the following fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ >>> >>> >>> >>> >>> >>> Issue: Wrong resolution variant image is used in Tray Icon. >>> >>> Fix : Applying the device transform to graphics object to >>> select the correct image. >>> >>> The image could be cropped on Linux because the high >>> resolution icon which size is bigger that the original image >>> is drawn to the buffered image with un-scaled size curW x CurH. >>> It is better to get a resolution variant from the >>> multi-resolution image, draw it to a buffered image with the >>> same scaled size and then draw the buffered image to the paint >>> graphics using original size: >>> ------- >>> Image resolutionVariant = ((MultiResolutionImage) >>> image).getResolutionVariant(scaleX * curW, scaleY * curH); >>> BufferedImage bufImage = new BufferedImage(scaleX * curW, >>> scaleY * curH, BufferedImage.TYPE_INT_ARGB); >>> // ... >>> gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, >>> observer); >>> // ... >>> g.drawImage(bufImage, 0, 0, curW, curH, observer); // non >>> scaled width and height >>> ------- >>> >>> By the way, is the buffered image necessary in this case? Is >>> it possible to draw the image directly to the paint graphics? >>> ------- >>> g.drawImage(image, 0, 0, curW, curH, null); >>> ------- >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>> >>> Regards, >>> >>> Rajeev Chamyal >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Sep 15 10:04:50 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 15 Sep 2016 13:04:50 +0300 Subject: Review Request for 8163261: regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java In-Reply-To: References: <680be17d-32e9-4765-99dd-f4ae65d48c9a@default> <6de9c6cb-814a-485d-b36e-c7e3bdbac075@default> <284feaa1-14af-4111-bb17-e652ccb72e05@default> <2966a7ef-cf7c-7426-4fd9-68b976cb0696@oracle.com> <43517154-6fc9-40fe-b1c4-218298f30556@default> <4772766f-74ba-48be-a739-d8b5280c1b87@default> Message-ID: <8cbc4145-4cab-5020-f65c-e22ee9eecb5e@oracle.com> +1 On 06.09.16 18:33, Alexandr Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/6/2016 6:21 PM, Ambarish Rapte wrote: >> >> Hi Alex, >> >> 1. There will be only one key value pair entry in the /cacheMap/. >> >> The CachedPainter.paint0() method uses getClass() as a key for the >> cacheMap. At least there should be more than 1 key (getClass() + >> PainterMultiResolutionCachedImage.class). >> >> Sorry for the confusion here, I meant, there will be only one key >> value pair entry in cacheMap for all PainterMultiResolutionCachedImage >> images. >> >> As you mentioned there will be entries for other classes as well. >> >> >> >> Could the image cache size be increased only for the >> PainterMultiResolutionCachedImage.class key in the approach 2 because >> other keys may require only one image? >> Please review the updated webrev modified as you guided, >> >> http://cr.openjdk.java.net/~arapte/8163261/webrev.04/ >> >> >> >> >> >> >> Regards, >> >> Ambarish >> >> >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* Monday, September 05, 2016 3:40 PM >> *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; >> swing-dev at openjdk.java.net >> *Subject:* Re: Review Request for 8163261: regression on >> Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java >> >> >> >> On 9/2/2016 7:18 AM, Ambarish Rapte wrote: >> >> Hi Alex, >> >> >> >> Thanks for the review comments, >> >> Yes, we can use thePainterMultiResolutionCachedImage.class object as a >> key in the PainterMultiResolutionCachedImage.getResolutionVariant() >> method. >> >> But there is below concern, >> >> 2. If PainterMultiResolutionCachedImage.class object is used as >> key in /Map cacheMap;/ >> >> 3. There will be only one key value pair entry in the /cacheMap/. >> >> The CachedPainter.paint0() method uses getClass() as a key for the >> cacheMap. At least there should be more than 1 key (getClass() + >> PainterMultiResolutionCachedImage.class). >> >> >> 4. The /ImageCache/ value created for the >> /PainterMultiResolutionCachedImage class/ is only of size 1. >> >> 5. Hence there will be only one image present at a time in the >> /cacheMap/. >> >> 6. Each time a new image is added, previous one will get >> deleted. In method: /ImageCache::getEntry() => if >> (entries.size() >= maxCount) { entries.removeLast(); }/ >> >> 7. This will result repeated deletion and creation of images. >> >> >> >> This requires increase in the size of /ImageCache /associated >> with/PainterMultiResolutionCachedImage.class /key to a certain >> justified value. >> >> For example, we can set the value to 8, so that at a time 8 images can >> be stored in the /ImageCache/. So for to add 9^th entry, last image >> would be removed. >> >> I am not sure what this value can be. I think this value can be number >> of components. >> >> SwinSet2 demo creates 17+ such images. >> >> After deciding a good value, this change can be done, a lesser value >> may add to processing by re-creating images. >> >> >> >> Currently we have 2 approaches: >> >> Approach1: /PainterMultiResolutionCachedImage >> /object as key, with/hashCode() & equals() >> /method/. >> /http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ >> >> >> Approach2: /PainterMultiResolutionCachedImage.class >> /object//as key, with a good justified size of/ImageCache. >> /http://cr.openjdk.java.net/~arapte/8163261/webrev.03/ >> >> >> Could the image cache size be increased only for the >> PainterMultiResolutionCachedImage.class key in the approach 2 because >> other keys may require only one image? >> >> Thanks, >> Alexandr. >> >> / / >> >> BOTH the approach would result in creating same number of creating >> images, in a normal scenario. >> >> however depending of GC/OOM this can change, as we have soft >> references to images. >> >> I observed over a long run of SwingSet2, Approach2 creates less number >> of images, but Approach1 recreates images. >> >> >> >> Another difference would be, >> >> Approach1 will add pair entries to /Map> ImageCache> cacheMap/. >> >> & >> >> Approach2 will add only ONE pair entry to /Map> ImageCache> cacheMap;/ But add entries to associated /ImageCache/. >> >> >> >> I think, approach 2 can be used with a justified size of ImageCache. >> In webrev.03 it is 32. >> >> Please provide, your comments. >> >> >> >> Regards, >> >> Ambarish >> >> >> >> *From:*Alexandr Scherbatiy >> *Sent:* Monday, August 29, 2016 6:09 PM >> *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; >> swing-dev at openjdk.java.net >> *Subject:* Re: Review Request for 8163261: regression on >> Linux: java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java >> >> >> >> >> CachedPainter.paint0() uses the object returned by getClass() as a key >> for the cache. >> Is it possible to use PainterMultiResolutionCachedImage.class object >> as a key in the >> PainterMultiResolutionCachedImage.getResolutionVariant() method? >> >> Thanks, >> Alexandr. >> >> On 8/26/2016 1:34 PM, Ambarish Rapte wrote: >> >> Hi Alex & All, >> >> Please review the updated webrev : >> http://cr.openjdk.java.net/~arapte/8163261/webrev.02/ >> >> >> >> >> Changes: (Copying from the previous email) >> >> I have included the change you suggested, to set component >> reference null after painting the component. >> >> >> >> In addition there is change in >> PainterMultiResolutionCachedImage to add /hashCode()/ & /equals()/ >> methods. >> >> Object of /PainterMultiResolutionCachedImage/ is >> used as key in the /Map cacheMap./ >> >> /hashCode()/ & /equals()/ would avoid multiple >> entries of similar image objects in the /cacheMap/ & help reduce >> the size of /cacheMap./ >> >> / / >> >> Verified this change by executing the /SwinSet2/ >> demo, all components get painted correctly. >> >> >> >> Also a small change in test, added check on panel >> reference and modified error message. >> >> >> >> Regards, >> >> Ambarish >> >> >> >> *From:*Ambarish Rapte >> *Sent:* Friday, August 26, 2016 12:34 PM >> *To:* Ambarish Rapte; Alexander Scherbatiy; Sergey Bylokhov; >> Rajeev Chamyal; swing-dev at openjdk.java.net >> >> *Subject:* RE: Review Request for 8163261: regression >> on Linux: >> java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java >> >> >> >> Hi All, >> >> Please hold the review for this. >> >> There are some merge conflicts with latest code so I shall update >> the webrev again for review. >> >> >> >> Regards, >> >> Ambarish >> >> >> >> *From:*Ambarish Rapte >> *Sent:* Thursday, August 25, 2016 10:19 PM >> *To:* Alexander Scherbatiy; Sergey Bylokhov; Rajeev Chamyal; >> swing-dev at openjdk.java.net >> *Subject:* Re: Review Request for 8163261: regression >> on Linux: >> java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java >> >> >> >> Hi Alex, >> >> Thanks for the review comments, >> >> Please review the updated webrev: >> http://cr.openjdk.java.net/~arapte/8163261/webrev.01/ >> >> >> >> >> I have included the change you suggested, to set >> component reference null after painting the component. >> >> >> >> In addition there is change in >> PainterMultiResolutionCachedImage to add /hashCode()/ & /equals()/ >> methods. >> >> Object of /PainterMultiResolutionCachedImage/ is >> used as key in the /Map cacheMap./ >> >> /hashCode()/ & /equals()/ would avoid multiple >> entries of similar image objects in the /cacheMap/ & help reduce >> the size of /cacheMap./ >> >> / / >> >> Verified this change by executing the /SwinSet2/ >> demo, all components get painted correctly. >> >> >> >> Also a small change in test, added check on panel >> reference and modified error message. >> >> >> >> Regards, >> >> Ambarish >> >> >> >> *From:*Alexander Scherbatiy >> *Sent:* Monday, August 22, 2016 5:47 PM >> *To:* Ambarish Rapte; Sergey Bylokhov; Rajeev Chamyal; >> swing-dev at openjdk.java.net >> *Subject:* Re: Review Request for 8163261: regression >> on Linux: >> java/awt/LightweightDispatcher/LWDispatcherMemoryLeakTest.java >> >> >> >> >> On 17/08/16 15:49, Alexandr Scherbatiy wrote: >> >> On 8/15/2016 12:43 PM, Ambarish Rapte wrote: >> >> Hi, >> >> Please review fix for JDK9, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163261 >> >> Webrev: >> http://cr.openjdk.java.net/~arapte/8163261/webrev.00/ >> >> >> >> >> Issue: >> >> Reference to JButton was not getting collected by GC. >> >> >> >> Cause: >> >> A strong reference to objects was held by >> PainterMultiResolutionCachedImage. >> >> And the image reference was held by HashMap. >> >> >> >> Fix: >> >> Changing the HashMap to WeakHashMap. Entry to >> WeakHashMap gets removed after the object has no other strong >> reference. >> >> May be using the soft reference would be better in this case. >> It could be expensive to recreate a cache with images every time >> GC removed them. >> >> >> There is the code which sets a component to the >> PainterMultiResolutionCachedImage: >> CachedPainter.paint0(...) >> ------- >> if (image instanceof PainterMultiResolutionCachedImage) { >> ((PainterMultiResolutionCachedImage) >> image).setParams(c, args); >> } >> >> // Render to the passed in Graphics >> paintImage(c, g, x, y, w, h, image, args); >> ------- >> >> May be it is possible to clean up the component and args from the >> PainterMultiResolutionCachedImage after the image is drawn? >> >> >> Thanks, >> Alexandr. >> >> >> >> >> >> >> >> Regards, >> >> Ambarish >> >> >> >> >> >> >> >> >> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Sep 15 10:09:59 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Thu, 15 Sep 2016 13:09:59 +0300 Subject: [9] Review request for JDK-8150176 [hidpi] wrong resolution variant of multi-res. image is used for TrayIcon In-Reply-To: References: <613ed421-289a-11c2-c256-09316262247b@oracle.com> <72bc3219-8476-4412-a58c-4465ac6899c2@default> <39b43048-49d8-0ef2-422a-05260a39533d@oracle.com> <26da165f-0d84-4f33-8920-6ae1f7a24b32@default> <9d8c0dc7-9594-0a3c-5b49-cf78b42b997e@oracle.com> <7aca2def-71e6-6ca1-a587-696111af9eb5@oracle.com> Message-ID: <5d38134f-7801-0d14-1b4f-e0e3a27c7d28@oracle.com> The fix looks good to me. Thanks, Alexandr. On 9/15/2016 1:01 PM, Sergey Bylokhov wrote: > +1 > > On 15.09.16 9:24, Rajeev Chamyal wrote: >> Hello Sergey, >> >> I have removed the html file. >> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: 14 September 2016 23:39 >> To: Alexandr Scherbatiy; Rajeev Chamyal; swing-dev at openjdk.java.net >> Subject: Re: [9] Review request for JDK-8150176 [hidpi] >> wrong resolution variant of multi-res. image is used for TrayIcon >> >> Is "MultiResolutionTrayIconTest.html" should be removed? >> >> On 14.09.16 17:44, Alexandr Scherbatiy wrote: >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/14/2016 12:01 PM, Rajeev Chamyal wrote: >>>> >>>> Hello Alexandr, >>>> >>>> >>>> >>>> Thanks for the review. >>>> >>>> Please review the webrev updated as per review comments. >>>> >>>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.03/ >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rajeev Chamyal >>>> >>>> >>>> >>>> *From:*Alexandr Scherbatiy >>>> *Sent:* 12 September 2016 20:07 >>>> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net; Sergey Bylokhov >>>> *Subject:* Re: [9] Review request for JDK-8150176 [hidpi] >>>> wrong resolution variant of multi-res. image is used for TrayIcon >>>> >>>> >>>> >>>> On 9/9/2016 3:06 PM, Rajeev Chamyal wrote: >>>> >>>> Hello Alexandr, >>>> >>>> >>>> >>>> Please review the updated webrev. >>>> >>>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.02/ >>>> >>>> >>>> WTrayIconPeer.java >>>> + gr.drawImage(image, 0, 0, (autosize ? w : >>>> image.getWidth(observer)), >>>> + (autosize ? h : >>>> image.getHeight(observer)), observer); >>>> >>>> The w and h are scaled. It looks like the image.getWidth(observer) >>>> and >>>> image.getHeight(observer) also should be scaled in the same way. >>>> >>>> MultiResolutionTrayIconTest.java >>>> + latch.await(); >>>> >>>> It is better to add a timeout here. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> >>>> >>>> >>>> >>>> Update: Updated webrev is fixing the issue in windows only. >>>> >>>> We have a separate bug linux and it will be fixed through a >>>> separate webrev. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8154551 >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rajeev Chamyal >>>> >>>> >>>> >>>> *From:*Alexandr Scherbatiy >>>> *Sent:* 14 June 2016 15:21 >>>> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >>>> ; Sergey Bylokhov >>>> *Subject:* Re: [9] Review request for JDK-8150176 >>>> [hidpi] wrong resolution variant of multi-res. image is used for >>>> TrayIcon >>>> >>>> >>>> >>>> On 6/13/2016 3:18 PM, Rajeev Chamyal wrote: >>>> >>>> >>>> Hello Alexandr, >>>> >>>> >>>> >>>> Thanks for the review. I have updated the webrev as per review >>>> comments. >>>> >>>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.01/ >>>> >>>> >>>> I tried drawing the image directly to paint graphics without >>>> buffered image and it was getting cropped. >>>> >>>> >>>> Did you paint it using non scaled width and height? >>>> g.drawImage(image, 0, 0, curW, curH, null); >>>> Is the g transform already scaled? >>>> >>>> XTrayIconPeer: >>>> >>>> 606 if (scaleX > 1.0 && scaleY > 1.0) { >>>> >>>> 607 resolutionVariant = >>>> ((MultiResolutionImage) image). >>>> >>>> >>>> It is better to change the condition to "image instanceof >>>> MultiResolutionImage". It is necessary to not get CCE for non >>>> multi-resolution image and the multi-resolution image should >>>> return the best resolution variant for any scale. >>>> >>>> 618 gr.drawImage(resolutionVariant, 0, 0, >>>> >>>> 619 curW, curH, observer); >>>> >>>> The width and height should be scaled here to draw to whole >>>> buffered image. >>>> >>>> WTrayIconPeer: >>>> >>>> 133 BufferedImage bufImage = new >>>> BufferedImage(TRAY_ICON_WIDTH, TRAY_ICON_HEIGHT, >>>> 134 >>>> BufferedImage.TYPE_INT_ARGB); >>>> >>>> The size for the buffered image should be scaled in the same was >>>> as for XTrayIconPeer. >>>> It may require to update the native code as well to set proper >>>> high-resolution icon. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rajeev Chamyal >>>> >>>> >>>> >>>> *From:*Alexandr Scherbatiy >>>> *Sent:* 09 June 2016 20:43 >>>> *To:* Rajeev Chamyal; swing-dev at openjdk.java.net >>>> ; Sergey Bylokhov >>>> *Subject:* Re: [9] Review request for JDK-8150176 >>>> [hidpi] wrong resolution variant of multi-res. image is used >>>> for TrayIcon >>>> >>>> >>>> >>>> On 6/9/2016 11:55 AM, Rajeev Chamyal wrote: >>>> >>>> >>>> >>>> Hello All, >>>> >>>> >>>> >>>> Please review the following fix. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150176 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rchamyal/8150176/webrev.00/ >>>> >>>> >>>> >>>> >>>> >>>> Issue: Wrong resolution variant image is used in Tray >>>> Icon. >>>> >>>> Fix : Applying the device transform to graphics object to >>>> select the correct image. >>>> >>>> The image could be cropped on Linux because the high >>>> resolution icon which size is bigger that the original image >>>> is drawn to the buffered image with un-scaled size curW x >>>> CurH. >>>> It is better to get a resolution variant from the >>>> multi-resolution image, draw it to a buffered image with the >>>> same scaled size and then draw the buffered image to the paint >>>> graphics using original size: >>>> ------- >>>> Image resolutionVariant = ((MultiResolutionImage) >>>> image).getResolutionVariant(scaleX * curW, scaleY * curH); >>>> BufferedImage bufImage = new BufferedImage(scaleX * curW, >>>> scaleY * curH, BufferedImage.TYPE_INT_ARGB); >>>> // ... >>>> gr.drawImage(image, 0, 0, scaleX * curW, scaleY * curH, >>>> observer); >>>> // ... >>>> g.drawImage(bufImage, 0, 0, curW, curH, observer); // non >>>> scaled width and height >>>> ------- >>>> >>>> By the way, is the buffered image necessary in this case? Is >>>> it possible to draw the image directly to the paint graphics? >>>> ------- >>>> g.drawImage(image, 0, 0, curW, curH, null); >>>> ------- >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rajeev Chamyal >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. >> > > From semyon.sadetsky at oracle.com Thu Sep 15 10:49:20 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 15 Sep 2016 13:49:20 +0300 Subject: [9] Review request for 8163124 Add floating point API support to javax.swing.text.Caret In-Reply-To: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> References: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> Message-ID: Hi Alexander, Could you run the next test (with x8 scale, for example): public class New2dApiTest { public static void main(String[] args) { JTextArea jTextArea2d = new JTextArea("jksxbqhbxniiiaiiaawww") { @Override protected void paintComponent(Graphics g) { super.paintComponent(g); Graphics2D g2d = (Graphics2D) g; g2d.setColor(new Color(255, 0, 0, 50)); for (int i = 0; i < getText().length(); i++) { try { g2d.fill(modelToView2D(i)); } catch (BadLocationException e) { e.printStackTrace(); } } } }; JTextArea jTextArea = new JTextArea("jksxbqhbxniiiaiiaawww") { @Override protected void paintComponent(Graphics g) { super.paintComponent(g); Graphics2D g2d = (Graphics2D) g; g2d.setColor(new Color(0, 0, 255, 50)); for (int i = 0; i < getText().length(); i++) { try { g2d.fill(modelToView(i)); } catch (BadLocationException e) { e.printStackTrace(); } } } }; JFrame jFrame = new JFrame(); jFrame.getContentPane().setLayout(new GridLayout(2, 1)); jFrame.getContentPane().add(jTextArea2d); jFrame.getContentPane().add(jTextArea); jFrame.pack(); jFrame.setVisible(true); } } For some reason I cannot see the difference with the new and old API result. --Semyon On 04.08.2016 15:44, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8163124 > webrev: http://cr.openjdk.java.net/~alexsch/8163124/webrev.00 > > The text position can have floating point value on HiDPI display. > The Caret interface should be updated to allow use floating point > positions. > > The fix adds the following public API with floating point positions: > javax.swing.text.Caret.getMagicCaretPosition2D() > javax.swing.text.Caret.setMagicCaretPosition2D(Point2D p) > javax.swing.text.JTextComponent.modelToView2D(int pos) > javax.swing.text.JTextComponent.viewToModel2D(Point2D pt) > javax.swing.text.ParagraphView.getClosestPositionTo(int pos, > Position.Bias b, Shape a, int direction, Position.Bias[], int > rowIndex, float x) > > > The fix replaces > Caret.getMagicCaretPosition()/setMagicCaretPosition(Point p) to > Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D p) in > all places > except DefaultCaret because DefaultCaret extends Rectangle so its > coordinates always have int values. > I have filled a separated enhancement for this JDK-8163174 Add > DefaultCaret2D which supports floating point API > > To make a custom caret use floating point API it is also necessary > that PlainView.modelToView() returns a rectangle with floating point > values. It can be done after the fix > JDK-8156217 Selected text is shifted on HiDPI display > which implements Utilities.getTabbedTextWidth(Segment s, FontMetrics > metrics, float x, TabExpander e, int startOffset) method. > I have filled a separated issue on it: > JDK-8163175 PlainView.modelToView() method should return Rectangle2D > > Thanks, > Alexandr. From semyon.sadetsky at oracle.com Thu Sep 15 11:03:18 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 15 Sep 2016 14:03:18 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: <3d41ceaa-54ca-6867-b735-80395701fa78@oracle.com> References: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> <3d41ceaa-54ca-6867-b735-80395701fa78@oracle.com> Message-ID: <5b279e84-8dc6-b979-2c78-1040825cfcd8@oracle.com> On 15.09.2016 12:49, Alexandr Scherbatiy wrote: > On 9/15/2016 11:47 AM, Semyon Sadetsky wrote: >> On 14.09.2016 21:00, Alexandr Scherbatiy wrote: >>> On 9/14/2016 6:41 PM, Alexandr Scherbatiy wrote: >>>> On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154043 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ >>>>> >>>>> The new RadioButton group focus traversal algorithm introduced by >>>>> JDK-8033699 doesn't take into account that group of radio buttons >>>>> can be lay-outed in several lines in container. In this case the >>>>> LayoutFocusTraversalPolicy may mix radio buttons of the same group >>>>> with other components in its focus traversal order and break the >>>>> assumption used in >>>>> BasicRadioButtonUI#getFocusTransferBaseComponent() that radio >>>>> buttons are sequenced in the focus policy order. >>>>> >>>>> The fix propose to treat a group of toggle buttons as a single >>>>> focus cycle entry in the LayoutFocusTraversalPolicy which order is >>>>> determined by the first toggle button in the group. >>>> Should the test for the fix JDK-8033699 >>>> test/javax/swing/JRadioButton/8033699/bug8033699.java be updated as >>>> well? >>> Is it possible to move the focus from the current radio button to >>> the next component which does not belong to the current radio >>> buttons group by pressing tab key? >>> For example in the test FocusCycleRootTest from the issue >>> description, moving the focus from the first and the second radio >>> button to the text field 1 and from the third and the fourth radio >>> button to the text field 2. >> It is possible. But then the group will get focus second (or more) >> time during the cycle. Seems, this is not correct because option in >> the group has already been selected. > It is not clear is it correct that pressing an arrow key selects a > radio button in a group. For example each radio button selection can > trigger some action. So trying to select the latest radio button it is > necessary to move the focus from the first button to the last by arrow > keys so radio buttons in the middle will also be unnecessary selected. > Usually the space key is responsible to a button selection. I did not get the concern. Arrow buttons are aimed to cycle all buttons group consequently. Tab key should move focus outside the group. Space key doesn't change focus. >> Also it looks inconsistent when the second option is skipped in the >> cycle while the third is not. > This is because the tab key is pressed which can move the focus from > the group and back. The arrow keys are used to move the focus in the > group. > It preserves the tab key behavior before the fix 8033699 except > radio buttons in the group. Group of options can be treated as one control which should be visited only once during single cycle. Because it is more correct from usability point of view: if user has made a selection it is unnecessary to return to this control again. Also what do you propose seems to contradict the 8074883 which requires only one selected option to be focused always in the group. --Semyon > > Thanks, > Alexandr. > >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Thu Sep 15 13:11:18 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 15 Sep 2016 17:11:18 +0400 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: <5b279e84-8dc6-b979-2c78-1040825cfcd8@oracle.com> References: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> <3d41ceaa-54ca-6867-b735-80395701fa78@oracle.com> <5b279e84-8dc6-b979-2c78-1040825cfcd8@oracle.com> Message-ID: <62b69f07-8bf4-992c-a5da-3941ac2a201e@oracle.com> On 15/09/16 15:03, Semyon Sadetsky wrote: > > > On 15.09.2016 12:49, Alexandr Scherbatiy wrote: >> On 9/15/2016 11:47 AM, Semyon Sadetsky wrote: >>> On 14.09.2016 21:00, Alexandr Scherbatiy wrote: >>>> On 9/14/2016 6:41 PM, Alexandr Scherbatiy wrote: >>>>> On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154043 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ >>>>>> >>>>>> The new RadioButton group focus traversal algorithm introduced by >>>>>> JDK-8033699 doesn't take into account that group of radio buttons >>>>>> can be lay-outed in several lines in container. In this case the >>>>>> LayoutFocusTraversalPolicy may mix radio buttons of the same >>>>>> group with other components in its focus traversal order and >>>>>> break the assumption used in >>>>>> BasicRadioButtonUI#getFocusTransferBaseComponent() that radio >>>>>> buttons are sequenced in the focus policy order. >>>>>> >>>>>> The fix propose to treat a group of toggle buttons as a single >>>>>> focus cycle entry in the LayoutFocusTraversalPolicy which order >>>>>> is determined by the first toggle button in the group. >>>>> Should the test for the fix JDK-8033699 >>>>> test/javax/swing/JRadioButton/8033699/bug8033699.java be updated >>>>> as well? >>>> Is it possible to move the focus from the current radio button to >>>> the next component which does not belong to the current radio >>>> buttons group by pressing tab key? >>>> For example in the test FocusCycleRootTest from the issue >>>> description, moving the focus from the first and the second radio >>>> button to the text field 1 and from the third and the fourth radio >>>> button to the text field 2. >>> It is possible. But then the group will get focus second (or more) >>> time during the cycle. Seems, this is not correct because option in >>> the group has already been selected. >> It is not clear is it correct that pressing an arrow key selects a >> radio button in a group. For example each radio button selection can >> trigger some action. So trying to select the latest radio button it >> is necessary to move the focus from the first button to the last by >> arrow keys so radio buttons in the middle will also be unnecessary >> selected. Usually the space key is responsible to a button selection. > I did not get the concern. Arrow buttons are aimed to cycle all > buttons group consequently. Tab key should move focus outside the > group. Space key doesn't change focus. >>> Also it looks inconsistent when the second option is skipped in the >>> cycle while the third is not. >> This is because the tab key is pressed which can move the focus >> from the group and back. The arrow keys are used to move the focus in >> the group. >> It preserves the tab key behavior before the fix 8033699 except >> radio buttons in the group. > Group of options can be treated as one control which should be visited > only once during single cycle. Because it is more correct from > usability point of view: if user has made a selection it is > unnecessary to return to this control again. > Also what do you propose seems to contradict the 8074883 which > requires only one selected option to be focused always in the group. I see the point that the group of buttons should be treated as one control from the focus point of view. I read the description of the JDK-8033699 but it is not still clear to me is selecting a radio button by pressing an arrow key follows to the industry standard? One more question which I have relates to a group of radio buttons there no one of them is selected. Should tab pressing moves the focus to the first button or to the latest one which has been selected or just using standard focus order for components? Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >> >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>> >>>> >>> >> > From andrej.golovnin at gmail.com Fri Sep 16 08:22:54 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 16 Sep 2016 10:22:54 +0200 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> Message-ID: Hi Alexandr, thanks! It looks much better now. > http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java 490 if(isScaledGraphics){ Spaces are missed between 'if' and '(' and between ')' and '{'. The empty lines 491, 520 and 522 are not needed and should be removed. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicArrowButton.java 240 if(SwingUtilities2.isScaledGraphics(g)){ Spaces are missed between 'if' and '(' and between ')' and '{'. 344 xPoints = new int[]{mid, mid + size, mid - size}; The Java Style Guidelines [1] don't mention this. But I think there should be a space between 'new int[]' and '{'. The lines 345, 356, 357, 366 and 367 are also affected. src/java.desktop/share/classes/sun/swing/SwingUtilities2.java 2041 public static boolean isScaledGraphics(Graphics g) { Have you considered to make this method a public API (move to the SwingUtilities class), so that other Swing developers may use it too? > [2] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png > [3] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png Radio buttons are still not ideal. Have you considered to enable AA when painting HiDPI icons? On the other hand I'm not sure, whether we should invest a lot of time into making Windows Classic L&f to look perfect on HiDPI screens. Best regards, Andrej Golovnin [1] http://cr.openjdk.java.net/~alundblad/styleguide/ From alexey.ivanov at oracle.com Fri Sep 16 10:20:30 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 16 Sep 2016 13:20:30 +0300 Subject: OpenJDK JDK-7067885 code changes for community review In-Reply-To: References: Message-ID: <549b7026-cbf3-8bc3-a593-561699431554@oracle.com> Hi Alok, This change should be discussed on swing-dev mailing list because you modify behavior of javax.swing.JFileChooser, and on core-libs-dev because you also modify java.io.File. I agree with Alan, using the new API appears to be a better alternative than changing java.io.File. Regards, Alexey On 12.09.2016 19:08, Alan Bateman wrote: > Best to follow-up on swing-dev as I assume the right thing is to > update JFileChooser rather than changing java.io.File to be mutable. > You did acknowledge near the end of your mail that the new file system > API supports sym links so it may be that JFileChooser could use that. > > -Alan > > > On 12/09/2016 08:41, Sharma, Alok Kumar (OSTL) wrote: >> Following is the fix for JDK-7067885. I am not sure which mailing ID >> to post this. >> >> Bug: FileChooser does not display soft link name if link is to >> nonexistent file/directory >> https://bugs.openjdk.java.net/browse/JDK-7067885 >> >> This bug is unassigned. Can someone please look into these changes >> and get back to me? Explanation of fix is at the end of the source >> code diff. >> >> Mercurial diff for source change: >> ------------------------------------------------------------------- >> diff -r 021369229cfd src/java.base/share/classes/java/io/File.java >> --- a/src/java.base/share/classes/java/io/File.java Tue Sep 06 >> 13:09:29 2016 -0400 >> +++ b/src/java.base/share/classes/java/io/File.java Mon Sep 12 >> 11:27:07 2016 +0530 >> @@ -164,6 +164,27 @@ >> private final String path; >> >> /** >> + * The flag indicates whether to follow the symlink. >> + */ >> + private boolean follow_link = true; >> + >> + /** >> + * Sets the follow_link of file. >> + * description: Sets follow_link on or off. >> + * @param follow_link the value that determines whether to follow >> the symlink or not. >> + * TRUE: file.io.exists() checks the file existence using >> stat() which follows the symlink. >> + * >> + * FALSE: file.io.exists() checks the file existence using >> lstat() if stat() fails to retrieve >> + * the file info. lstat() if file is a symbolic link, then >> it returns information >> + * about the link itself. >> + * @return Returns ZERO at success >> + */ >> + public int set_follow_link(boolean follow_link) { >> + this.follow_link=follow_link; >> + return 0; >> + } >> + >> + /** >> * Enum type that indicates the status of a file path. >> */ >> private static enum PathStatus { INVALID, CHECKED }; >> diff -r 021369229cfd >> src/java.base/unix/native/libjava/UnixFileSystem_md.c >> --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Tue Sep >> 06 13:09:29 2016 -0400 >> +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon Sep >> 12 11:27:07 2016 +0530 >> @@ -51,6 +51,7 @@ >> #define dirent64 dirent >> #define readdir64_r readdir_r >> #define stat64 stat >> +#define lstat64 lstat >> #ifndef MACOSX >> #define statvfs64 statvfs >> #endif >> @@ -62,6 +63,7 @@ >> jfieldID path; >> } ids; >> >> +jfieldID ufs_follow_link; >> >> JNIEXPORT void JNICALL >> Java_java_io_UnixFileSystem_initIDs(JNIEnv *env, jclass cls) >> @@ -70,6 +72,8 @@ >> if (!fileClass) return; >> ids.path = (*env)->GetFieldID(env, fileClass, >> "path", "Ljava/lang/String;"); >> + ufs_follow_link = (*env)->GetFieldID(env, fileClass, >> + "follow_link", "Z"); >> } >> >> /* -- Path operations -- */ >> @@ -113,20 +117,42 @@ >> return JNI_FALSE; >> } >> >> +static jboolean >> +lstatMode(const char *path, int *mode) >> +{ >> + struct stat64 sb; >> + if (lstat64(path, &sb) == 0) { >> + *mode = sb.st_mode; >> + return JNI_TRUE; >> + } >> + return JNI_FALSE; >> +} >> >> JNIEXPORT jint JNICALL >> Java_java_io_UnixFileSystem_getBooleanAttributes0(JNIEnv *env, >> jobject this, >> jobject file) >> { >> jint rv = 0; >> + jint follow_link = 0; >> >> WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) { >> int mode; >> - if (statMode(path, &mode)) { >> - int fmt = mode & S_IFMT; >> - rv = (jint) (java_io_FileSystem_BA_EXISTS >> - | ((fmt == S_IFREG) ? >> java_io_FileSystem_BA_REGULAR : 0) >> - | ((fmt == S_IFDIR) ? >> java_io_FileSystem_BA_DIRECTORY : 0)); >> + follow_link = (*env)->GetBooleanField(env, file, >> ufs_follow_link); >> + if ( follow_link ) { >> + if (statMode(path, &mode)) { >> + int fmt = mode & S_IFMT; >> + rv = (jint) (java_io_FileSystem_BA_EXISTS >> + | ((fmt == S_IFREG) ? >> java_io_FileSystem_BA_REGULAR : 0) >> + | ((fmt == S_IFDIR) ? >> java_io_FileSystem_BA_DIRECTORY : 0)); >> + } >> + } >> + else { >> + if (lstatMode(path, &mode)) { >> + int fmt = mode & S_IFMT; >> + rv = (jint) (java_io_FileSystem_BA_EXISTS >> + | ((fmt == S_IFREG) ? >> java_io_FileSystem_BA_REGULAR : 0) >> + | ((fmt == S_IFDIR) ? >> java_io_FileSystem_BA_DIRECTORY : 0)); >> + } >> } >> } END_PLATFORM_STRING(env, path); >> return rv; >> diff -r 021369229cfd >> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> --- >> a/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> Tue Sep 06 13:09:29 2016 -0400 >> +++ >> b/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >> Mon Sep 12 11:27:07 2016 +0530 >> @@ -521,6 +521,7 @@ >> f = createFileSystemRoot(f); >> } >> try { >> + f.set_follow_link(false); >> f = ShellFolder.getShellFolder(f); >> } catch (FileNotFoundException e) { >> // Not a valid file (wouldn't show in native >> file chooser) >> ------------------------------------------ >> >> Below is the explanation for fix. >> >> Problem description: >> FileChooser behavior when there is a soft link to a non-existent >> file/directory. >> Soft link to be displayed with an error/exception when attempt is >> made to >> open it. Instead the soft link name is not displayed in the file >> chooser. >> >> Analysis: >> JFileChooser() internally uses java.io.exists() to check whether file >> exists. >> In this scenario JFileChooser() checks dangling symlink existence >> using java.io.exists(). >> java.io.exists() api does not handle dangling symlink and returns false. >> >> JFileChooser() expects exists() api to return true for dangling >> symlink but, java.io.exists() returns false. >> >> We see that there are two exists() apis in JAVA java.io.exists() and >> java.nio.exists(). >> >> java.nio.exists() handles dangling symlinks it accepts second >> argument link option which >> determines whether to follow the link or not and returns true for >> dangling symlinks. >> java.io.exists() follows the symlink and returns false if target file >> doesn't exist. >> >> We have enhanced the java.io.exists() api to return true if it is a >> dangling symlink. >> >> Changes in code: >> >> New variable "follow_link" is introduced in >> "jdk/src/java.base/share/classes/java/io/File.java", we check for >> this flag in exists() code >> if its set then we handle symlinks. In case of dangling symlink >> java.io.exists() api checks file existence >> symlink itself not the target file and returns true. >> >> JFileChooser() issue (JDK-7067885) gets resolved with these changes. >> >> Testing: >> I have covered the testing for the below apis. >> Jfilechooser >> getShellFolder >> FileSystemView >> and ran /openjdk9/jdk/test/javax/swing/JFileChooser/* tests. >> > From semyon.sadetsky at oracle.com Fri Sep 16 14:34:20 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 16 Sep 2016 17:34:20 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: <62b69f07-8bf4-992c-a5da-3941ac2a201e@oracle.com> References: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> <3d41ceaa-54ca-6867-b735-80395701fa78@oracle.com> <5b279e84-8dc6-b979-2c78-1040825cfcd8@oracle.com> <62b69f07-8bf4-992c-a5da-3941ac2a201e@oracle.com> Message-ID: <553e9c4e-dd9a-1e9f-0f6b-3955eceed899@oracle.com> On 15.09.2016 16:11, Alexander Scherbatiy wrote: > On 15/09/16 15:03, Semyon Sadetsky wrote: >> >> >> On 15.09.2016 12:49, Alexandr Scherbatiy wrote: >>> On 9/15/2016 11:47 AM, Semyon Sadetsky wrote: >>>> On 14.09.2016 21:00, Alexandr Scherbatiy wrote: >>>>> On 9/14/2016 6:41 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review fix for JDK9: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154043 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ >>>>>>> >>>>>>> The new RadioButton group focus traversal algorithm introduced >>>>>>> by JDK-8033699 doesn't take into account that group of radio >>>>>>> buttons can be lay-outed in several lines in container. In this >>>>>>> case the LayoutFocusTraversalPolicy may mix radio buttons of the >>>>>>> same group with other components in its focus traversal order >>>>>>> and break the assumption used in >>>>>>> BasicRadioButtonUI#getFocusTransferBaseComponent() that radio >>>>>>> buttons are sequenced in the focus policy order. >>>>>>> >>>>>>> The fix propose to treat a group of toggle buttons as a single >>>>>>> focus cycle entry in the LayoutFocusTraversalPolicy which order >>>>>>> is determined by the first toggle button in the group. >>>>>> Should the test for the fix JDK-8033699 >>>>>> test/javax/swing/JRadioButton/8033699/bug8033699.java be updated >>>>>> as well? >>>>> Is it possible to move the focus from the current radio button >>>>> to the next component which does not belong to the current radio >>>>> buttons group by pressing tab key? >>>>> For example in the test FocusCycleRootTest from the issue >>>>> description, moving the focus from the first and the second radio >>>>> button to the text field 1 and from the third and the fourth radio >>>>> button to the text field 2. >>>> It is possible. But then the group will get focus second (or more) >>>> time during the cycle. Seems, this is not correct because option in >>>> the group has already been selected. >>> It is not clear is it correct that pressing an arrow key selects a >>> radio button in a group. For example each radio button selection can >>> trigger some action. So trying to select the latest radio button it >>> is necessary to move the focus from the first button to the last by >>> arrow keys so radio buttons in the middle will also be unnecessary >>> selected. Usually the space key is responsible to a button selection. >> I did not get the concern. Arrow buttons are aimed to cycle all >> buttons group consequently. Tab key should move focus outside the >> group. Space key doesn't change focus. >>>> Also it looks inconsistent when the second option is skipped in the >>>> cycle while the third is not. >>> This is because the tab key is pressed which can move the focus >>> from the group and back. The arrow keys are used to move the focus >>> in the group. >>> It preserves the tab key behavior before the fix 8033699 except >>> radio buttons in the group. >> Group of options can be treated as one control which should be >> visited only once during single cycle. Because it is more correct >> from usability point of view: if user has made a selection it is >> unnecessary to return to this control again. >> Also what do you propose seems to contradict the 8074883 which >> requires only one selected option to be focused always in the group. > I see the point that the group of buttons should be treated as one > control from the focus point of view. > I read the description of the JDK-8033699 but it is not still clear > to me is selecting a radio button by pressing an arrow key follows to > the industry standard? In native apps and in browsers it works that way. > > One more question which I have relates to a group of radio buttons > there no one of them is selected. Should tab pressing moves the focus > to the first button or to the latest one which has been selected or > just using standard focus order for components? It is not good style to leave all radio buttons unselected in one group. I think the first one should be selected in this case. Also, yes, the test/javax/swing/JRadioButton/8033699/bug8033699.java should be modified. The updated webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev.01/ --Semyon > > Thanks, > Alexandr. > >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Sep 19 19:43:50 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 19 Sep 2016 22:43:50 +0300 Subject: [9] Review request for 8163124 Add floating point API support to javax.swing.text.Caret In-Reply-To: References: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> Message-ID: <5840c3a5-a3d5-86d1-223a-fcb5aba73fb5@oracle.com> This is the known issue: JDK-8163175 PlainView.modelToView() method should return Rectangle2D It is included into the fix JDK-8156217 Selected text is shifted on HiDPI display. You can apply the fix [1] JDK-8156217 to the JDK and try the proposed sample. I get the results [2] for scale 2x and [3] for scale 8x. [1] http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all [2] http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-2x.png [3] http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-8x.png Thanks, Alexandr. On 9/15/2016 1:49 PM, Semyon Sadetsky wrote: > Hi Alexander, > > Could you run the next test (with x8 scale, for example): > > public class New2dApiTest { > public static void main(String[] args) { > JTextArea jTextArea2d = new JTextArea("jksxbqhbxniiiaiiaawww") { > @Override > protected void paintComponent(Graphics g) { > super.paintComponent(g); > Graphics2D g2d = (Graphics2D) g; > g2d.setColor(new Color(255, 0, 0, 50)); > for (int i = 0; i < getText().length(); i++) { > try { > g2d.fill(modelToView2D(i)); > } catch (BadLocationException e) { > e.printStackTrace(); > } > } > } > }; > JTextArea jTextArea = new JTextArea("jksxbqhbxniiiaiiaawww") { > @Override > protected void paintComponent(Graphics g) { > super.paintComponent(g); > Graphics2D g2d = (Graphics2D) g; > g2d.setColor(new Color(0, 0, 255, 50)); > for (int i = 0; i < getText().length(); i++) { > try { > g2d.fill(modelToView(i)); > } catch (BadLocationException e) { > e.printStackTrace(); > } > } > } > }; > > JFrame jFrame = new JFrame(); > jFrame.getContentPane().setLayout(new GridLayout(2, 1)); > jFrame.getContentPane().add(jTextArea2d); > jFrame.getContentPane().add(jTextArea); > jFrame.pack(); > jFrame.setVisible(true); > > } > } > > > For some reason I cannot see the difference with the new and old API > result. > > --Semyon > > > On 04.08.2016 15:44, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8163124 >> webrev: http://cr.openjdk.java.net/~alexsch/8163124/webrev.00 >> >> The text position can have floating point value on HiDPI display. >> The Caret interface should be updated to allow use floating point >> positions. >> >> The fix adds the following public API with floating point positions: >> javax.swing.text.Caret.getMagicCaretPosition2D() >> javax.swing.text.Caret.setMagicCaretPosition2D(Point2D p) >> javax.swing.text.JTextComponent.modelToView2D(int pos) >> javax.swing.text.JTextComponent.viewToModel2D(Point2D pt) >> javax.swing.text.ParagraphView.getClosestPositionTo(int pos, >> Position.Bias b, Shape a, int direction, Position.Bias[], int >> rowIndex, float x) >> >> >> The fix replaces >> Caret.getMagicCaretPosition()/setMagicCaretPosition(Point p) to >> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D p) in >> all places >> except DefaultCaret because DefaultCaret extends Rectangle so its >> coordinates always have int values. >> I have filled a separated enhancement for this JDK-8163174 Add >> DefaultCaret2D which supports floating point API >> >> To make a custom caret use floating point API it is also necessary >> that PlainView.modelToView() returns a rectangle with floating point >> values. It can be done after the fix >> JDK-8156217 Selected text is shifted on HiDPI display >> which implements Utilities.getTabbedTextWidth(Segment s, >> FontMetrics metrics, float x, TabExpander e, int startOffset) method. >> I have filled a separated issue on it: >> JDK-8163175 PlainView.modelToView() method should return Rectangle2D >> >> Thanks, >> Alexandr. > From alexandr.scherbatiy at oracle.com Mon Sep 19 20:59:37 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 19 Sep 2016 23:59:37 +0300 Subject: [9] Review request for 8154043: Fields not reachable anymore by tab-key, because of new tabbing behaviour of radio button groups. In-Reply-To: <553e9c4e-dd9a-1e9f-0f6b-3955eceed899@oracle.com> References: <53bbca96-88df-de75-cc56-ff97001585ba@oracle.com> <3d41ceaa-54ca-6867-b735-80395701fa78@oracle.com> <5b279e84-8dc6-b979-2c78-1040825cfcd8@oracle.com> <62b69f07-8bf4-992c-a5da-3941ac2a201e@oracle.com> <553e9c4e-dd9a-1e9f-0f6b-3955eceed899@oracle.com> Message-ID: <5d56385e-6e2e-3912-05ac-6cf69f99f868@oracle.com> The fix looks good to me. Thanks, Alexandr. On 9/16/2016 5:34 PM, Semyon Sadetsky wrote: > > > On 15.09.2016 16:11, Alexander Scherbatiy wrote: >> On 15/09/16 15:03, Semyon Sadetsky wrote: >>> >>> >>> On 15.09.2016 12:49, Alexandr Scherbatiy wrote: >>>> On 9/15/2016 11:47 AM, Semyon Sadetsky wrote: >>>>> On 14.09.2016 21:00, Alexandr Scherbatiy wrote: >>>>>> On 9/14/2016 6:41 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/14/2016 1:48 PM, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review fix for JDK9: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154043 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154043/webrev/ >>>>>>>> >>>>>>>> The new RadioButton group focus traversal algorithm introduced >>>>>>>> by JDK-8033699 doesn't take into account that group of radio >>>>>>>> buttons can be lay-outed in several lines in container. In this >>>>>>>> case the LayoutFocusTraversalPolicy may mix radio buttons of >>>>>>>> the same group with other components in its focus traversal >>>>>>>> order and break the assumption used in >>>>>>>> BasicRadioButtonUI#getFocusTransferBaseComponent() that radio >>>>>>>> buttons are sequenced in the focus policy order. >>>>>>>> >>>>>>>> The fix propose to treat a group of toggle buttons as a single >>>>>>>> focus cycle entry in the LayoutFocusTraversalPolicy which order >>>>>>>> is determined by the first toggle button in the group. >>>>>>> Should the test for the fix JDK-8033699 >>>>>>> test/javax/swing/JRadioButton/8033699/bug8033699.java be updated >>>>>>> as well? >>>>>> Is it possible to move the focus from the current radio button >>>>>> to the next component which does not belong to the current radio >>>>>> buttons group by pressing tab key? >>>>>> For example in the test FocusCycleRootTest from the issue >>>>>> description, moving the focus from the first and the second radio >>>>>> button to the text field 1 and from the third and the fourth >>>>>> radio button to the text field 2. >>>>> It is possible. But then the group will get focus second (or more) >>>>> time during the cycle. Seems, this is not correct because option >>>>> in the group has already been selected. >>>> It is not clear is it correct that pressing an arrow key selects >>>> a radio button in a group. For example each radio button selection >>>> can trigger some action. So trying to select the latest radio >>>> button it is necessary to move the focus from the first button to >>>> the last by arrow keys so radio buttons in the middle will also be >>>> unnecessary selected. Usually the space key is responsible to a >>>> button selection. >>> I did not get the concern. Arrow buttons are aimed to cycle all >>> buttons group consequently. Tab key should move focus outside the >>> group. Space key doesn't change focus. >>>>> Also it looks inconsistent when the second option is skipped in >>>>> the cycle while the third is not. >>>> This is because the tab key is pressed which can move the focus >>>> from the group and back. The arrow keys are used to move the focus >>>> in the group. >>>> It preserves the tab key behavior before the fix 8033699 except >>>> radio buttons in the group. >>> Group of options can be treated as one control which should be >>> visited only once during single cycle. Because it is more correct >>> from usability point of view: if user has made a selection it is >>> unnecessary to return to this control again. >>> Also what do you propose seems to contradict the 8074883 which >>> requires only one selected option to be focused always in the group. >> I see the point that the group of buttons should be treated as one >> control from the focus point of view. >> I read the description of the JDK-8033699 but it is not still clear >> to me is selecting a radio button by pressing an arrow key follows to >> the industry standard? > In native apps and in browsers it works that way. >> >> One more question which I have relates to a group of radio buttons >> there no one of them is selected. Should tab pressing moves the focus >> to the first button or to the latest one which has been selected or >> just using standard focus order for components? > It is not good style to leave all radio buttons unselected in one > group. I think the first one should be selected in this case. > > Also, yes, the test/javax/swing/JRadioButton/8033699/bug8033699.java > should be modified. > The updated webrev: > http://cr.openjdk.java.net/~ssadetsky/8154043/webrev.01/ > > --Semyon >> >> Thanks, >> Alexandr. >> >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Sep 19 21:00:00 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 00:00:00 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: References: <57990608-d43c-8f81-5e28-8c9dace840a6@oracle.com> <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> <0f57ef7f-a8ad-fef0-5be9-b71250c23022@oracle.com> Message-ID: <16f2db7f-94fb-c027-d1b0-62e5e6ca57cd@oracle.com> On 9/14/2016 11:51 AM, Semyon Sadetsky wrote: > On 9/13/2016 9:03 PM, Alexandr Scherbatiy wrote: >> On 9/13/2016 8:49 PM, Semyon Sadetsky wrote: >>> On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote: >>>> On 9/13/2016 8:34 PM, Semyon Sadetsky wrote: >>>>> >>>>> On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> GTKPainter does not implement a lot of methods which can >>>>>>>>>>>>> be accessed by public API. Could you, please, explain, why >>>>>>>>>>>>> this specific method is more important than, for example, >>>>>>>>>>>>> paintToolBarContentBackground() or >>>>>>>>>>>>> paintToggleButtonBorder(), or all other unimplemented? >>>>>>>>>>>>> >>>>>>>>>>>>> In general, how do you separate public API methods of the >>>>>>>>>>>>> SynthPainter class into two sets: the first set that >>>>>>>>>>>>> *should be* over-riden and the second set of methods that >>>>>>>>>>>>> *should not be* overr-riden? Are there any systematic >>>>>>>>>>>>> criterium for that differentiation? >>>>>>>>>>>> All the same methods with different number of arguments >>>>>>>>>>>> which do not fall to overridden implementation should be >>>>>>>>>>>> overridden to provide proper implementation. >>>>>>>>>>> Where I can read about this rule for SynthPainter? And it >>>>>>>>>>> obviously is not true. >>>>>>>>>> This is a usual rule for public methods which can be used >>>>>>>>>> by an external application. >>>>>>>>>>> There are a lot of methods that are not over-riden in >>>>>>>>>>> GTKPainter. I even wrote an examples above. >>>>>>>>>> The SynthPainter.paintToolBarContentBackground(..., >>>>>>>>>> orientation) calls >>>>>>>>>> SynthPainter.paintToolBarContentBackground(...) without the >>>>>>>>>> orientation and the GTKPainter .paintToolBarContentBackground >>>>>>>>>> overrides the method without the orientation. So calls to >>>>>>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) >>>>>>>>>> falls down to the overriden method in GTKPainter. >>>>>>>>>> >>>>>>>>>> The same is for SynthPainter.paintProgressBarBackground(..., >>>>>>>>>> orientation) and paintScrollBarBackground(..., orientation) >>>>>>>>>> methods. >>>>>>>>>> >>>>>>>>>> The SynthPainter has only one paintToggleButtonBorder() method. >>>>>>>>> Interesting rule... I thought that more specific method >>>>>>>>> version may have different implementation. >>>>>>>> It was done for historical reason. For example before the fix >>>>>>>> JDK-5033822 "Synth ScrollBar paintTrack() dosn't support >>>>>>>> orientation" >>>>>>>> there was only paintScrollBarBackground() method without the >>>>>>>> orientation in the SynthPainter class. >>>>>>>> After the fix the paintScrollBarBackground() method with the >>>>>>>> orientation is added which default implementation just calls >>>>>>>> the same method without the orientation because old user's >>>>>>>> subclasses can override the method without the orientation an >>>>>>>> not be aware about new method version. >>>>>>>> >>>>>>>>> What would you say about paintSeparatorBackground() ? >>>>>>>>> It's (..., orientation) version is over-ridden while the >>>>>>>>> generic version is not over-ridden. >>>>>>>> I guess that it is just a bug. >>>>>>> Not sure. GTKPainter has never been providing a systematic API >>>>>>> from the beginning. It is not for an arbitrary external use, >>>>>>> because the resulting painting will be unpredictable. I >>>>>>> explained this in this thread many times. And even if I would >>>>>>> like to provide this useless method implementation >>>>>> It is a part of the public SynthPainter API and can be called >>>>>> by an external application. >>>>> I can be called without any predictable result. This is the >>>>> current state. It cannot be changed by the change you are >>>>> proposing to add. >>>> The result is described in the public method javadoc. >>>>>>> I were not able to do this because the orientation is a required >>>>>>> parameter to paint the GTK tab border. >>>>>> The overridden method without the orientation can just call the >>>>>> overridden method with orientation passing a default orientation >>>>>> value. >>>>> And what the default value is? It is not defined. >>>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html >>>> Creates a new horizontal separator: Constructor JSeparator(). >>> Sorry, I didn't get how the separator orientation is related to >>> tabbed pane border. >> https://docs.oracle.com/javase/7/docs/api/javax/swing/JTabbedPane.html#setTabPlacement(int) >> >> The default value, if not set, is SwingConstants.TOP. > It is a default for JTabbedPane but not for the LnF. JTabbedPane > always has some orientation and it is used in the painter. But I > cannot even imagine what should be painted if the GTK painter API is > called to paint TabbedPane without orientation and why. Because > orientation is mandatory in the corresponding gtk-lib call. The GTK L&F just tries to paint Swing components in the same way as native components. It is possible to get a default orientation of a native component to which the JTabbedPane corresponds to and use it. Thanks, Alexandr. > > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> The paintTabbedPaneTabBorder() without orientation should >>>>>>>>>>>>>> be implemented as well because it can be accessed by >>>>>>>>>>>>>> public API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>>>> What reason? Why it is not public? since I provided >>>>>>>>>>>>>>>>>> the code example >>>>>>>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>>>>>>> implement one of the method according to the spec and >>>>>>>>>>>>>>>> skip the same method for some unknown reason. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I still did not get why an overload method should >>>>>>>>>>>>>>>>>>> have the same behavior >>>>>>>>>>>>>>>>>>> as its associates. This is a brand new design >>>>>>>>>>>>>>>>>>> principle I've never heard >>>>>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ........... >>>>>>>>>>>>>>>>> That's nice... >>>>>>>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I still do not understand why the first method with >>>>>>>>>>>>>>>> default orientation is not implemented. >>>>>>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>>>>>>> because it is never used. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Tue Sep 20 00:31:31 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Sep 2016 03:31:31 +0300 Subject: [9] Review request for 8165234 Provide a way to not close toggle menu items on mouse click on component level In-Reply-To: <0abb68ee-e9c4-f005-eb63-ff035cd2ad3c@oracle.com> References: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> <57C9CC28.2040309@oracle.com> <30851302-18c4-b9f2-95bc-09bc0a433e11@oracle.com> <0abb68ee-e9c4-f005-eb63-ff035cd2ad3c@oracle.com> Message-ID: Looks fine. On 15.09.16 12:31, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165234/webrev.02 > > The closeOnMouseClick property is renamed to doNotCloseOnMouseClick > with the default false value. > The client property is queried in the first place. If it is not set > the L&F property value is used instead. > > Thanks, > Alexandr. > > On 9/14/2016 10:03 PM, Sergey Bylokhov wrote: >> Hi, Alexandr. >> I think we should double check how we operate on this property in case >> of custom L&F. Our code relies that this property is set to "true" by >> default. And if the custom look&feel, which knows nothing about it >> will be in use, then the code in SwingUtilities2 returns false. Is it >> expected? >> >> On 05.09.16 13:51, Alexandr Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8165234/webrev.01 >>> >>> On 9/2/2016 9:59 PM, Phil Race wrote: >>>> Seems fine except for a grammatical issue in the javadoc >>>> >>>> {@code true}. Setting the property to {@code false} either to >>>> {@literal L&F} >>>> >>>> I think you mean ".. either on the ..." >>> The typo "either to" is updated to "either on the". >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -phil. >>>> >>>> On 09/02/2016 05:30 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165234 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8165234/webrev.00 >>>>> >>>>> The fix JDK-8158566 adds "CheckBoxMenuItem.closeOnMouseClick" and >>>>> "RadioButtonMenuItem.closeOnMouseClick" properties >>>>> that control toogle menu items closing on mouse click on L&F level. >>>>> >>>>> The current fix allows to control menu items closing on a component >>>>> level. A toogle menu item >>>>> is not closed on mouse click if the corresponding property is set >>>>> to false either on the L&F or component level. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Tue Sep 20 07:40:16 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 10:40:16 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <16f2db7f-94fb-c027-d1b0-62e5e6ca57cd@oracle.com> References: <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> <0f57ef7f-a8ad-fef0-5be9-b71250c23022@oracle.com> <16f2db7f-94fb-c027-d1b0-62e5e6ca57cd@oracle.com> Message-ID: <59501abb-236f-e689-8a5e-7d43a4e0ac4a@oracle.com> On 9/20/2016 12:00 AM, Alexandr Scherbatiy wrote: > On 9/14/2016 11:51 AM, Semyon Sadetsky wrote: >> On 9/13/2016 9:03 PM, Alexandr Scherbatiy wrote: >>> On 9/13/2016 8:49 PM, Semyon Sadetsky wrote: >>>> On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote: >>>>> On 9/13/2016 8:34 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>>>>>>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>>>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>> GTKPainter does not implement a lot of methods which can >>>>>>>>>>>>>> be accessed by public API. Could you, please, explain, >>>>>>>>>>>>>> why this specific method is more important than, for >>>>>>>>>>>>>> example, paintToolBarContentBackground() or >>>>>>>>>>>>>> paintToggleButtonBorder(), or all other unimplemented? >>>>>>>>>>>>>> >>>>>>>>>>>>>> In general, how do you separate public API methods of the >>>>>>>>>>>>>> SynthPainter class into two sets: the first set that >>>>>>>>>>>>>> *should be* over-riden and the second set of methods that >>>>>>>>>>>>>> *should not be* overr-riden? Are there any systematic >>>>>>>>>>>>>> criterium for that differentiation? >>>>>>>>>>>>> All the same methods with different number of arguments >>>>>>>>>>>>> which do not fall to overridden implementation should be >>>>>>>>>>>>> overridden to provide proper implementation. >>>>>>>>>>>> Where I can read about this rule for SynthPainter? And it >>>>>>>>>>>> obviously is not true. >>>>>>>>>>> This is a usual rule for public methods which can be used >>>>>>>>>>> by an external application. >>>>>>>>>>>> There are a lot of methods that are not over-riden in >>>>>>>>>>>> GTKPainter. I even wrote an examples above. >>>>>>>>>>> The SynthPainter.paintToolBarContentBackground(..., >>>>>>>>>>> orientation) calls >>>>>>>>>>> SynthPainter.paintToolBarContentBackground(...) without the >>>>>>>>>>> orientation and the GTKPainter >>>>>>>>>>> .paintToolBarContentBackground overrides the method without >>>>>>>>>>> the orientation. So calls to >>>>>>>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) >>>>>>>>>>> falls down to the overriden method in GTKPainter. >>>>>>>>>>> >>>>>>>>>>> The same is for >>>>>>>>>>> SynthPainter.paintProgressBarBackground(..., orientation) >>>>>>>>>>> and paintScrollBarBackground(..., orientation) methods. >>>>>>>>>>> >>>>>>>>>>> The SynthPainter has only one paintToggleButtonBorder() >>>>>>>>>>> method. >>>>>>>>>> Interesting rule... I thought that more specific method >>>>>>>>>> version may have different implementation. >>>>>>>>> It was done for historical reason. For example before the >>>>>>>>> fix JDK-5033822 "Synth ScrollBar paintTrack() dosn't support >>>>>>>>> orientation" >>>>>>>>> there was only paintScrollBarBackground() method without the >>>>>>>>> orientation in the SynthPainter class. >>>>>>>>> After the fix the paintScrollBarBackground() method with the >>>>>>>>> orientation is added which default implementation just calls >>>>>>>>> the same method without the orientation because old user's >>>>>>>>> subclasses can override the method without the orientation an >>>>>>>>> not be aware about new method version. >>>>>>>>> >>>>>>>>>> What would you say about paintSeparatorBackground() ? >>>>>>>>>> It's (..., orientation) version is over-ridden while the >>>>>>>>>> generic version is not over-ridden. >>>>>>>>> I guess that it is just a bug. >>>>>>>> Not sure. GTKPainter has never been providing a systematic API >>>>>>>> from the beginning. It is not for an arbitrary external use, >>>>>>>> because the resulting painting will be unpredictable. I >>>>>>>> explained this in this thread many times. And even if I would >>>>>>>> like to provide this useless method implementation >>>>>>> It is a part of the public SynthPainter API and can be called >>>>>>> by an external application. >>>>>> I can be called without any predictable result. This is the >>>>>> current state. It cannot be changed by the change you are >>>>>> proposing to add. >>>>> The result is described in the public method javadoc. >>>>>>>> I were not able to do this because the orientation is a >>>>>>>> required parameter to paint the GTK tab border. >>>>>>> The overridden method without the orientation can just call >>>>>>> the overridden method with orientation passing a default >>>>>>> orientation value. >>>>>> And what the default value is? It is not defined. >>>>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html >>>>> Creates a new horizontal separator: Constructor JSeparator(). >>>> Sorry, I didn't get how the separator orientation is related to >>>> tabbed pane border. >>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JTabbedPane.html#setTabPlacement(int) >>> >>> The default value, if not set, is SwingConstants.TOP. >> It is a default for JTabbedPane but not for the LnF. JTabbedPane >> always has some orientation and it is used in the painter. But I >> cannot even imagine what should be painted if the GTK painter API is >> called to paint TabbedPane without orientation and why. Because >> orientation is mandatory in the corresponding gtk-lib call. > The GTK L&F just tries to paint Swing components in the same way as > native components. > It is possible to get a default orientation of a native component to > which the JTabbedPane corresponds to and use it. All orientation are equivalent and should correspond to the component position. Drawing a border for a tab with unknown orientation is senseless. --Semyon > > Thanks, > Alexandr. >> >> --Semyon >>> >>> Thanks, >>> Alexandr. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> The paintTabbedPaneTabBorder() without orientation >>>>>>>>>>>>>>> should be implemented as well because it can be accessed >>>>>>>>>>>>>>> by public API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>>>>> What reason? Why it is not public? since I provided >>>>>>>>>>>>>>>>>>> the code example >>>>>>>>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>>>>>>>> implement one of the method according to the spec and >>>>>>>>>>>>>>>>> skip the same method for some unknown reason. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I still did not get why an overload method should >>>>>>>>>>>>>>>>>>>> have the same behavior >>>>>>>>>>>>>>>>>>>> as its associates. This is a brand new design >>>>>>>>>>>>>>>>>>>> principle I've never heard >>>>>>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ........... >>>>>>>>>>>>>>>>>> That's nice... >>>>>>>>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I still do not understand why the first method with >>>>>>>>>>>>>>>>> default orientation is not implemented. >>>>>>>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>>>>>>>> because it is never used. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Tue Sep 20 10:56:28 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 13:56:28 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> References: <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> Message-ID: Hi Alexander, why in the TextUI class the new viewToModel2D and modelToView2D methods implementations fall-back to the deprecated ones? --Semyon On 12.09.2016 15:19, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all > public API changes: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api > > - @since 9 tag is added to new methods. > > Thanks, > Alexandr. > > On 9/10/2016 2:36 AM, Philip Race wrote: >> - * Returns the tab size set for the document, defaulting to 8. >> - * >> - * @implSpec This implementation calls {@link #getTabSize() >> getTabSize()}. >> - * >> - * @return the tab size >> - */ >> - protected float getFractionalTabSize() { >> - return getTabSize(); >> - } >> - >> >> >> It seems this was added only in 9. >> Since I think I remember that asking a question about it. >> I note it has no @since. Moot if you are really removing it but >> what has it to do with the rest of this change ? >> >> -phil. >> >> On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >>> public API changes: >>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >>> >>> - reflection is used to detect do methods with floating point API >>> need to be called. >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> >>>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> Alexander, did you consider possibility to check if method is >>>>>>> really over-riden then to use the old API? >>>>>>> >>>>>> Could you give a sample how it can be done? >>>>> I think it is possible to use a reflection to found the latest >>>>> overridden method which uses int coordinates and check does it has >>>>> a corresponding overridden method with floating point arguments. >>>>> But I doubt that it is a good solution. >>>> yes. You could use: >>>> useFloatingPointAPI = >>>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>>> ...).getDeclaringClass()); >>>> >>>> Otherwise, with high probability your new API will never be used. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> Hi Alexander, >>>>>>>>> >>>>>>>>> It is a good style to add a note recommending what to use >>>>>>>>> instead of the method which is being deprecated. >>>>>>>>> >>>>>>>> Could you review the updated public API there "replaced by" >>>>>>>> notes are added to the deprecated methods: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>>> >>>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>>> introduced and moreover is set to false by default. If the old >>>>>>>>> API is used then it doesn't matter which value it has because >>>>>>>>> the float values will receive ints. And for the new API I >>>>>>>>> would expect everything having the float precision, and it is >>>>>>>>> unclear what may be the reason to switch it off back to >>>>>>>>> integer. Especially if >>>>>>>>> >>>>>>>>> " This allows to draw text properly using graphics with scaled >>>>>>>>> transform." >>>>>>>>> >>>>>>>>> so an improper mode is the default? >>>>>>>>> >>>>>>>> This is has been discussed below. For example new >>>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int >>>>>>>> p1) with floating point coordinates is added to the PlainView >>>>>>>> which has the same method with int coordinates. Suppose someone >>>>>>>> has a custom password component which uses and old methods with >>>>>>>> int coordinates. >>>>>>>> -------- >>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>> >>>>>>>> @Override >>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>> // draw echo chars >>>>>>>> } >>>>>>>> } >>>>>>>> -------- >>>>>>>> >>>>>>>> If we start to call drawSelectedText() with floating point >>>>>>>> values the customization of old components will not be used and >>>>>>>> the CustomPasswordField from the example starts to show real >>>>>>>> text instead of echo chars. This is incompatible change with >>>>>>>> previous JDK releases. >>>>>>>> >>>>>>>> The solution is to switch to new floating point API only when >>>>>>>> it is known that a component properly overrides new methods >>>>>>>> with floating point arguments. After that the >>>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>>> >>>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>>> sure that drawSelectedText() methods with floating point >>>>>>>> arguments is overridden. So Swing standard text components are >>>>>>>> switched to use new floating point API. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>>> OK .. I do not know enough about how modelToView is used by >>>>>>>>>>> Swing >>>>>>>>>>> to know what is really needed here. Someone with a bit more >>>>>>>>>>> Swing >>>>>>>>>>> background needs to chime in. I was encouraged that the >>>>>>>>>>> *API* surface >>>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>>> webrev >>>>>>>>>>> but maybe that is because you did not include everything. >>>>>>>>>>> For example >>>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>>> PasswordView >>>>>>>>>>> since that is a public class would become part of the spec >>>>>>>>>>> .. would they not ? >>>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>>> >>>>>>>>>>> Put another way I was looking for what the content of the >>>>>>>>>>> CCC would be. >>>>>>>>>> Here is the updated version of the public API change which >>>>>>>>>> includes overridden deprecated methods: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>>> modelToView >>>>>>>>>>>>> That will just hold this up as the reasoning behind >>>>>>>>>>>>> needing those changes is not something >>>>>>>>>>>>> I have yet been able to convince myself about - even after >>>>>>>>>>>>> reading your last email. >>>>>>>>>>>> >>>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>>> p)) is not included in the current fix. I only moved the >>>>>>>>>>>> new methods JTextComponent.modelToView2D(int >>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret >>>>>>>>>>>> to this fix. These methods are used not only for caret but >>>>>>>>>>>> in other cases like mouse handling, text dragging and others. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>>> >>>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>>> - public >>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>>> are added >>>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API >>>>>>>>>>>>>> in standard Java text components >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point >>>>>>>>>>>>>>>> I am not sure what we are gaining >>>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It affects only the methods that the 3rd party code >>>>>>>>>>>>>>>> can over-ride >>>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal >>>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>>> Is there any other method that matters / is used in >>>>>>>>>>>>>>>> this way ? >>>>>>>>>>>>>>> I have found the following methods which relate to >>>>>>>>>>>>>>> text drawing, can be overridden and could have floating >>>>>>>>>>>>>>> point coordinates: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is also a method which relates to a caret position >>>>>>>>>>>>>>> in a text: >>>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they will >>>>>>>>>>>>>>>> get the JDK >>>>>>>>>>>>>>>> super-class version, thus losing any customisation they >>>>>>>>>>>>>>>> might have done >>>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and >>>>>>>>>>>>>>>> always call the float versions >>>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>>> method is: >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace at >>>>>>>>>>>>>>> the end >>>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>>> make calls >>>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Applications can rely on this behaviour and stopping to >>>>>>>>>>>>>>> call the drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>>>> methods with int coordinates will be incompatible change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>>> and enabled for standard Swing text component classes. >>>>>>>>>>>>>>>>> This has advantage that selection will work for text >>>>>>>>>>>>>>>>> component in users applications on HiDPI display. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But it still has the same problem. Applications >>>>>>>>>>>>>>>>> which use custom View classes needs to updated them to >>>>>>>>>>>>>>>>> implement corresponding text drawing methods with >>>>>>>>>>>>>>>>> floating point arguments and enable the floating point >>>>>>>>>>>>>>>>> API usage. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>>> By default it is false and all work as before. >>>>>>>>>>>>>>>>>>> The issue with selected text is reproduced. >>>>>>>>>>>>>>>>>>> An application with enabled property does not >>>>>>>>>>>>>>>>>>> have issue with the selected text but a user should >>>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Here is a proposed solution where new public >>>>>>>>>>>>>>>>>>> system property "javax.swing.floatingPoints.enabled" >>>>>>>>>>>>>>>>>>> is added: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the >>>>>>>>>>>>>>>>>>>>> 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() >>>>>>>>>>>>>>>>>>>>> method is 99.999992. >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N >>>>>>>>>>>>>>>>>>>>> * advance); >>>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects >>>>>>>>>>>>>>>>>>>>> the text selection code in Swing: >>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate >>>>>>>>>>>>>>>>>>>> the transformed coordinates are: >>>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but there >>>>>>>>>>>>>>>>>>>>>>> still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text related. >>>>>>>>>>>>>>>>>>>>>>> Can you take a look. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of the >>>>>>>>>>>>>>>>>>>>>> text. >>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, >>>>>>>>>>>>>>>>>>>>>> 0, index, >>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related to >>>>>>>>>>>>>>>>>>>>>>>> the fact that char width can be fractional in >>>>>>>>>>>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Sep 20 11:02:01 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 14:02:01 +0300 Subject: [9] Review request for 8163124 Add floating point API support to javax.swing.text.Caret In-Reply-To: <5840c3a5-a3d5-86d1-223a-fcb5aba73fb5@oracle.com> References: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> <5840c3a5-a3d5-86d1-223a-fcb5aba73fb5@oracle.com> Message-ID: Thanks, that helped. Did you think about changing the DefaultCaret class to use the new 2D API in case it is allowed for the component ? --Semyon On 19.09.2016 22:43, Alexandr Scherbatiy wrote: > > This is the known issue: JDK-8163175 PlainView.modelToView() method > should return Rectangle2D > It is included into the fix JDK-8156217 Selected text is shifted on > HiDPI display. > > You can apply the fix [1] JDK-8156217 to the JDK and try the proposed > sample. > I get the results [2] for scale 2x and [3] for scale 8x. > > [1] http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all > [2] > http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-2x.png > [3] > http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-8x.png > > Thanks, > Alexandr. > > On 9/15/2016 1:49 PM, Semyon Sadetsky wrote: >> Hi Alexander, >> >> Could you run the next test (with x8 scale, for example): >> >> public class New2dApiTest { >> public static void main(String[] args) { >> JTextArea jTextArea2d = new JTextArea("jksxbqhbxniiiaiiaawww") { >> @Override >> protected void paintComponent(Graphics g) { >> super.paintComponent(g); >> Graphics2D g2d = (Graphics2D) g; >> g2d.setColor(new Color(255, 0, 0, 50)); >> for (int i = 0; i < getText().length(); i++) { >> try { >> g2d.fill(modelToView2D(i)); >> } catch (BadLocationException e) { >> e.printStackTrace(); >> } >> } >> } >> }; >> JTextArea jTextArea = new JTextArea("jksxbqhbxniiiaiiaawww") { >> @Override >> protected void paintComponent(Graphics g) { >> super.paintComponent(g); >> Graphics2D g2d = (Graphics2D) g; >> g2d.setColor(new Color(0, 0, 255, 50)); >> for (int i = 0; i < getText().length(); i++) { >> try { >> g2d.fill(modelToView(i)); >> } catch (BadLocationException e) { >> e.printStackTrace(); >> } >> } >> } >> }; >> >> JFrame jFrame = new JFrame(); >> jFrame.getContentPane().setLayout(new GridLayout(2, 1)); >> jFrame.getContentPane().add(jTextArea2d); >> jFrame.getContentPane().add(jTextArea); >> jFrame.pack(); >> jFrame.setVisible(true); >> >> } >> } >> >> >> For some reason I cannot see the difference with the new and old API >> result. >> >> --Semyon >> >> >> On 04.08.2016 15:44, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8163124 >>> webrev: http://cr.openjdk.java.net/~alexsch/8163124/webrev.00 >>> >>> The text position can have floating point value on HiDPI display. >>> The Caret interface should be updated to allow use floating point >>> positions. >>> >>> The fix adds the following public API with floating point positions: >>> javax.swing.text.Caret.getMagicCaretPosition2D() >>> javax.swing.text.Caret.setMagicCaretPosition2D(Point2D p) >>> javax.swing.text.JTextComponent.modelToView2D(int pos) >>> javax.swing.text.JTextComponent.viewToModel2D(Point2D pt) >>> javax.swing.text.ParagraphView.getClosestPositionTo(int pos, >>> Position.Bias b, Shape a, int direction, Position.Bias[], int >>> rowIndex, float x) >>> >>> >>> The fix replaces >>> Caret.getMagicCaretPosition()/setMagicCaretPosition(Point p) to >>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D p) >>> in all places >>> except DefaultCaret because DefaultCaret extends Rectangle so its >>> coordinates always have int values. >>> I have filled a separated enhancement for this JDK-8163174 Add >>> DefaultCaret2D which supports floating point API >>> >>> To make a custom caret use floating point API it is also necessary >>> that PlainView.modelToView() returns a rectangle with floating point >>> values. It can be done after the fix >>> JDK-8156217 Selected text is shifted on HiDPI display >>> which implements Utilities.getTabbedTextWidth(Segment s, >>> FontMetrics metrics, float x, TabExpander e, int startOffset) method. >>> I have filled a separated issue on it: >>> JDK-8163175 PlainView.modelToView() method should return >>> Rectangle2D >>> >>> Thanks, >>> Alexandr. >> > From semyon.sadetsky at oracle.com Tue Sep 20 11:41:09 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 14:41:09 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> References: <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> Message-ID: Yet another question: Why the floating point API doesn't work for JTextPane? Also it doesn't work for JTextArea, JTextField and JTextPane if i18n is on. --Semyon On 12.09.2016 15:19, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all > public API changes: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api > > - @since 9 tag is added to new methods. > > Thanks, > Alexandr. > > On 9/10/2016 2:36 AM, Philip Race wrote: >> - * Returns the tab size set for the document, defaulting to 8. >> - * >> - * @implSpec This implementation calls {@link #getTabSize() >> getTabSize()}. >> - * >> - * @return the tab size >> - */ >> - protected float getFractionalTabSize() { >> - return getTabSize(); >> - } >> - >> >> >> It seems this was added only in 9. >> Since I think I remember that asking a question about it. >> I note it has no @since. Moot if you are really removing it but >> what has it to do with the rest of this change ? >> >> -phil. >> >> On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >>> public API changes: >>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >>> >>> - reflection is used to detect do methods with floating point API >>> need to be called. >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> >>>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> Alexander, did you consider possibility to check if method is >>>>>>> really over-riden then to use the old API? >>>>>>> >>>>>> Could you give a sample how it can be done? >>>>> I think it is possible to use a reflection to found the latest >>>>> overridden method which uses int coordinates and check does it has >>>>> a corresponding overridden method with floating point arguments. >>>>> But I doubt that it is a good solution. >>>> yes. You could use: >>>> useFloatingPointAPI = >>>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>>> ...).getDeclaringClass()); >>>> >>>> Otherwise, with high probability your new API will never be used. >>>> >>>> --Semyon >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> Hi Alexander, >>>>>>>>> >>>>>>>>> It is a good style to add a note recommending what to use >>>>>>>>> instead of the method which is being deprecated. >>>>>>>>> >>>>>>>> Could you review the updated public API there "replaced by" >>>>>>>> notes are added to the deprecated methods: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>>> >>>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>>> introduced and moreover is set to false by default. If the old >>>>>>>>> API is used then it doesn't matter which value it has because >>>>>>>>> the float values will receive ints. And for the new API I >>>>>>>>> would expect everything having the float precision, and it is >>>>>>>>> unclear what may be the reason to switch it off back to >>>>>>>>> integer. Especially if >>>>>>>>> >>>>>>>>> " This allows to draw text properly using graphics with scaled >>>>>>>>> transform." >>>>>>>>> >>>>>>>>> so an improper mode is the default? >>>>>>>>> >>>>>>>> This is has been discussed below. For example new >>>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int >>>>>>>> p1) with floating point coordinates is added to the PlainView >>>>>>>> which has the same method with int coordinates. Suppose someone >>>>>>>> has a custom password component which uses and old methods with >>>>>>>> int coordinates. >>>>>>>> -------- >>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>> >>>>>>>> @Override >>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>> // draw echo chars >>>>>>>> } >>>>>>>> } >>>>>>>> -------- >>>>>>>> >>>>>>>> If we start to call drawSelectedText() with floating point >>>>>>>> values the customization of old components will not be used and >>>>>>>> the CustomPasswordField from the example starts to show real >>>>>>>> text instead of echo chars. This is incompatible change with >>>>>>>> previous JDK releases. >>>>>>>> >>>>>>>> The solution is to switch to new floating point API only when >>>>>>>> it is known that a component properly overrides new methods >>>>>>>> with floating point arguments. After that the >>>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>>> >>>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>>> sure that drawSelectedText() methods with floating point >>>>>>>> arguments is overridden. So Swing standard text components are >>>>>>>> switched to use new floating point API. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>>> OK .. I do not know enough about how modelToView is used by >>>>>>>>>>> Swing >>>>>>>>>>> to know what is really needed here. Someone with a bit more >>>>>>>>>>> Swing >>>>>>>>>>> background needs to chime in. I was encouraged that the >>>>>>>>>>> *API* surface >>>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>>> webrev >>>>>>>>>>> but maybe that is because you did not include everything. >>>>>>>>>>> For example >>>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>>> PasswordView >>>>>>>>>>> since that is a public class would become part of the spec >>>>>>>>>>> .. would they not ? >>>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>>> >>>>>>>>>>> Put another way I was looking for what the content of the >>>>>>>>>>> CCC would be. >>>>>>>>>> Here is the updated version of the public API change which >>>>>>>>>> includes overridden deprecated methods: >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>>> modelToView >>>>>>>>>>>>> That will just hold this up as the reasoning behind >>>>>>>>>>>>> needing those changes is not something >>>>>>>>>>>>> I have yet been able to convince myself about - even after >>>>>>>>>>>>> reading your last email. >>>>>>>>>>>> >>>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>>> p)) is not included in the current fix. I only moved the >>>>>>>>>>>> new methods JTextComponent.modelToView2D(int >>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret >>>>>>>>>>>> to this fix. These methods are used not only for caret but >>>>>>>>>>>> in other cases like mouse handling, text dragging and others. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>>> >>>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>>> - public >>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>>> are added >>>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API >>>>>>>>>>>>>> in standard Java text components >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point >>>>>>>>>>>>>>>> I am not sure what we are gaining >>>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It affects only the methods that the 3rd party code >>>>>>>>>>>>>>>> can over-ride >>>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal >>>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>>> Is there any other method that matters / is used in >>>>>>>>>>>>>>>> this way ? >>>>>>>>>>>>>>> I have found the following methods which relate to >>>>>>>>>>>>>>> text drawing, can be overridden and could have floating >>>>>>>>>>>>>>> point coordinates: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is also a method which relates to a caret position >>>>>>>>>>>>>>> in a text: >>>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point p) >>>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they will >>>>>>>>>>>>>>>> get the JDK >>>>>>>>>>>>>>>> super-class version, thus losing any customisation they >>>>>>>>>>>>>>>> might have done >>>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class which >>>>>>>>>>>>>>> overrides drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>>>> methods and draws echo chars instead of text. >>>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and >>>>>>>>>>>>>>>> always call the float versions >>>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>>> method is: >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace at >>>>>>>>>>>>>>> the end >>>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>>> make calls >>>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>>> * {@code drawSelectedText} so that the way selected and >>>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Applications can rely on this behaviour and stopping to >>>>>>>>>>>>>>> call the drawSelectedText(...)/drawUnselectedText(...) >>>>>>>>>>>>>>> methods with int coordinates will be incompatible change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Is there a more fine grained way to detect programmer >>>>>>>>>>>>>>>>>> awareness or lack of awareness of the new methods? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here is a slightly updated version which adds public >>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>>> and enabled for standard Swing text component classes. >>>>>>>>>>>>>>>>> This has advantage that selection will work for text >>>>>>>>>>>>>>>>> component in users applications on HiDPI display. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But it still has the same problem. Applications >>>>>>>>>>>>>>>>> which use custom View classes needs to updated them to >>>>>>>>>>>>>>>>> implement corresponding text drawing methods with >>>>>>>>>>>>>>>>> floating point arguments and enable the floating point >>>>>>>>>>>>>>>>> API usage. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 Provide >>>>>>>>>>>>>>>>>>> public API for text related methods in SwingUtilities2 >>>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>>> By default it is false and all work as before. >>>>>>>>>>>>>>>>>>> The issue with selected text is reproduced. >>>>>>>>>>>>>>>>>>> An application with enabled property does not >>>>>>>>>>>>>>>>>>> have issue with the selected text but a user should >>>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>>> all methods with floating point values if he uses >>>>>>>>>>>>>>>>>>> corresponding methods with integer values. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Here is a proposed solution where new public >>>>>>>>>>>>>>>>>>> system property "javax.swing.floatingPoints.enabled" >>>>>>>>>>>>>>>>>>> is added: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and the >>>>>>>>>>>>>>>>>>>>> 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each glyph >>>>>>>>>>>>>>>>>>>>> advance in StandardGlyphVector.initPositions() >>>>>>>>>>>>>>>>>>>>> method is 99.999992. >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N >>>>>>>>>>>>>>>>>>>>> * advance); >>>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float position >>>>>>>>>>>>>>>>>>>>> 99.999998 is shifted one pixel left which affects >>>>>>>>>>>>>>>>>>>>> the text selection code in Swing: >>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero translate >>>>>>>>>>>>>>>>>>>> the transformed coordinates are: >>>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but there >>>>>>>>>>>>>>>>>>>>>>> still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text related. >>>>>>>>>>>>>>>>>>>>>>> Can you take a look. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of the >>>>>>>>>>>>>>>>>>>>>> text. >>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, >>>>>>>>>>>>>>>>>>>>>> 0, index, >>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related to >>>>>>>>>>>>>>>>>>>>>>>> the fact that char width can be fractional in >>>>>>>>>>>>>>>>>>>>>>>> user space. >>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Tue Sep 20 11:42:23 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 14:42:23 +0300 Subject: [9] Review request for 8165234 Provide a way to not close toggle menu items on mouse click on component level In-Reply-To: References: <584993b6-c552-c0e6-23dc-eff996c562ff@oracle.com> <57C9CC28.2040309@oracle.com> <30851302-18c4-b9f2-95bc-09bc0a433e11@oracle.com> <0abb68ee-e9c4-f005-eb63-ff035cd2ad3c@oracle.com> Message-ID: <80355223-24e9-e0ec-79b1-9783ba4c8cb4@oracle.com> +1 --Semyon On 20.09.2016 03:31, Sergey Bylokhov wrote: > Looks fine. > > On 15.09.16 12:31, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8165234/webrev.02 >> >> The closeOnMouseClick property is renamed to doNotCloseOnMouseClick >> with the default false value. >> The client property is queried in the first place. If it is not set >> the L&F property value is used instead. >> >> Thanks, >> Alexandr. >> >> On 9/14/2016 10:03 PM, Sergey Bylokhov wrote: >>> Hi, Alexandr. >>> I think we should double check how we operate on this property in case >>> of custom L&F. Our code relies that this property is set to "true" by >>> default. And if the custom look&feel, which knows nothing about it >>> will be in use, then the code in SwingUtilities2 returns false. Is it >>> expected? >>> >>> On 05.09.16 13:51, Alexandr Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8165234/webrev.01 >>>> >>>> On 9/2/2016 9:59 PM, Phil Race wrote: >>>>> Seems fine except for a grammatical issue in the javadoc >>>>> >>>>> {@code true}. Setting the property to {@code false} either to >>>>> {@literal L&F} >>>>> >>>>> I think you mean ".. either on the ..." >>>> The typo "either to" is updated to "either on the". >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> -phil. >>>>> >>>>> On 09/02/2016 05:30 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165234 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8165234/webrev.00 >>>>>> >>>>>> The fix JDK-8158566 adds "CheckBoxMenuItem.closeOnMouseClick" and >>>>>> "RadioButtonMenuItem.closeOnMouseClick" properties >>>>>> that control toogle menu items closing on mouse click on L&F >>>>>> level. >>>>>> >>>>>> The current fix allows to control menu items closing on a >>>>>> component >>>>>> level. A toogle menu item >>>>>> is not closed on mouse click if the corresponding property is set >>>>>> to false either on the L&F or component level. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Tue Sep 20 11:56:42 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 14:56:42 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> Message-ID: <080fb7f0-1260-ef44-bc3b-3faa1516b256@oracle.com> On 9/16/2016 11:22 AM, Andrej Golovnin wrote: > Hi Alexandr, > > thanks! It looks much better now. > >> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 > src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java > > 490 if(isScaledGraphics){ > > Spaces are missed between 'if' and '(' and between ')' and '{'. > > The empty lines 491, 520 and 522 are not needed and should be removed. > > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicArrowButton.java > > 240 if(SwingUtilities2.isScaledGraphics(g)){ > > Spaces are missed between 'if' and '(' and between ')' and '{'. > > 344 xPoints = new int[]{mid, mid + size, mid - size}; > > The Java Style Guidelines [1] don't mention this. But I think there > should be a space between 'new int[]' and '{'. The lines 345, 356, > 357, 366 and 367 are also affected. > > > src/java.desktop/share/classes/sun/swing/SwingUtilities2.java I will update the fix to properly format the code. > > 2041 public static boolean isScaledGraphics(Graphics g) { > > Have you considered to make this method a public API (move to the > SwingUtilities class), so that other Swing developers may use it too? Please, file an enhancement on this if you think it is worth to do: http://bugs.java.com Thanks, Alexandr. > >> [2] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >> [3] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png > Radio buttons are still not ideal. Have you considered to enable AA > when painting HiDPI icons? On the other hand I'm not sure, whether we > should invest a lot of time into making Windows Classic L&f to look > perfect on HiDPI screens. > > Best regards, > Andrej Golovnin > > [1] http://cr.openjdk.java.net/~alundblad/styleguide/ From alexandr.scherbatiy at oracle.com Tue Sep 20 11:58:54 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 14:58:54 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8165594/webrev.02 The code formatting issues are updated. On 9/14/2016 8:02 PM, Semyon Sadetsky wrote: > Hi Alexander, > > When I press the arrow button (for example in the "111" combo) several > times I can see artifacts. They are well seen in scale x4. I have filled an issue on it: JDK-8166368 JComboBox drawing has artifacts with Windows Classic L&F on HiDPI display https://bugs.openjdk.java.net/browse/JDK-8166368 Thanks, Alexandr. > > --Semyon > > > On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 >> >> - HiDPI icons are only drawn for scaled graphics. >> >> The screenshots [1], [2], and [3] show difference between icons >> drawing before and after the fix for scales 1x, 2x, and 4x. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png >> [2] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >> [3] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >> >> Thanks, >> Alexandr. >> >> On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >>> Hi Alexandr, >>> >>>> [1] >>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>>> >>> The icons do not look right to me. Take look at the top-left part of >>> the radio button. There is a white pixel between the shadow lines. And >>> in the selected state there should be a black circle. But instead it >>> is a square. The check sign of the checkbox is too thin. And the >>> arrows of the combobox and the vertical scroll bar should have a >>> single pixel at the top/bottom side. But now they have two pixels. >>> >>> It would be also nice to see a screen shot of the native Windows >>> components for comparison. >>> >>> Personally when I would make changes like that, then my code would >>> look like this: >>> >>> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >>> // use the old good code. >>> } else { >>> // use the new code >>> } >>> >>> Best regards, >>> Andrej Golovnin >>> >>>> [2] >>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>>> >>>> [3] >>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>>> >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >> > From alexandr.scherbatiy at oracle.com Tue Sep 20 12:04:35 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 15:04:35 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <080fb7f0-1260-ef44-bc3b-3faa1516b256@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <080fb7f0-1260-ef44-bc3b-3faa1516b256@oracle.com> Message-ID: <923cd11a-fd01-eccf-a682-9f77a75d4fe1@oracle.com> On 9/20/2016 2:56 PM, Alexandr Scherbatiy wrote: >> [2] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >> >> [3] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >> > Radio buttons are still not ideal. Have you considered to enable AA > when painting HiDPI icons? On the other hand I'm not sure, whether we > should invest a lot of time into making Windows Classic L&f to look > perfect on HiDPI screens. I think this all questions can be addressed to Java 2D which draws arcs and ovals. It also should be mention that 4 pixels for HiDPI display with scale 2x and 16 pixels on a display with scale 4x relate just to 1 pixel on non HiDPI display. Thanks, Alexandr. > > Best regards, > Andrej Golovnin -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 20 12:18:28 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 15:18:28 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: References: <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> Message-ID: <56b4f85c-c01f-a3bf-3c7d-93b25d0ba5e5@oracle.com> On 9/20/2016 1:56 PM, Semyon Sadetsky wrote: > > Hi Alexander, > > why in the TextUI class the new viewToModel2D and modelToView2D > methods implementations fall-back to the deprecated ones? > TextUI is a public abstract class. There is no way to add a new abstract method to it and keep a backward compatibility with previous version. So new viewToModel2D/modelToView2D methods should have an implementation. New code which starts to use new TextUI.viewToModel2D()/modelToView2D() methods can get a reference to old TextUI class implementation which does not override new viewToModel2D()/modelToView2D() methods but it expects that it they return a meaningful result. The only way to keep compatibility with old classes which extend TextUI class is that new viewToModel2D()/modelToView2D() methods fall back to old ones. Thanks, Alexandr. > --Semyon > > On 12.09.2016 15:19, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all >> public API changes: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api >> >> - @since 9 tag is added to new methods. >> >> Thanks, >> Alexandr. >> >> On 9/10/2016 2:36 AM, Philip Race wrote: >>> - * Returns the tab size set for the document, defaulting to 8. >>> - * >>> - * @implSpec This implementation calls {@link #getTabSize() >>> getTabSize()}. >>> - * >>> - * @return the tab size >>> - */ >>> - protected float getFractionalTabSize() { >>> - return getTabSize(); >>> - } >>> - >>> >>> >>> It seems this was added only in 9. >>> Since I think I remember that asking a question about it. >>> I note it has no @since. Moot if you are really removing it but >>> what has it to do with the rest of this change ? >>> >>> -phil. >>> >>> On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >>>> public API changes: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >>>> >>>> - reflection is used to detect do methods with floating point API >>>> need to be called. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> >>>>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> Alexander, did you consider possibility to check if method is >>>>>>>> really over-riden then to use the old API? >>>>>>>> >>>>>>> Could you give a sample how it can be done? >>>>>> I think it is possible to use a reflection to found the latest >>>>>> overridden method which uses int coordinates and check does it >>>>>> has a corresponding overridden method with floating point >>>>>> arguments. But I doubt that it is a good solution. >>>>> yes. You could use: >>>>> useFloatingPointAPI = >>>>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>>>> ...).getDeclaringClass()); >>>>> >>>>> Otherwise, with high probability your new API will never be used. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> Hi Alexander, >>>>>>>>>> >>>>>>>>>> It is a good style to add a note recommending what to use >>>>>>>>>> instead of the method which is being deprecated. >>>>>>>>>> >>>>>>>>> Could you review the updated public API there "replaced by" >>>>>>>>> notes are added to the deprecated methods: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>>>> >>>>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>>>> introduced and moreover is set to false by default. If the >>>>>>>>>> old API is used then it doesn't matter which value it has >>>>>>>>>> because the float values will receive ints. And for the new >>>>>>>>>> API I would expect everything having the float precision, and >>>>>>>>>> it is unclear what may be the reason to switch it off back to >>>>>>>>>> integer. Especially if >>>>>>>>>> >>>>>>>>>> " This allows to draw text properly using graphics with >>>>>>>>>> scaled transform." >>>>>>>>>> >>>>>>>>>> so an improper mode is the default? >>>>>>>>>> >>>>>>>>> This is has been discussed below. For example new >>>>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int >>>>>>>>> p1) with floating point coordinates is added to the PlainView >>>>>>>>> which has the same method with int coordinates. Suppose >>>>>>>>> someone has a custom password component which uses and old >>>>>>>>> methods with int coordinates. >>>>>>>>> -------- >>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>>> // draw echo chars >>>>>>>>> } >>>>>>>>> } >>>>>>>>> -------- >>>>>>>>> >>>>>>>>> If we start to call drawSelectedText() with floating point >>>>>>>>> values the customization of old components will not be used >>>>>>>>> and the CustomPasswordField from the example starts to show >>>>>>>>> real text instead of echo chars. This is incompatible change >>>>>>>>> with previous JDK releases. >>>>>>>>> >>>>>>>>> The solution is to switch to new floating point API only when >>>>>>>>> it is known that a component properly overrides new methods >>>>>>>>> with floating point arguments. After that the >>>>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>>>> >>>>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>>>> sure that drawSelectedText() methods with floating point >>>>>>>>> arguments is overridden. So Swing standard text components are >>>>>>>>> switched to use new floating point API. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>>>> OK .. I do not know enough about how modelToView is used by >>>>>>>>>>>> Swing >>>>>>>>>>>> to know what is really needed here. Someone with a bit more >>>>>>>>>>>> Swing >>>>>>>>>>>> background needs to chime in. I was encouraged that the >>>>>>>>>>>> *API* surface >>>>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>>>> webrev >>>>>>>>>>>> but maybe that is because you did not include everything. >>>>>>>>>>>> For example >>>>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>>>> PasswordView >>>>>>>>>>>> since that is a public class would become part of the spec >>>>>>>>>>>> .. would they not ? >>>>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>>>> >>>>>>>>>>>> Put another way I was looking for what the content of the >>>>>>>>>>>> CCC would be. >>>>>>>>>>> Here is the updated version of the public API change >>>>>>>>>>> which includes overridden deprecated methods: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>>>> modelToView >>>>>>>>>>>>>> That will just hold this up as the reasoning behind >>>>>>>>>>>>>> needing those changes is not something >>>>>>>>>>>>>> I have yet been able to convince myself about - even >>>>>>>>>>>>>> after reading your last email. >>>>>>>>>>>>> >>>>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>>>> p)) is not included in the current fix. I only moved the >>>>>>>>>>>>> new methods JTextComponent.modelToView2D(int >>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret >>>>>>>>>>>>> to this fix. These methods are used not only for caret but >>>>>>>>>>>>> in other cases like mouse handling, text dragging and others. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>>>> - public >>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>>>> are added >>>>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API >>>>>>>>>>>>>>> in standard Java text components >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point >>>>>>>>>>>>>>>>> I am not sure what we are gaining >>>>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It affects only the methods that the 3rd party code >>>>>>>>>>>>>>>>> can over-ride >>>>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal >>>>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>>>> Is there any other method that matters / is used in >>>>>>>>>>>>>>>>> this way ? >>>>>>>>>>>>>>>> I have found the following methods which relate to >>>>>>>>>>>>>>>> text drawing, can be overridden and could have floating >>>>>>>>>>>>>>>> point coordinates: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is also a method which relates to a caret >>>>>>>>>>>>>>>> position in a text: >>>>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point >>>>>>>>>>>>>>>> p) >>>>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they >>>>>>>>>>>>>>>>> will get the JDK >>>>>>>>>>>>>>>>> super-class version, thus losing any customisation >>>>>>>>>>>>>>>>> they might have done >>>>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class >>>>>>>>>>>>>>>> which overrides >>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>> and draws echo chars instead of text. >>>>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and >>>>>>>>>>>>>>>>> always call the float versions >>>>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>>>> method is: >>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace >>>>>>>>>>>>>>>> at the end >>>>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>>>> make calls >>>>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>>>> * {@code drawSelectedText} so that the way >>>>>>>>>>>>>>>> selected and >>>>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Applications can rely on this behaviour and stopping >>>>>>>>>>>>>>>> to call the >>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>> with int coordinates will be incompatible change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is there a more fine grained way to detect >>>>>>>>>>>>>>>>>>> programmer awareness or lack of awareness of the new >>>>>>>>>>>>>>>>>>> methods? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Here is a slightly updated version which adds >>>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>>>> and enabled for standard Swing text component >>>>>>>>>>>>>>>>>> classes. This has advantage that selection will work >>>>>>>>>>>>>>>>>> for text component in users applications on HiDPI >>>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But it still has the same problem. Applications >>>>>>>>>>>>>>>>>> which use custom View classes needs to updated them >>>>>>>>>>>>>>>>>> to implement corresponding text drawing methods with >>>>>>>>>>>>>>>>>> floating point arguments and enable the floating >>>>>>>>>>>>>>>>>> point API usage. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 >>>>>>>>>>>>>>>>>>>> Provide public API for text related methods in >>>>>>>>>>>>>>>>>>>> SwingUtilities2 >>>>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>>>> By default it is false and all work as before. >>>>>>>>>>>>>>>>>>>> The issue with selected text is reproduced. >>>>>>>>>>>>>>>>>>>> An application with enabled property does not >>>>>>>>>>>>>>>>>>>> have issue with the selected text but a user should >>>>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>>>> all methods with floating point values if he >>>>>>>>>>>>>>>>>>>> uses corresponding methods with integer values. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Here is a proposed solution where new public >>>>>>>>>>>>>>>>>>>> system property >>>>>>>>>>>>>>>>>>>> "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and >>>>>>>>>>>>>>>>>>>>>> the 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each >>>>>>>>>>>>>>>>>>>>>> glyph advance in >>>>>>>>>>>>>>>>>>>>>> StandardGlyphVector.initPositions() method is >>>>>>>>>>>>>>>>>>>>>> 99.999992. >>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N >>>>>>>>>>>>>>>>>>>>>> * advance); >>>>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float >>>>>>>>>>>>>>>>>>>>>> position 99.999998 is shifted one pixel left >>>>>>>>>>>>>>>>>>>>>> which affects the text selection code in Swing: >>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero >>>>>>>>>>>>>>>>>>>>> translate the transformed coordinates are: >>>>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but >>>>>>>>>>>>>>>>>>>>>>>> there still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text >>>>>>>>>>>>>>>>>>>>>>>> related. Can you take a look. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of >>>>>>>>>>>>>>>>>>>>>>> the text. >>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related >>>>>>>>>>>>>>>>>>>>>>>>> to the fact that char width can be fractional >>>>>>>>>>>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 20 12:22:39 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 15:22:39 +0300 Subject: [9] Review request for 8163124 Add floating point API support to javax.swing.text.Caret In-Reply-To: References: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> <5840c3a5-a3d5-86d1-223a-fcb5aba73fb5@oracle.com> Message-ID: <7841b852-474d-7cdc-b324-8d73d25b63e0@oracle.com> On 9/20/2016 2:02 PM, Semyon Sadetsky wrote: > Thanks, that helped. > > Did you think about changing the DefaultCaret class to use the new 2D > API in case it is allowed for the component ? DefaultCaret class extends Rectangle so it always uses int coordinates. I filled an enhancement to support new floating point version of the caret. JDK-8163174 Add DefaultCaret2D which supports floating point API https://bugs.openjdk.java.net/browse/JDK-8163174 Thanks, Alexandr. > > --Semyon > > > On 19.09.2016 22:43, Alexandr Scherbatiy wrote: >> >> This is the known issue: JDK-8163175 PlainView.modelToView() method >> should return Rectangle2D >> It is included into the fix JDK-8156217 Selected text is shifted on >> HiDPI display. >> >> You can apply the fix [1] JDK-8156217 to the JDK and try the proposed >> sample. >> I get the results [2] for scale 2x and [3] for scale 8x. >> >> [1] http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all >> [2] >> http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-2x.png >> [3] >> http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-8x.png >> >> Thanks, >> Alexandr. >> >> On 9/15/2016 1:49 PM, Semyon Sadetsky wrote: >>> Hi Alexander, >>> >>> Could you run the next test (with x8 scale, for example): >>> >>> public class New2dApiTest { >>> public static void main(String[] args) { >>> JTextArea jTextArea2d = new >>> JTextArea("jksxbqhbxniiiaiiaawww") { >>> @Override >>> protected void paintComponent(Graphics g) { >>> super.paintComponent(g); >>> Graphics2D g2d = (Graphics2D) g; >>> g2d.setColor(new Color(255, 0, 0, 50)); >>> for (int i = 0; i < getText().length(); i++) { >>> try { >>> g2d.fill(modelToView2D(i)); >>> } catch (BadLocationException e) { >>> e.printStackTrace(); >>> } >>> } >>> } >>> }; >>> JTextArea jTextArea = new JTextArea("jksxbqhbxniiiaiiaawww") { >>> @Override >>> protected void paintComponent(Graphics g) { >>> super.paintComponent(g); >>> Graphics2D g2d = (Graphics2D) g; >>> g2d.setColor(new Color(0, 0, 255, 50)); >>> for (int i = 0; i < getText().length(); i++) { >>> try { >>> g2d.fill(modelToView(i)); >>> } catch (BadLocationException e) { >>> e.printStackTrace(); >>> } >>> } >>> } >>> }; >>> >>> JFrame jFrame = new JFrame(); >>> jFrame.getContentPane().setLayout(new GridLayout(2, 1)); >>> jFrame.getContentPane().add(jTextArea2d); >>> jFrame.getContentPane().add(jTextArea); >>> jFrame.pack(); >>> jFrame.setVisible(true); >>> >>> } >>> } >>> >>> >>> For some reason I cannot see the difference with the new and old API >>> result. >>> >>> --Semyon >>> >>> >>> On 04.08.2016 15:44, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8163124 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8163124/webrev.00 >>>> >>>> The text position can have floating point value on HiDPI display. >>>> The Caret interface should be updated to allow use floating point >>>> positions. >>>> >>>> The fix adds the following public API with floating point positions: >>>> javax.swing.text.Caret.getMagicCaretPosition2D() >>>> javax.swing.text.Caret.setMagicCaretPosition2D(Point2D p) >>>> javax.swing.text.JTextComponent.modelToView2D(int pos) >>>> javax.swing.text.JTextComponent.viewToModel2D(Point2D pt) >>>> javax.swing.text.ParagraphView.getClosestPositionTo(int pos, >>>> Position.Bias b, Shape a, int direction, Position.Bias[], int >>>> rowIndex, float x) >>>> >>>> >>>> The fix replaces >>>> Caret.getMagicCaretPosition()/setMagicCaretPosition(Point p) to >>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D p) >>>> in all places >>>> except DefaultCaret because DefaultCaret extends Rectangle so its >>>> coordinates always have int values. >>>> I have filled a separated enhancement for this JDK-8163174 Add >>>> DefaultCaret2D which supports floating point API >>>> >>>> To make a custom caret use floating point API it is also >>>> necessary that PlainView.modelToView() returns a rectangle with >>>> floating point values. It can be done after the fix >>>> JDK-8156217 Selected text is shifted on HiDPI display >>>> which implements Utilities.getTabbedTextWidth(Segment s, >>>> FontMetrics metrics, float x, TabExpander e, int startOffset) method. >>>> I have filled a separated issue on it: >>>> JDK-8163175 PlainView.modelToView() method should return >>>> Rectangle2D >>>> >>>> Thanks, >>>> Alexandr. >>> >> > From semyon.sadetsky at oracle.com Tue Sep 20 13:37:06 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 16:37:06 +0300 Subject: [9] Review request for 8163124 Add floating point API support to javax.swing.text.Caret In-Reply-To: <7841b852-474d-7cdc-b324-8d73d25b63e0@oracle.com> References: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> <5840c3a5-a3d5-86d1-223a-fcb5aba73fb5@oracle.com> <7841b852-474d-7cdc-b324-8d73d25b63e0@oracle.com> Message-ID: <1197b61c-2cbe-a918-5c87-27ba4bfa2118@oracle.com> On 9/20/2016 3:22 PM, Alexandr Scherbatiy wrote: > On 9/20/2016 2:02 PM, Semyon Sadetsky wrote: >> Thanks, that helped. >> >> Did you think about changing the DefaultCaret class to use the new 2D >> API in case it is allowed for the component ? > DefaultCaret class extends Rectangle so it always uses int coordinates. Are you sure that using Rectangle2D is necessary for this? The rectangle which the DefaultCaret presents is only a bounds for repainting. But actual caret paint method may draw any shape. Since repaint() method is not receiving floating point coordinates the DefaultCaret don't need to extend Rectangle2D. --Semyon > I filled an enhancement to support new floating point version of the > caret. > JDK-8163174 Add DefaultCaret2D which supports floating point API > https://bugs.openjdk.java.net/browse/JDK-8163174 > > Thanks, > Alexandr. > >> >> --Semyon >> >> >> On 19.09.2016 22:43, Alexandr Scherbatiy wrote: >>> >>> This is the known issue: JDK-8163175 PlainView.modelToView() method >>> should return Rectangle2D >>> It is included into the fix JDK-8156217 Selected text is shifted on >>> HiDPI display. >>> >>> You can apply the fix [1] JDK-8156217 to the JDK and try the >>> proposed sample. >>> I get the results [2] for scale 2x and [3] for scale 8x. >>> >>> [1] http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-2x.png >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8156217/screenshots/model-to-view-8x.png >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/15/2016 1:49 PM, Semyon Sadetsky wrote: >>>> Hi Alexander, >>>> >>>> Could you run the next test (with x8 scale, for example): >>>> >>>> public class New2dApiTest { >>>> public static void main(String[] args) { >>>> JTextArea jTextArea2d = new >>>> JTextArea("jksxbqhbxniiiaiiaawww") { >>>> @Override >>>> protected void paintComponent(Graphics g) { >>>> super.paintComponent(g); >>>> Graphics2D g2d = (Graphics2D) g; >>>> g2d.setColor(new Color(255, 0, 0, 50)); >>>> for (int i = 0; i < getText().length(); i++) { >>>> try { >>>> g2d.fill(modelToView2D(i)); >>>> } catch (BadLocationException e) { >>>> e.printStackTrace(); >>>> } >>>> } >>>> } >>>> }; >>>> JTextArea jTextArea = new JTextArea("jksxbqhbxniiiaiiaawww") { >>>> @Override >>>> protected void paintComponent(Graphics g) { >>>> super.paintComponent(g); >>>> Graphics2D g2d = (Graphics2D) g; >>>> g2d.setColor(new Color(0, 0, 255, 50)); >>>> for (int i = 0; i < getText().length(); i++) { >>>> try { >>>> g2d.fill(modelToView(i)); >>>> } catch (BadLocationException e) { >>>> e.printStackTrace(); >>>> } >>>> } >>>> } >>>> }; >>>> >>>> JFrame jFrame = new JFrame(); >>>> jFrame.getContentPane().setLayout(new GridLayout(2, 1)); >>>> jFrame.getContentPane().add(jTextArea2d); >>>> jFrame.getContentPane().add(jTextArea); >>>> jFrame.pack(); >>>> jFrame.setVisible(true); >>>> >>>> } >>>> } >>>> >>>> >>>> For some reason I cannot see the difference with the new and old >>>> API result. >>>> >>>> --Semyon >>>> >>>> >>>> On 04.08.2016 15:44, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8163124 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8163124/webrev.00 >>>>> >>>>> The text position can have floating point value on HiDPI >>>>> display. The Caret interface should be updated to allow use >>>>> floating point positions. >>>>> >>>>> The fix adds the following public API with floating point >>>>> positions: >>>>> javax.swing.text.Caret.getMagicCaretPosition2D() >>>>> javax.swing.text.Caret.setMagicCaretPosition2D(Point2D p) >>>>> javax.swing.text.JTextComponent.modelToView2D(int pos) >>>>> javax.swing.text.JTextComponent.viewToModel2D(Point2D pt) >>>>> javax.swing.text.ParagraphView.getClosestPositionTo(int pos, >>>>> Position.Bias b, Shape a, int direction, Position.Bias[], int >>>>> rowIndex, float x) >>>>> >>>>> >>>>> The fix replaces >>>>> Caret.getMagicCaretPosition()/setMagicCaretPosition(Point p) to >>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D p) >>>>> in all places >>>>> except DefaultCaret because DefaultCaret extends Rectangle so >>>>> its coordinates always have int values. >>>>> I have filled a separated enhancement for this JDK-8163174 Add >>>>> DefaultCaret2D which supports floating point API >>>>> >>>>> To make a custom caret use floating point API it is also >>>>> necessary that PlainView.modelToView() returns a rectangle with >>>>> floating point values. It can be done after the fix >>>>> JDK-8156217 Selected text is shifted on HiDPI display >>>>> which implements Utilities.getTabbedTextWidth(Segment s, >>>>> FontMetrics metrics, float x, TabExpander e, int startOffset) method. >>>>> I have filled a separated issue on it: >>>>> JDK-8163175 PlainView.modelToView() method should return >>>>> Rectangle2D >>>>> >>>>> Thanks, >>>>> Alexandr. >>>> >>> >> > From semyon.sadetsky at oracle.com Tue Sep 20 14:34:01 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 17:34:01 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> Message-ID: <803bb585-83f3-9a31-2011-6a2195da7ad5@oracle.com> I would rewrite the method that draws triangle to simplify it: private void paintScaledTriangle(Graphics g, double x, double y, double size, int direction, boolean isEnabled) { size = Math.max(size , 2); Path2D.Double path = new Path2D.Double(); path.moveTo(-size, size/2); path.lineTo(size, size/2); path.lineTo(0, -size/2); path.closePath(); AffineTransform affineTransform = new AffineTransform(); affineTransform.rotate(Math.PI * (direction - 1) / 4 ); path.transform(affineTransform); Graphics2D g2d = (Graphics2D) g; g2d.translate(x + size / 2. - 1, y + size / 2); Color oldColor = g.getColor(); if (!isEnabled) { g2d.translate(1, 0); g2d.setColor(highlight); g2d.fill(path); g2d.translate(-1, 0); } g2d.setColor(isEnabled ? darkShadow : shadow); g2d.fill(path); g2d.translate( - x - size / 2. + 1, - y - size / 2); g2d.setColor(oldColor); } I'm suggesting to make the paintTriangle() method accept floating point coordinates to get more precise location and size for the scaled version. Optionally, 2D AA hints can be added to get better appearance for scales 1.25, 1.5, 1.75. --Semyon On 9/20/2016 2:58 PM, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165594/webrev.02 > > The code formatting issues are updated. > > On 9/14/2016 8:02 PM, Semyon Sadetsky wrote: >> Hi Alexander, >> >> When I press the arrow button (for example in the "111" combo) >> several times I can see artifacts. They are well seen in scale x4. > I have filled an issue on it: JDK-8166368 JComboBox drawing has > artifacts with Windows Classic L&F on HiDPI display > https://bugs.openjdk.java.net/browse/JDK-8166368 > > Thanks, > Alexandr. > >> >> --Semyon >> >> >> On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 >>> >>> - HiDPI icons are only drawn for scaled graphics. >>> >>> The screenshots [1], [2], and [3] show difference between icons >>> drawing before and after the fix for scales 1x, 2x, and 4x. >>> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >>>> Hi Alexandr, >>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>>>> >>>> The icons do not look right to me. Take look at the top-left part of >>>> the radio button. There is a white pixel between the shadow lines. And >>>> in the selected state there should be a black circle. But instead it >>>> is a square. The check sign of the checkbox is too thin. And the >>>> arrows of the combobox and the vertical scroll bar should have a >>>> single pixel at the top/bottom side. But now they have two pixels. >>>> >>>> It would be also nice to see a screen shot of the native Windows >>>> components for comparison. >>>> >>>> Personally when I would make changes like that, then my code would >>>> look like this: >>>> >>>> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >>>> // use the old good code. >>>> } else { >>>> // use the new code >>>> } >>>> >>>> Best regards, >>>> Andrej Golovnin >>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>>>> >>>>> [3] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>> >> > From semyon.sadetsky at oracle.com Tue Sep 20 14:35:30 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 20 Sep 2016 17:35:30 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <923cd11a-fd01-eccf-a682-9f77a75d4fe1@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <080fb7f0-1260-ef44-bc3b-3faa1516b256@oracle.com> <923cd11a-fd01-eccf-a682-9f77a75d4fe1@oracle.com> Message-ID: <48c5a9ff-c03f-b879-dbbf-cc9aede3fb6b@oracle.com> On 9/20/2016 3:04 PM, Alexandr Scherbatiy wrote: > > On 9/20/2016 2:56 PM, Alexandr Scherbatiy wrote: > >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>> >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >>> >> Radio buttons are still not ideal. Have you considered to enable AA >> when painting HiDPI icons? On the other hand I'm not sure, whether we >> should invest a lot of time into making Windows Classic L&f to look >> perfect on HiDPI screens. > I think this all questions can be addressed to Java 2D which draws > arcs and ovals. It also should be mention that 4 pixels for HiDPI > display with scale 2x and 16 pixels on a display with scale 4x relate > just to 1 pixel on non HiDPI display. You could add AA hint to make circles/ovals looking good. --Semyon > > Thanks, > Alexandr. > >> >> Best regards, >> Andrej Golovnin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Sep 20 14:48:54 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 17:48:54 +0300 Subject: OpenJDK JDK-7067885 code changes for community review In-Reply-To: <549b7026-cbf3-8bc3-a593-561699431554@oracle.com> References: <549b7026-cbf3-8bc3-a593-561699431554@oracle.com> Message-ID: <88e9828b-9609-f33e-78e8-ad31361dc828@oracle.com> Hello Alok, Is it possible to update the line where File.exists() is used just converting the file to a Path and using java.nio.exists() check? Thanks, Alexandr. On 9/16/2016 1:20 PM, Alexey Ivanov wrote: > Hi Alok, > > This change should be discussed on swing-dev mailing list because you > modify behavior of javax.swing.JFileChooser, and on core-libs-dev > because you also modify java.io.File. > > I agree with Alan, using the new API appears to be a better > alternative than changing java.io.File. > > > Regards, > Alexey > > On 12.09.2016 19:08, Alan Bateman wrote: >> Best to follow-up on swing-dev as I assume the right thing is to >> update JFileChooser rather than changing java.io.File to be mutable. >> You did acknowledge near the end of your mail that the new file >> system API supports sym links so it may be that JFileChooser could >> use that. >> >> -Alan >> >> >> On 12/09/2016 08:41, Sharma, Alok Kumar (OSTL) wrote: >>> Following is the fix for JDK-7067885. I am not sure which mailing ID >>> to post this. >>> >>> Bug: FileChooser does not display soft link name if link is to >>> nonexistent file/directory >>> https://bugs.openjdk.java.net/browse/JDK-7067885 >>> >>> This bug is unassigned. Can someone please look into these changes >>> and get back to me? Explanation of fix is at the end of the source >>> code diff. >>> >>> Mercurial diff for source change: >>> ------------------------------------------------------------------- >>> diff -r 021369229cfd src/java.base/share/classes/java/io/File.java >>> --- a/src/java.base/share/classes/java/io/File.java Tue Sep 06 >>> 13:09:29 2016 -0400 >>> +++ b/src/java.base/share/classes/java/io/File.java Mon Sep 12 >>> 11:27:07 2016 +0530 >>> @@ -164,6 +164,27 @@ >>> private final String path; >>> >>> /** >>> + * The flag indicates whether to follow the symlink. >>> + */ >>> + private boolean follow_link = true; >>> + >>> + /** >>> + * Sets the follow_link of file. >>> + * description: Sets follow_link on or off. >>> + * @param follow_link the value that determines whether to >>> follow the symlink or not. >>> + * TRUE: file.io.exists() checks the file existence using >>> stat() which follows the symlink. >>> + * >>> + * FALSE: file.io.exists() checks the file existence using >>> lstat() if stat() fails to retrieve >>> + * the file info. lstat() if file is a symbolic link, then >>> it returns information >>> + * about the link itself. >>> + * @return Returns ZERO at success >>> + */ >>> + public int set_follow_link(boolean follow_link) { >>> + this.follow_link=follow_link; >>> + return 0; >>> + } >>> + >>> + /** >>> * Enum type that indicates the status of a file path. >>> */ >>> private static enum PathStatus { INVALID, CHECKED }; >>> diff -r 021369229cfd >>> src/java.base/unix/native/libjava/UnixFileSystem_md.c >>> --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Tue Sep >>> 06 13:09:29 2016 -0400 >>> +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon Sep >>> 12 11:27:07 2016 +0530 >>> @@ -51,6 +51,7 @@ >>> #define dirent64 dirent >>> #define readdir64_r readdir_r >>> #define stat64 stat >>> +#define lstat64 lstat >>> #ifndef MACOSX >>> #define statvfs64 statvfs >>> #endif >>> @@ -62,6 +63,7 @@ >>> jfieldID path; >>> } ids; >>> >>> +jfieldID ufs_follow_link; >>> >>> JNIEXPORT void JNICALL >>> Java_java_io_UnixFileSystem_initIDs(JNIEnv *env, jclass cls) >>> @@ -70,6 +72,8 @@ >>> if (!fileClass) return; >>> ids.path = (*env)->GetFieldID(env, fileClass, >>> "path", "Ljava/lang/String;"); >>> + ufs_follow_link = (*env)->GetFieldID(env, fileClass, >>> + "follow_link", "Z"); >>> } >>> >>> /* -- Path operations -- */ >>> @@ -113,20 +117,42 @@ >>> return JNI_FALSE; >>> } >>> >>> +static jboolean >>> +lstatMode(const char *path, int *mode) >>> +{ >>> + struct stat64 sb; >>> + if (lstat64(path, &sb) == 0) { >>> + *mode = sb.st_mode; >>> + return JNI_TRUE; >>> + } >>> + return JNI_FALSE; >>> +} >>> >>> JNIEXPORT jint JNICALL >>> Java_java_io_UnixFileSystem_getBooleanAttributes0(JNIEnv *env, >>> jobject this, >>> jobject file) >>> { >>> jint rv = 0; >>> + jint follow_link = 0; >>> >>> WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) { >>> int mode; >>> - if (statMode(path, &mode)) { >>> - int fmt = mode & S_IFMT; >>> - rv = (jint) (java_io_FileSystem_BA_EXISTS >>> - | ((fmt == S_IFREG) ? >>> java_io_FileSystem_BA_REGULAR : 0) >>> - | ((fmt == S_IFDIR) ? >>> java_io_FileSystem_BA_DIRECTORY : 0)); >>> + follow_link = (*env)->GetBooleanField(env, file, >>> ufs_follow_link); >>> + if ( follow_link ) { >>> + if (statMode(path, &mode)) { >>> + int fmt = mode & S_IFMT; >>> + rv = (jint) (java_io_FileSystem_BA_EXISTS >>> + | ((fmt == S_IFREG) ? >>> java_io_FileSystem_BA_REGULAR : 0) >>> + | ((fmt == S_IFDIR) ? >>> java_io_FileSystem_BA_DIRECTORY : 0)); >>> + } >>> + } >>> + else { >>> + if (lstatMode(path, &mode)) { >>> + int fmt = mode & S_IFMT; >>> + rv = (jint) (java_io_FileSystem_BA_EXISTS >>> + | ((fmt == S_IFREG) ? >>> java_io_FileSystem_BA_REGULAR : 0) >>> + | ((fmt == S_IFDIR) ? >>> java_io_FileSystem_BA_DIRECTORY : 0)); >>> + } >>> } >>> } END_PLATFORM_STRING(env, path); >>> return rv; >>> diff -r 021369229cfd >>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>> --- >>> a/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>> Tue Sep 06 13:09:29 2016 -0400 >>> +++ >>> b/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>> Mon Sep 12 11:27:07 2016 +0530 >>> @@ -521,6 +521,7 @@ >>> f = createFileSystemRoot(f); >>> } >>> try { >>> + f.set_follow_link(false); >>> f = ShellFolder.getShellFolder(f); >>> } catch (FileNotFoundException e) { >>> // Not a valid file (wouldn't show in native >>> file chooser) >>> ------------------------------------------ >>> >>> Below is the explanation for fix. >>> >>> Problem description: >>> FileChooser behavior when there is a soft link to a non-existent >>> file/directory. >>> Soft link to be displayed with an error/exception when attempt is >>> made to >>> open it. Instead the soft link name is not displayed in the file >>> chooser. >>> >>> Analysis: >>> JFileChooser() internally uses java.io.exists() to check whether >>> file exists. >>> In this scenario JFileChooser() checks dangling symlink existence >>> using java.io.exists(). >>> java.io.exists() api does not handle dangling symlink and returns >>> false. >>> >>> JFileChooser() expects exists() api to return true for dangling >>> symlink but, java.io.exists() returns false. >>> >>> We see that there are two exists() apis in JAVA java.io.exists() and >>> java.nio.exists(). >>> >>> java.nio.exists() handles dangling symlinks it accepts second >>> argument link option which >>> determines whether to follow the link or not and returns true for >>> dangling symlinks. >>> java.io.exists() follows the symlink and returns false if target >>> file doesn't exist. >>> >>> We have enhanced the java.io.exists() api to return true if it is a >>> dangling symlink. >>> >>> Changes in code: >>> >>> New variable "follow_link" is introduced in >>> "jdk/src/java.base/share/classes/java/io/File.java", we check for >>> this flag in exists() code >>> if its set then we handle symlinks. In case of dangling symlink >>> java.io.exists() api checks file existence >>> symlink itself not the target file and returns true. >>> >>> JFileChooser() issue (JDK-7067885) gets resolved with these changes. >>> >>> Testing: >>> I have covered the testing for the below apis. >>> Jfilechooser >>> getShellFolder >>> FileSystemView >>> and ran /openjdk9/jdk/test/javax/swing/JFileChooser/* tests. >>> >> > From Sergey.Bylokhov at oracle.com Tue Sep 20 15:24:45 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Sep 2016 18:24:45 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <923cd11a-fd01-eccf-a682-9f77a75d4fe1@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <080fb7f0-1260-ef44-bc3b-3faa1516b256@oracle.com> <923cd11a-fd01-eccf-a682-9f77a75d4fe1@oracle.com> Message-ID: <6b5d315a-79c5-ffae-3cb1-4e983b39954f@oracle.com> On 20.09.16 15:04, Alexandr Scherbatiy wrote: > On 9/20/2016 2:56 PM, Alexandr Scherbatiy wrote: > >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>> >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png Not sure but it looks like the triangles in the scroll bars are shifted a little bit(at least combobox(which also is not in the center) looks better). >>> >> Radio buttons are still not ideal. Have you considered to enable AA >> when painting HiDPI icons? On the other hand I'm not sure, whether we >> should invest a lot of time into making Windows Classic L&f to look >> perfect on HiDPI screens. > I think this all questions can be addressed to Java 2D which draws > arcs and ovals. It also should be mention that 4 pixels for HiDPI > display with scale 2x and 16 pixels on a display with scale 4x relate > just to 1 pixel on non HiDPI display. > > Thanks, > Alexandr. > >> >> Best regards, >> Andrej Golovnin > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Tue Sep 20 16:35:45 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 20 Sep 2016 19:35:45 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <803bb585-83f3-9a31-2011-6a2195da7ad5@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> <803bb585-83f3-9a31-2011-6a2195da7ad5@oracle.com> Message-ID: <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> Thank you for the suggested code. Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8165594/webrev.04 - the provided method is used to draw triangles in BasicArrowButton class - shift to one pixel right is added for the triangles drawing - AA rendering hint is set to draw a radio button Screenshots [1] and [2] shows difference between icons drawing before and after the fix for scales 2x and 4x. [1] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_03.png [2] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_03.png Thanks, Alexandr. On 9/20/2016 5:34 PM, Semyon Sadetsky wrote: > I would rewrite the method that draws triangle to simplify it: > > private void paintScaledTriangle(Graphics g, double x, double y, > double size, > int direction, boolean isEnabled) { > size = Math.max(size , 2); > Path2D.Double path = new Path2D.Double(); > path.moveTo(-size, size/2); > path.lineTo(size, size/2); > path.lineTo(0, -size/2); > path.closePath(); > AffineTransform affineTransform = new AffineTransform(); > affineTransform.rotate(Math.PI * (direction - 1) / 4 ); > path.transform(affineTransform); > > Graphics2D g2d = (Graphics2D) g; > g2d.translate(x + size / 2. - 1, y + size / 2); > Color oldColor = g.getColor(); > if (!isEnabled) { > g2d.translate(1, 0); > g2d.setColor(highlight); > g2d.fill(path); > g2d.translate(-1, 0); > } > g2d.setColor(isEnabled ? darkShadow : shadow); > g2d.fill(path); > g2d.translate( - x - size / 2. + 1, - y - size / 2); > g2d.setColor(oldColor); > } > > I'm suggesting to make the paintTriangle() method accept floating > point coordinates to get more precise location and size for the scaled > version. > > Optionally, 2D AA hints can be added to get better appearance for > scales 1.25, 1.5, 1.75. > > --Semyon > > > On 9/20/2016 2:58 PM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8165594/webrev.02 >> >> The code formatting issues are updated. >> >> On 9/14/2016 8:02 PM, Semyon Sadetsky wrote: >>> Hi Alexander, >>> >>> When I press the arrow button (for example in the "111" combo) >>> several times I can see artifacts. They are well seen in scale x4. >> I have filled an issue on it: JDK-8166368 JComboBox drawing has >> artifacts with Windows Classic L&F on HiDPI display >> https://bugs.openjdk.java.net/browse/JDK-8166368 >> >> Thanks, >> Alexandr. >> >>> >>> --Semyon >>> >>> >>> On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 >>>> >>>> - HiDPI icons are only drawn for scaled graphics. >>>> >>>> The screenshots [1], [2], and [3] show difference between icons >>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png >>>> [2] >>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>>> [3] >>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >>>>> Hi Alexandr, >>>>> >>>>>> [1] >>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>>>>> >>>>> The icons do not look right to me. Take look at the top-left part of >>>>> the radio button. There is a white pixel between the shadow lines. >>>>> And >>>>> in the selected state there should be a black circle. But instead it >>>>> is a square. The check sign of the checkbox is too thin. And the >>>>> arrows of the combobox and the vertical scroll bar should have a >>>>> single pixel at the top/bottom side. But now they have two pixels. >>>>> >>>>> It would be also nice to see a screen shot of the native Windows >>>>> components for comparison. >>>>> >>>>> Personally when I would make changes like that, then my code would >>>>> look like this: >>>>> >>>>> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >>>>> // use the old good code. >>>>> } else { >>>>> // use the new code >>>>> } >>>>> >>>>> Best regards, >>>>> Andrej Golovnin >>>>> >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>>>>> >>>>>> [3] >>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>> >>> >> > From semyon.sadetsky at oracle.com Wed Sep 21 07:53:24 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 21 Sep 2016 10:53:24 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> <803bb585-83f3-9a31-2011-6a2195da7ad5@oracle.com> <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> Message-ID: Looks good. --Semyon On 9/20/2016 7:35 PM, Alexandr Scherbatiy wrote: > > Thank you for the suggested code. > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165594/webrev.04 > > - the provided method is used to draw triangles in BasicArrowButton > class > - shift to one pixel right is added for the triangles drawing > - AA rendering hint is set to draw a radio button > > Screenshots [1] and [2] shows difference between icons drawing > before and after the fix for scales 2x and 4x. > > [1] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_03.png > [2] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_03.png > > Thanks, > Alexandr. > > On 9/20/2016 5:34 PM, Semyon Sadetsky wrote: >> I would rewrite the method that draws triangle to simplify it: >> >> private void paintScaledTriangle(Graphics g, double x, double y, >> double size, >> int direction, boolean isEnabled) { >> size = Math.max(size , 2); >> Path2D.Double path = new Path2D.Double(); >> path.moveTo(-size, size/2); >> path.lineTo(size, size/2); >> path.lineTo(0, -size/2); >> path.closePath(); >> AffineTransform affineTransform = new AffineTransform(); >> affineTransform.rotate(Math.PI * (direction - 1) / 4 ); >> path.transform(affineTransform); >> >> Graphics2D g2d = (Graphics2D) g; >> g2d.translate(x + size / 2. - 1, y + size / 2); >> Color oldColor = g.getColor(); >> if (!isEnabled) { >> g2d.translate(1, 0); >> g2d.setColor(highlight); >> g2d.fill(path); >> g2d.translate(-1, 0); >> } >> g2d.setColor(isEnabled ? darkShadow : shadow); >> g2d.fill(path); >> g2d.translate( - x - size / 2. + 1, - y - size / 2); >> g2d.setColor(oldColor); >> } >> >> I'm suggesting to make the paintTriangle() method accept floating >> point coordinates to get more precise location and size for the >> scaled version. >> >> Optionally, 2D AA hints can be added to get better appearance for >> scales 1.25, 1.5, 1.75. >> >> --Semyon >> >> >> On 9/20/2016 2:58 PM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.02 >>> >>> The code formatting issues are updated. >>> >>> On 9/14/2016 8:02 PM, Semyon Sadetsky wrote: >>>> Hi Alexander, >>>> >>>> When I press the arrow button (for example in the "111" combo) >>>> several times I can see artifacts. They are well seen in scale x4. >>> I have filled an issue on it: JDK-8166368 JComboBox drawing has >>> artifacts with Windows Classic L&F on HiDPI display >>> https://bugs.openjdk.java.net/browse/JDK-8166368 >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>> >>>> >>>> On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 >>>>> >>>>> - HiDPI icons are only drawn for scaled graphics. >>>>> >>>>> The screenshots [1], [2], and [3] show difference between icons >>>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png >>>>> [2] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>>>> [3] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>>>>>> >>>>>> The icons do not look right to me. Take look at the top-left part of >>>>>> the radio button. There is a white pixel between the shadow >>>>>> lines. And >>>>>> in the selected state there should be a black circle. But instead it >>>>>> is a square. The check sign of the checkbox is too thin. And the >>>>>> arrows of the combobox and the vertical scroll bar should have a >>>>>> single pixel at the top/bottom side. But now they have two pixels. >>>>>> >>>>>> It would be also nice to see a screen shot of the native Windows >>>>>> components for comparison. >>>>>> >>>>>> Personally when I would make changes like that, then my code would >>>>>> look like this: >>>>>> >>>>>> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >>>>>> // use the old good code. >>>>>> } else { >>>>>> // use the new code >>>>>> } >>>>>> >>>>>> Best regards, >>>>>> Andrej Golovnin >>>>>> >>>>>>> [2] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>>>>>> >>>>>>> [3] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Wed Sep 21 13:06:25 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 21 Sep 2016 16:06:25 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: References: <7823974c-523d-afea-c6db-4b5e9a6c33cb@oracle.com> <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> Message-ID: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all_01 The public API remains unchanged: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api ParagraphView and GlyphPainter2 are updated to return Recatngel2D shape for ParagraphView.modelToView(...) call. However, the returned rectangle has int coordinates when "i18n" is set just because TextLayout.getCaretInfo(hit) method in class GlyphPainter2 returns int caret info. Thanks, Alexandr. On 9/20/2016 2:41 PM, Semyon Sadetsky wrote: > > Yet another question: Why the floating point API doesn't work for > JTextPane? > > Also it doesn't work for JTextArea, JTextField and JTextPane if i18n > is on. > > --Semyon > > > On 12.09.2016 15:19, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all >> public API changes: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api >> >> - @since 9 tag is added to new methods. >> >> Thanks, >> Alexandr. >> >> On 9/10/2016 2:36 AM, Philip Race wrote: >>> - * Returns the tab size set for the document, defaulting to 8. >>> - * >>> - * @implSpec This implementation calls {@link #getTabSize() >>> getTabSize()}. >>> - * >>> - * @return the tab size >>> - */ >>> - protected float getFractionalTabSize() { >>> - return getTabSize(); >>> - } >>> - >>> >>> >>> It seems this was added only in 9. >>> Since I think I remember that asking a question about it. >>> I note it has no @since. Moot if you are really removing it but >>> what has it to do with the rest of this change ? >>> >>> -phil. >>> >>> On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >>>> public API changes: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >>>> >>>> - reflection is used to detect do methods with floating point API >>>> need to be called. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> >>>>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> Alexander, did you consider possibility to check if method is >>>>>>>> really over-riden then to use the old API? >>>>>>>> >>>>>>> Could you give a sample how it can be done? >>>>>> I think it is possible to use a reflection to found the latest >>>>>> overridden method which uses int coordinates and check does it >>>>>> has a corresponding overridden method with floating point >>>>>> arguments. But I doubt that it is a good solution. >>>>> yes. You could use: >>>>> useFloatingPointAPI = >>>>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>>>> ...).getDeclaringClass()); >>>>> >>>>> Otherwise, with high probability your new API will never be used. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> Hi Alexander, >>>>>>>>>> >>>>>>>>>> It is a good style to add a note recommending what to use >>>>>>>>>> instead of the method which is being deprecated. >>>>>>>>>> >>>>>>>>> Could you review the updated public API there "replaced by" >>>>>>>>> notes are added to the deprecated methods: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>>>> >>>>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>>>> introduced and moreover is set to false by default. If the >>>>>>>>>> old API is used then it doesn't matter which value it has >>>>>>>>>> because the float values will receive ints. And for the new >>>>>>>>>> API I would expect everything having the float precision, and >>>>>>>>>> it is unclear what may be the reason to switch it off back to >>>>>>>>>> integer. Especially if >>>>>>>>>> >>>>>>>>>> " This allows to draw text properly using graphics with >>>>>>>>>> scaled transform." >>>>>>>>>> >>>>>>>>>> so an improper mode is the default? >>>>>>>>>> >>>>>>>>> This is has been discussed below. For example new >>>>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int >>>>>>>>> p1) with floating point coordinates is added to the PlainView >>>>>>>>> which has the same method with int coordinates. Suppose >>>>>>>>> someone has a custom password component which uses and old >>>>>>>>> methods with int coordinates. >>>>>>>>> -------- >>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>> >>>>>>>>> @Override >>>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>>> // draw echo chars >>>>>>>>> } >>>>>>>>> } >>>>>>>>> -------- >>>>>>>>> >>>>>>>>> If we start to call drawSelectedText() with floating point >>>>>>>>> values the customization of old components will not be used >>>>>>>>> and the CustomPasswordField from the example starts to show >>>>>>>>> real text instead of echo chars. This is incompatible change >>>>>>>>> with previous JDK releases. >>>>>>>>> >>>>>>>>> The solution is to switch to new floating point API only when >>>>>>>>> it is known that a component properly overrides new methods >>>>>>>>> with floating point arguments. After that the >>>>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>>>> >>>>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>>>> sure that drawSelectedText() methods with floating point >>>>>>>>> arguments is overridden. So Swing standard text components are >>>>>>>>> switched to use new floating point API. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>>>> OK .. I do not know enough about how modelToView is used by >>>>>>>>>>>> Swing >>>>>>>>>>>> to know what is really needed here. Someone with a bit more >>>>>>>>>>>> Swing >>>>>>>>>>>> background needs to chime in. I was encouraged that the >>>>>>>>>>>> *API* surface >>>>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>>>> webrev >>>>>>>>>>>> but maybe that is because you did not include everything. >>>>>>>>>>>> For example >>>>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>>>> PasswordView >>>>>>>>>>>> since that is a public class would become part of the spec >>>>>>>>>>>> .. would they not ? >>>>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>>>> >>>>>>>>>>>> Put another way I was looking for what the content of the >>>>>>>>>>>> CCC would be. >>>>>>>>>>> Here is the updated version of the public API change >>>>>>>>>>> which includes overridden deprecated methods: >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>>>> modelToView >>>>>>>>>>>>>> That will just hold this up as the reasoning behind >>>>>>>>>>>>>> needing those changes is not something >>>>>>>>>>>>>> I have yet been able to convince myself about - even >>>>>>>>>>>>>> after reading your last email. >>>>>>>>>>>>> >>>>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>>>> p)) is not included in the current fix. I only moved the >>>>>>>>>>>>> new methods JTextComponent.modelToView2D(int >>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret >>>>>>>>>>>>> to this fix. These methods are used not only for caret but >>>>>>>>>>>>> in other cases like mouse handling, text dragging and others. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>>>> - public >>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>>>> are added >>>>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API >>>>>>>>>>>>>>> in standard Java text components >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point >>>>>>>>>>>>>>>>> I am not sure what we are gaining >>>>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It affects only the methods that the 3rd party code >>>>>>>>>>>>>>>>> can over-ride >>>>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal >>>>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>>>> Is there any other method that matters / is used in >>>>>>>>>>>>>>>>> this way ? >>>>>>>>>>>>>>>> I have found the following methods which relate to >>>>>>>>>>>>>>>> text drawing, can be overridden and could have floating >>>>>>>>>>>>>>>> point coordinates: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is also a method which relates to a caret >>>>>>>>>>>>>>>> position in a text: >>>>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point >>>>>>>>>>>>>>>> p) >>>>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they >>>>>>>>>>>>>>>>> will get the JDK >>>>>>>>>>>>>>>>> super-class version, thus losing any customisation >>>>>>>>>>>>>>>>> they might have done >>>>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class >>>>>>>>>>>>>>>> which overrides >>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>> and draws echo chars instead of text. >>>>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and >>>>>>>>>>>>>>>>> always call the float versions >>>>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>>>> method is: >>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace >>>>>>>>>>>>>>>> at the end >>>>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>>>> make calls >>>>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>>>> * {@code drawSelectedText} so that the way >>>>>>>>>>>>>>>> selected and >>>>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Applications can rely on this behaviour and stopping >>>>>>>>>>>>>>>> to call the >>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>> with int coordinates will be incompatible change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Is there a more fine grained way to detect >>>>>>>>>>>>>>>>>>> programmer awareness or lack of awareness of the new >>>>>>>>>>>>>>>>>>> methods? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Here is a slightly updated version which adds >>>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>>>> and enabled for standard Swing text component >>>>>>>>>>>>>>>>>> classes. This has advantage that selection will work >>>>>>>>>>>>>>>>>> for text component in users applications on HiDPI >>>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But it still has the same problem. Applications >>>>>>>>>>>>>>>>>> which use custom View classes needs to updated them >>>>>>>>>>>>>>>>>> to implement corresponding text drawing methods with >>>>>>>>>>>>>>>>>> floating point arguments and enable the floating >>>>>>>>>>>>>>>>>> point API usage. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 >>>>>>>>>>>>>>>>>>>> Provide public API for text related methods in >>>>>>>>>>>>>>>>>>>> SwingUtilities2 >>>>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>>>> By default it is false and all work as before. >>>>>>>>>>>>>>>>>>>> The issue with selected text is reproduced. >>>>>>>>>>>>>>>>>>>> An application with enabled property does not >>>>>>>>>>>>>>>>>>>> have issue with the selected text but a user should >>>>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>>>> all methods with floating point values if he >>>>>>>>>>>>>>>>>>>> uses corresponding methods with integer values. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Here is a proposed solution where new public >>>>>>>>>>>>>>>>>>>> system property >>>>>>>>>>>>>>>>>>>> "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and >>>>>>>>>>>>>>>>>>>>>> the 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each >>>>>>>>>>>>>>>>>>>>>> glyph advance in >>>>>>>>>>>>>>>>>>>>>> StandardGlyphVector.initPositions() method is >>>>>>>>>>>>>>>>>>>>>> 99.999992. >>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, advance, N >>>>>>>>>>>>>>>>>>>>>> * advance); >>>>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float >>>>>>>>>>>>>>>>>>>>>> position 99.999998 is shifted one pixel left >>>>>>>>>>>>>>>>>>>>>> which affects the text selection code in Swing: >>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = font.getStringBounds(TEXT, 0, >>>>>>>>>>>>>>>>>>>>>> index, g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero >>>>>>>>>>>>>>>>>>>>> translate the transformed coordinates are: >>>>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but >>>>>>>>>>>>>>>>>>>>>>>> there still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text >>>>>>>>>>>>>>>>>>>>>>>> related. Can you take a look. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of >>>>>>>>>>>>>>>>>>>>>>> the text. >>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related >>>>>>>>>>>>>>>>>>>>>>>>> to the fact that char width can be fractional >>>>>>>>>>>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Sep 21 16:21:02 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 21 Sep 2016 19:21:02 +0300 Subject: [9] Review request for 8163124 Add floating point API support to javax.swing.text.Caret In-Reply-To: <57BE88E8.1070409@oracle.com> References: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> <57A8FD3A.5040700@oracle.com> <4932b261-ec98-435d-3271-9de33e30bd6e@oracle.com> <57AA3DEE.1090602@oracle.com> <1c855e83-f713-d21f-ccfc-3a253713e932@oracle.com> <8e8aec05-73a1-a60b-d0a2-1b7590c75d71@oracle.com> <57B4B1D2.9030702@oracle.com> <85e9924e-221f-9404-f4b1-56bfea67730b@oracle.com> <57BE88E8.1070409@oracle.com> Message-ID: <36c65570-c213-9d7c-b146-3ca8a0621a6d@oracle.com> When a font size is small and UI scale is large it is possible that a char advance can be smaller than 1. For example, if font is Dialog plain with size 2 and UI scale is 32 the 'j' char width has value 0.47. For this case saved int caret position which is used to move a caret to next line does not have enough precision to be placed between the first and the second 'j' char. I have prepared the test [1]. It should be run with the applied patch [2] for the fix JDK-8156217 because it contains implementation of the TextComponent.modelToView2D(pos) method. The test shows a JTextArea with two lines "jjjjjjjjjjj" and uses a custom caret implementation. Pressing the arrow key to the right and down leads that the caret is moved before the first character on the second line instead of the second character. [1] http://cr.openjdk.java.net/~alexsch/8163124/samples/MagicCaretPositionTest.java [2] http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all_01 Thanks, Alexandr. On 8/25/2016 8:58 AM, Philip Race wrote: > On 8/24/16, 9:45 AM, Alexander Scherbatiy wrote: >> On 17/08/16 22:49, Phil Race wrote: >>> Sorry, but I have had some trouble trying to picture this. >>> If the caret is between "b" and "c", being off by a fractional value >>> seems >>> unlikely to make it jump to between "a" and "b". >>> It might now "round" to somewhere in the trailing pixel of "b" but >>> nowhere >>> near the leading edge. >> I suppose yes. >> >> Another case is when a caret is in the center of the "b". In this >> case it can be moved to another character if fractional values are >> not taken into account. However, may be it does not matter which >> character "a" or "c" would be chosen because they have nearly the >> same distance to the center of the "b". > > Indeed. And I think that is no different than today that "in the > middle" means > it is 50:50 which way it goes with integers too. > Also unless this position was set by some code that just picked a > position > out thin air, I would expect this to always be "between" the > characters as > a result of normal calculation of the caret. > > -phil. >> >> Thanks, >> Alexandr. >> >>> >>> -phil. >>> >>> >>> On 08/11/2016 09:55 AM, Alexandr Scherbatiy wrote: >>>> >>>> I am sorry. The JTextComponent.viewToModel(Point) method returns >>>> the closest location for the provided point. If the caret position >>>> is N.25 the distance to the right character is 0.25 and to the left >>>> one is greater than 0.75. Even in for the worst case the distance >>>> to the right character is less than 1 and to the left is greater >>>> than 1 (suppose a character width is greater than 1). For the >>>> provided cases the caret should always be placed in the proper >>>> closest location. >>>> >>>> There is just a question could a user just compare the provided >>>> magic caret position (which coordinates are rounded) with the >>>> result of rectangle from the method >>>> JTextComponent.modelToView2(position) which returns the floating >>>> point positions. So for the same position the rounded point can be >>>> (N, y) and the rectangle can have bounds (N.25, y, w, h). Comparing >>>> these results can lead that the magic caret point does not belong >>>> to the provided rectangle but it is definitely that the x >>>> coordinate of this rectangle is the closest one to this point. >>>> >>>> By the way, I can merge the added JTextComponent.modelToView2D(int >>>> pos)/viewToModel2D(Point2D pt) public methods with the fix for the >>>> 8156217 Selected text is shifted on HiDPI display >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04/ >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/10/2016 5:22 PM, Alexandr Scherbatiy wrote: >>>>> >>>>> Suppose there is a text area with two lines with the same text: >>>>> abcdefghij >>>>> abcdefghij >>>>> >>>>> The char 'c' on the fist line has offset 2 and some coordinates >>>>> (x1, y1) where x1 can have a floating point values like 21.25. >>>>> The char 'c' on the second line has offset 13 and coordinates (x2, >>>>> y2) where x2 is equal to x1. >>>>> >>>>> Setting the caret to the first 'c' character sets the magic caret >>>>> position to (round (x1), round (y1)) position. >>>>> Pressing the arrow down key calculates the new y position and >>>>> uses the x position from the magic caret position which is >>>>> round(21.5) = 21. >>>>> Now the new offset can be calculated as >>>>> textComponent.viewToModel(new Point(21, newY)) which returns >>>>> offset 12 for char 'b' on the second line instead the offset 13 >>>>> for char 'c'. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/9/2016 11:32 PM, Philip Race wrote: >>>>>> But characters are of varying width. Being on the "20th" char on >>>>>> line N >>>>>> may mean being on the "25th" on line N+1. >>>>>> >>>>>> So I am claiming this is nothing new and we really do not need do >>>>>> anything here. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 8/9/16, 1:06 PM, Alexandr Scherbatiy wrote: >>>>>>> On 8/9/2016 12:44 AM, Phil Race wrote: >>>>>>>> I was not familiar with this "magic caret" but from reading it >>>>>>>> seems like it has just one use/purpose. >>>>>>>> In the event that someone has multi-line text that you can >>>>>>>> navigate around with up/down arrow keys >>>>>>>> and that text has lines of varying length, you want a >>>>>>>> "preferred" horizontal position for the caret >>>>>>>> to be remembered so the caret is placed at that position >>>>>>>> whenever the line of text has a length >>>>>>>> greater than the caret position. Is there anything more to it >>>>>>>> than that ? >>>>>>>> >>>>>>>> Obviously the caret needs to be placed correctly in the context >>>>>>>> of the text, so the precise position, >>>>>>>> even in an all-integer world, is not going to line up on every >>>>>>>> single line, unless you have monospaced text. >>>>>>>> ie the "pixel" position is going to get converted into a >>>>>>>> position on the leading or trailing edge of some glyph >>>>>>>> >>>>>>>> So I wonder, does adding float matter .. is the extra precision >>>>>>>> valuable here ? >>>>>>> It may depend on the rounding of a point position. >>>>>>> Suppose there are two lines with the same text. The caret is >>>>>>> on the first line can have x position N.25. Pressing down the >>>>>>> arrow key can round it to the N and the caret can be set to a >>>>>>> previous char on the second line. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 08/04/2016 05:44 AM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8163124 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8163124/webrev.00 >>>>>>>>> >>>>>>>>> The text position can have floating point value on HiDPI >>>>>>>>> display. The Caret interface should be updated to allow use >>>>>>>>> floating point positions. >>>>>>>>> >>>>>>>>> The fix adds the following public API with floating point >>>>>>>>> positions: >>>>>>>>> javax.swing.text.Caret.getMagicCaretPosition2D() >>>>>>>>> javax.swing.text.Caret.setMagicCaretPosition2D(Point2D p) >>>>>>>>> javax.swing.text.JTextComponent.modelToView2D(int pos) >>>>>>>>> javax.swing.text.JTextComponent.viewToModel2D(Point2D pt) >>>>>>>>> javax.swing.text.ParagraphView.getClosestPositionTo(int pos, >>>>>>>>> Position.Bias b, Shape a, int direction, Position.Bias[], int >>>>>>>>> rowIndex, float x) >>>>>>>>> >>>>>>>>> >>>>>>>>> The fix replaces >>>>>>>>> Caret.getMagicCaretPosition()/setMagicCaretPosition(Point p) >>>>>>>>> to >>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>> p) in all places >>>>>>>>> except DefaultCaret because DefaultCaret extends Rectangle >>>>>>>>> so its coordinates always have int values. >>>>>>>>> I have filled a separated enhancement for this JDK-8163174 >>>>>>>>> Add DefaultCaret2D which supports floating point API >>>>>>>>> >>>>>>>>> To make a custom caret use floating point API it is also >>>>>>>>> necessary that PlainView.modelToView() returns a rectangle >>>>>>>>> with floating point values. It can be done after the fix >>>>>>>>> JDK-8156217 Selected text is shifted on HiDPI display >>>>>>>>> which implements Utilities.getTabbedTextWidth(Segment s, >>>>>>>>> FontMetrics metrics, float x, TabExpander e, int startOffset) >>>>>>>>> method. >>>>>>>>> I have filled a separated issue on it: >>>>>>>>> JDK-8163175 PlainView.modelToView() method should return >>>>>>>>> Rectangle2D >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>> >>>> >>> >> From alexandr.scherbatiy at oracle.com Wed Sep 21 20:23:51 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 21 Sep 2016 23:23:51 +0300 Subject: [9] Review request for 8157065: There is no the focus border on the selected tab. In-Reply-To: <59501abb-236f-e689-8a5e-7d43a4e0ac4a@oracle.com> References: <7462fb94-9ab7-3303-5cbf-4ea1a1bb38d0@oracle.com> <536de57e-b109-fcac-7ddd-08438338da89@oracle.com> <348732cf-2a21-a1c5-f427-b425d30311a9@oracle.com> <2aa52025-9829-be35-45b3-a842b7213b43@oracle.com> <0c6e0c52-e1c0-716d-36b4-46626ab0e402@oracle.com> <14598d03-ef0b-3ac1-ad8b-4cf7fb4ec947@oracle.com> <761df97e-a3e0-858d-68e8-7bd861a193db@oracle.com> <9d3571ec-6c45-8889-4f52-c88f2c547c0c@oracle.com> <6cc6e2f5-f2e1-9c12-d3c6-72d7abd52618@oracle.com> <4d741950-6655-31b8-92b4-69c528c08c69@oracle.com> <0f57ef7f-a8ad-fef0-5be9-b71250c23022@oracle.com> <16f2db7f-94fb-c027-d1b0-62e5e6ca57cd@oracle.com> <59501abb-236f-e689-8a5e-7d43a4e0ac4a@oracle.com> Message-ID: <31f84b4c-3832-102a-b538-6a92454de58f@oracle.com> On 9/20/2016 10:40 AM, Semyon Sadetsky wrote: > On 9/20/2016 12:00 AM, Alexandr Scherbatiy wrote: >> On 9/14/2016 11:51 AM, Semyon Sadetsky wrote: >>> On 9/13/2016 9:03 PM, Alexandr Scherbatiy wrote: >>>> On 9/13/2016 8:49 PM, Semyon Sadetsky wrote: >>>>> On 9/13/2016 8:46 PM, Alexandr Scherbatiy wrote: >>>>>> On 9/13/2016 8:34 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> On 9/13/2016 8:25 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/13/2016 7:38 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/13/2016 7:21 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> On 9/12/2016 10:42 PM, Semyon Sadetsky wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/12/2016 9:48 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>> On 9/12/2016 7:52 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> On 9/12/2016 6:50 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/12/2016 6:42 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>> GTKPainter does not implement a lot of methods which can >>>>>>>>>>>>>>> be accessed by public API. Could you, please, explain, >>>>>>>>>>>>>>> why this specific method is more important than, for >>>>>>>>>>>>>>> example, paintToolBarContentBackground() or >>>>>>>>>>>>>>> paintToggleButtonBorder(), or all other unimplemented? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In general, how do you separate public API methods of >>>>>>>>>>>>>>> the SynthPainter class into two sets: the first set that >>>>>>>>>>>>>>> *should be* over-riden and the second set of methods >>>>>>>>>>>>>>> that *should not be* overr-riden? Are there any >>>>>>>>>>>>>>> systematic criterium for that differentiation? >>>>>>>>>>>>>> All the same methods with different number of arguments >>>>>>>>>>>>>> which do not fall to overridden implementation should be >>>>>>>>>>>>>> overridden to provide proper implementation. >>>>>>>>>>>>> Where I can read about this rule for SynthPainter? And it >>>>>>>>>>>>> obviously is not true. >>>>>>>>>>>> This is a usual rule for public methods which can be used >>>>>>>>>>>> by an external application. >>>>>>>>>>>>> There are a lot of methods that are not over-riden in >>>>>>>>>>>>> GTKPainter. I even wrote an examples above. >>>>>>>>>>>> The SynthPainter.paintToolBarContentBackground(..., >>>>>>>>>>>> orientation) calls >>>>>>>>>>>> SynthPainter.paintToolBarContentBackground(...) without the >>>>>>>>>>>> orientation and the GTKPainter >>>>>>>>>>>> .paintToolBarContentBackground overrides the method without >>>>>>>>>>>> the orientation. So calls to >>>>>>>>>>>> gtkPainter.paintToolBarContentBackground(..., orientation) >>>>>>>>>>>> falls down to the overriden method in GTKPainter. >>>>>>>>>>>> >>>>>>>>>>>> The same is for >>>>>>>>>>>> SynthPainter.paintProgressBarBackground(..., orientation) >>>>>>>>>>>> and paintScrollBarBackground(..., orientation) methods. >>>>>>>>>>>> >>>>>>>>>>>> The SynthPainter has only one paintToggleButtonBorder() >>>>>>>>>>>> method. >>>>>>>>>>> Interesting rule... I thought that more specific method >>>>>>>>>>> version may have different implementation. >>>>>>>>>> It was done for historical reason. For example before the >>>>>>>>>> fix JDK-5033822 "Synth ScrollBar paintTrack() dosn't support >>>>>>>>>> orientation" >>>>>>>>>> there was only paintScrollBarBackground() method without >>>>>>>>>> the orientation in the SynthPainter class. >>>>>>>>>> After the fix the paintScrollBarBackground() method with >>>>>>>>>> the orientation is added which default implementation just >>>>>>>>>> calls the same method without the orientation because old >>>>>>>>>> user's subclasses can override the method without the >>>>>>>>>> orientation an not be aware about new method version. >>>>>>>>>> >>>>>>>>>>> What would you say about paintSeparatorBackground() ? >>>>>>>>>>> It's (..., orientation) version is over-ridden while the >>>>>>>>>>> generic version is not over-ridden. >>>>>>>>>> I guess that it is just a bug. >>>>>>>>> Not sure. GTKPainter has never been providing a systematic API >>>>>>>>> from the beginning. It is not for an arbitrary external use, >>>>>>>>> because the resulting painting will be unpredictable. I >>>>>>>>> explained this in this thread many times. And even if I would >>>>>>>>> like to provide this useless method implementation >>>>>>>> It is a part of the public SynthPainter API and can be called >>>>>>>> by an external application. >>>>>>> I can be called without any predictable result. This is the >>>>>>> current state. It cannot be changed by the change you are >>>>>>> proposing to add. >>>>>> The result is described in the public method javadoc. >>>>>>>>> I were not able to do this because the orientation is a >>>>>>>>> required parameter to paint the GTK tab border. >>>>>>>> The overridden method without the orientation can just call >>>>>>>> the overridden method with orientation passing a default >>>>>>>> orientation value. >>>>>>> And what the default value is? It is not defined. >>>>>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JSeparator.html >>>>>> >>>>>> Creates a new horizontal separator: Constructor JSeparator(). >>>>> Sorry, I didn't get how the separator orientation is related to >>>>> tabbed pane border. >>>> https://docs.oracle.com/javase/7/docs/api/javax/swing/JTabbedPane.html#setTabPlacement(int) >>>> >>>> The default value, if not set, is SwingConstants.TOP. >>> It is a default for JTabbedPane but not for the LnF. JTabbedPane >>> always has some orientation and it is used in the painter. But I >>> cannot even imagine what should be painted if the GTK painter API is >>> called to paint TabbedPane without orientation and why. Because >>> orientation is mandatory in the corresponding gtk-lib call. >> The GTK L&F just tries to paint Swing components in the same way as >> native components. >> It is possible to get a default orientation of a native component >> to which the JTabbedPane corresponds to and use it. > All orientation are equivalent and should correspond to the component > position. Drawing a border for a tab with unknown orientation is > senseless. https://developer.gnome.org/gtk-tutorial/stable/x1450.html void gtk_notebook_set_tab_pos(GtkNotebook *notebook, GtkPositionType pos); GtkPositionType will be one of the following, which are pretty self explanatory: GTK_POS_LEFT, GTK_POS_RIGHT, GTK_POS_TOP, GTK_POS_BOTTOM. GTK_POS_TOP is the default. Thanks, Alexandr. > --Semyon >> >> Thanks, >> Alexandr. >>> >>> --Semyon >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> --Semyon >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/12/2016 6:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> The paintTabbedPaneTabBorder() without orientation >>>>>>>>>>>>>>>> should be implemented as well because it can be >>>>>>>>>>>>>>>> accessed by public API. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6/3/2016 10:54 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 6/3/2016 10:34 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>>> On 03.06.16 22:21, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>>>>>> What reason? Why it is not public? since I provided >>>>>>>>>>>>>>>>>>>> the code example >>>>>>>>>>>>>>>>>>>> where these methods are accessed by the user? >>>>>>>>>>>>>>>>>>> GTK toollkit painting sequence is very different. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What does it mean "different"? Even in this fix you >>>>>>>>>>>>>>>>>> implement one of the method according to the spec and >>>>>>>>>>>>>>>>>> skip the same method for some unknown reason. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I still did not get why an overload method should >>>>>>>>>>>>>>>>>>>>> have the same behavior >>>>>>>>>>>>>>>>>>>>> as its associates. This is a brand new design >>>>>>>>>>>>>>>>>>>>> principle I've never heard >>>>>>>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ........... >>>>>>>>>>>>>>>>>>> That's nice... >>>>>>>>>>>>>>>>>>> Do you have any other concerns? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I still do not understand why the first method with >>>>>>>>>>>>>>>>>> default orientation is not implemented. >>>>>>>>>>>>>>>>> I guess you meant "is not over-ridden". :) Once again: >>>>>>>>>>>>>>>>> because it is never used. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From andrej.golovnin at gmail.com Wed Sep 21 20:38:49 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 21 Sep 2016 22:38:49 +0200 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> <803bb585-83f3-9a31-2011-6a2195da7ad5@oracle.com> <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> Message-ID: Hi Alexandr, looks good. Thanks! Best regards, Andrej Golovnin > On 20 Sep 2016, at 18:35, Alexandr Scherbatiy wrote: > > > Thank you for the suggested code. > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165594/webrev.04 > > - the provided method is used to draw triangles in BasicArrowButton class > - shift to one pixel right is added for the triangles drawing > - AA rendering hint is set to draw a radio button > > Screenshots [1] and [2] shows difference between icons drawing before and after the fix for scales 2x and 4x. > > [1] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_03.png > [2] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_03.png > > Thanks, > Alexandr. > > On 9/20/2016 5:34 PM, Semyon Sadetsky wrote: >> I would rewrite the method that draws triangle to simplify it: >> >> private void paintScaledTriangle(Graphics g, double x, double y, double size, >> int direction, boolean isEnabled) { >> size = Math.max(size , 2); >> Path2D.Double path = new Path2D.Double(); >> path.moveTo(-size, size/2); >> path.lineTo(size, size/2); >> path.lineTo(0, -size/2); >> path.closePath(); >> AffineTransform affineTransform = new AffineTransform(); >> affineTransform.rotate(Math.PI * (direction - 1) / 4 ); >> path.transform(affineTransform); >> >> Graphics2D g2d = (Graphics2D) g; >> g2d.translate(x + size / 2. - 1, y + size / 2); >> Color oldColor = g.getColor(); >> if (!isEnabled) { >> g2d.translate(1, 0); >> g2d.setColor(highlight); >> g2d.fill(path); >> g2d.translate(-1, 0); >> } >> g2d.setColor(isEnabled ? darkShadow : shadow); >> g2d.fill(path); >> g2d.translate( - x - size / 2. + 1, - y - size / 2); >> g2d.setColor(oldColor); >> } >> >> I'm suggesting to make the paintTriangle() method accept floating point coordinates to get more precise location and size for the scaled version. >> >> Optionally, 2D AA hints can be added to get better appearance for scales 1.25, 1.5, 1.75. >> >> --Semyon >> >> >> On 9/20/2016 2:58 PM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.02 >>> >>> The code formatting issues are updated. >>> >>> On 9/14/2016 8:02 PM, Semyon Sadetsky wrote: >>>> Hi Alexander, >>>> >>>> When I press the arrow button (for example in the "111" combo) several times I can see artifacts. They are well seen in scale x4. >>> I have filled an issue on it: JDK-8166368 JComboBox drawing has artifacts with Windows Classic L&F on HiDPI display >>> https://bugs.openjdk.java.net/browse/JDK-8166368 >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>> >>>> >>>> On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 >>>>> >>>>> - HiDPI icons are only drawn for scaled graphics. >>>>> >>>>> The screenshots [1], [2], and [3] show difference between icons drawing before and after the fix for scales 1x, 2x, and 4x. >>>>> >>>>> [1] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png >>>>> [2] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>>>> [3] http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>>>>> The icons do not look right to me. Take look at the top-left part of >>>>>> the radio button. There is a white pixel between the shadow lines. And >>>>>> in the selected state there should be a black circle. But instead it >>>>>> is a square. The check sign of the checkbox is too thin. And the >>>>>> arrows of the combobox and the vertical scroll bar should have a >>>>>> single pixel at the top/bottom side. But now they have two pixels. >>>>>> >>>>>> It would be also nice to see a screen shot of the native Windows >>>>>> components for comparison. >>>>>> >>>>>> Personally when I would make changes like that, then my code would >>>>>> look like this: >>>>>> >>>>>> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >>>>>> // use the old good code. >>>>>> } else { >>>>>> // use the new code >>>>>> } >>>>>> >>>>>> Best regards, >>>>>> Andrej Golovnin >>>>>> >>>>>>> [2] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>>>>>> [3] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>> >>>> >>> >> > From ebakke at ultorg.com Thu Sep 22 17:10:04 2016 From: ebakke at ultorg.com (Eirik Bakke) Date: Thu, 22 Sep 2016 17:10:04 +0000 Subject: SVG support for Swing icons etc.? (Useful for HiDPI) Message-ID: Hi, swing-dev. I see there's a lot of work going on to make Swing work well with HiDPI/Retina displays, including the new MultiResolutionImage API ( http://openjdk.java.net/jeps/251 ). It's now up to application developers to provide icons and other image assets in multiple resolutions. My bet is that many of these newly designed assets are going to be designed as vector art (e.g. Adobe Illustrator), which will currently need to be manually rasterized down to PNG files of the different required resolutions. Are there any plans or existing RFEs for allowing Swing to load SVG files from its existing APIs (e.g. "new ImageIcon(URL)")? I searched the OpenJDK JIRA and JEP 251 but could not find any mention of this. I think SVG support would make it easier for application developers to supply icons that look good at all resolutions. SVG support is now standard in all the big web browsers. Some existing approaches involving use of the external Batik library can be seen on http://stackoverflow.com/questions/2495501/swing-batik-create-an-imageicon-from-an-svg-file . -- Eirik -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Sep 22 17:21:20 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 22 Sep 2016 20:21:20 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> <803bb585-83f3-9a31-2011-6a2195da7ad5@oracle.com> <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> Message-ID: <61c8fb44-b006-5755-c516-f74ff12af35f@oracle.com> Looks fine. Can you please check the "thumb" in the scroll bar in text area as well(it is invisible in the current screenshots) On 20.09.16 19:35, Alexandr Scherbatiy wrote: > > Thank you for the suggested code. > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8165594/webrev.04 > > - the provided method is used to draw triangles in BasicArrowButton class > - shift to one pixel right is added for the triangles drawing > - AA rendering hint is set to draw a radio button > > Screenshots [1] and [2] shows difference between icons drawing before > and after the fix for scales 2x and 4x. > > [1] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_03.png > > [2] > http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_03.png > > > Thanks, > Alexandr. > > On 9/20/2016 5:34 PM, Semyon Sadetsky wrote: >> I would rewrite the method that draws triangle to simplify it: >> >> private void paintScaledTriangle(Graphics g, double x, double y, >> double size, >> int direction, boolean isEnabled) { >> size = Math.max(size , 2); >> Path2D.Double path = new Path2D.Double(); >> path.moveTo(-size, size/2); >> path.lineTo(size, size/2); >> path.lineTo(0, -size/2); >> path.closePath(); >> AffineTransform affineTransform = new AffineTransform(); >> affineTransform.rotate(Math.PI * (direction - 1) / 4 ); >> path.transform(affineTransform); >> >> Graphics2D g2d = (Graphics2D) g; >> g2d.translate(x + size / 2. - 1, y + size / 2); >> Color oldColor = g.getColor(); >> if (!isEnabled) { >> g2d.translate(1, 0); >> g2d.setColor(highlight); >> g2d.fill(path); >> g2d.translate(-1, 0); >> } >> g2d.setColor(isEnabled ? darkShadow : shadow); >> g2d.fill(path); >> g2d.translate( - x - size / 2. + 1, - y - size / 2); >> g2d.setColor(oldColor); >> } >> >> I'm suggesting to make the paintTriangle() method accept floating >> point coordinates to get more precise location and size for the scaled >> version. >> >> Optionally, 2D AA hints can be added to get better appearance for >> scales 1.25, 1.5, 1.75. >> >> --Semyon >> >> >> On 9/20/2016 2:58 PM, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.02 >>> >>> The code formatting issues are updated. >>> >>> On 9/14/2016 8:02 PM, Semyon Sadetsky wrote: >>>> Hi Alexander, >>>> >>>> When I press the arrow button (for example in the "111" combo) >>>> several times I can see artifacts. They are well seen in scale x4. >>> I have filled an issue on it: JDK-8166368 JComboBox drawing has >>> artifacts with Windows Classic L&F on HiDPI display >>> https://bugs.openjdk.java.net/browse/JDK-8166368 >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> --Semyon >>>> >>>> >>>> On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 >>>>> >>>>> - HiDPI icons are only drawn for scaled graphics. >>>>> >>>>> The screenshots [1], [2], and [3] show difference between icons >>>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png >>>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>>>> >>>>> [3] >>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >>>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>>> [1] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>>>>>> >>>>>> The icons do not look right to me. Take look at the top-left part of >>>>>> the radio button. There is a white pixel between the shadow lines. >>>>>> And >>>>>> in the selected state there should be a black circle. But instead it >>>>>> is a square. The check sign of the checkbox is too thin. And the >>>>>> arrows of the combobox and the vertical scroll bar should have a >>>>>> single pixel at the top/bottom side. But now they have two pixels. >>>>>> >>>>>> It would be also nice to see a screen shot of the native Windows >>>>>> components for comparison. >>>>>> >>>>>> Personally when I would make changes like that, then my code would >>>>>> look like this: >>>>>> >>>>>> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >>>>>> // use the old good code. >>>>>> } else { >>>>>> // use the new code >>>>>> } >>>>>> >>>>>> Best regards, >>>>>> Andrej Golovnin >>>>>> >>>>>>> [2] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>>>>>> >>>>>>> [3] >>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. From philip.race at oracle.com Thu Sep 22 17:34:05 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 22 Sep 2016 10:34:05 -0700 Subject: SVG support for Swing icons etc.? (Useful for HiDPI) In-Reply-To: References: Message-ID: <57E4160D.8020102@oracle.com> There is no work currently planned along those lines. If there were it would be JDK10 at the earliest. The alternative is that you custom render the exact size that is needed onto a BufferedImage using Graphic2D calls and hand that over. Granted it is not the same as bundling an SVG resource with your app but it doesn't depend on any unplanned work. -phil. On 9/22/16, 10:10 AM, Eirik Bakke wrote: > Hi, swing-dev. > > I see there's a lot of work going on to make Swing work well with > HiDPI/Retina displays, including the new MultiResolutionImage API ( > http://openjdk.java.net/jeps/251 ). > > It's now up to application developers to provide icons and other image > assets in multiple resolutions. My bet is that many of these newly > designed assets are going to be designed as vector art (e.g. Adobe > Illustrator), which will currently need to be manually rasterized down > to PNG files of the different required resolutions. > > Are there any plans or existing RFEs for allowing Swing to load SVG > files from its existing APIs (e.g. "new ImageIcon(URL)")? I searched > the OpenJDK JIRA and JEP 251 but could not find any mention of this. I > think SVG support would make it easier for application developers to > supply icons that look good at all resolutions. SVG support is now > standard in all the big web browsers. > > Some existing approaches involving use of the external Batik library > can be seen on > http://stackoverflow.com/questions/2495501/swing-batik-create-an-imageicon-from-an-svg-file . > > -- Eirik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Sep 23 12:52:52 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Sep 2016 15:52:52 +0300 Subject: [9] Review request for 8160160: The menu displayed nothing with the option"-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". In-Reply-To: <06069937-3447-85ee-27e2-fb8429f08bb6@oracle.com> References: <18da8062-6386-bc91-b146-0c03329c6f83@oracle.com> <21e7f336-570d-4898-4dbf-00e945ce377a@oracle.com> <9abb3797-a7c2-34d7-3a26-0df4f9df5f17@oracle.com> <06069937-3447-85ee-27e2-fb8429f08bb6@oracle.com> Message-ID: <16908a3d-030a-14e1-8bb1-ae61bd0ee6dd@oracle.com> On 01.09.16 14:21, Semyon Sadetsky wrote: > The proposed variant is better because if WM effects are switched off we > will receive this bug again. It should not be a problem because we will work in the similar way as native popup menu. This version looks fine. Please fila a separate RFE to update menu implementation to look as the native one, including the shadow. > > > On 8/31/2016 10:29 PM, Sergey Bylokhov wrote: >> Did you try to force HW popups for GTK l&f? The current proposal will >> lead to the situation when popup will have different border depending >> on location in/out of the frame. >> >> On 31.08.16 10:54, Semyon Sadetsky wrote: >>> Hi Sergey, >>> >>> This is a valid concern. The fix is updated: >>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.02/ >>> >>> --Semyon >>> >>> >>> On 8/30/2016 11:10 PM, Sergey Bylokhov wrote: >>>> Hi, Semyon. >>>> I suggest to double check the HW menu/popups, they should have the >>>> correct border, because they should use the top level window, which >>>> should contains correct shadow effect. Note that after the fix we >>>> should not have two borers in such cases. >>>> >>>> On 29.08.16 20:11, Alexandr Scherbatiy wrote: >>>>> >>>>> The fix looks good to me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/29/2016 7:08 PM, Semyon Sadetsky wrote: >>>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.01/ >>>>>> >>>>>> return type of ENGINE.finishPainting() changed to Buffered image. >>>>>> >>>>>> img.getRGB() returns a primitive not an object. >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>>> On 8/29/2016 3:45 PM, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> >>>>>>> On 8/29/2016 1:12 PM, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review fix for JDK9: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.00/ >>>>>>>> >>>>>>>> The menu border is not painted by GTK Adwaita theme and makes popup >>>>>>>> menu invisible at some circumstances. To resolve this the GTK menu >>>>>>>> border color is compared to the menu background color and if the >>>>>>>> same the border is painted by means of java graphics using a bit >>>>>>>> different color tone. >>>>>>> - BufferedImage img = (BufferedImage) ENGINE.finishPainting(); >>>>>>> if the ENGINE.finishPainting() always returns BufferedImage it >>>>>>> would be better to change the return type to BufferedImage. >>>>>>> >>>>>>> - border == img.getRGB(w / 2, h / 2) >>>>>>> Could we rely on that img.getRGB(0, h / 2) returns the same object >>>>>>> as the img.getRGB(w / 2, h / 2)? May be it is use equals() methods >>>>>>> for comparing in this case. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 23 13:03:37 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Sep 2016 16:03:37 +0300 Subject: [9] Review request for 8165594 Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI display In-Reply-To: <61c8fb44-b006-5755-c516-f74ff12af35f@oracle.com> References: <4558a1c2-ab09-68dd-ecb6-00dd042761a7@oracle.com> <8dbd795b-dc41-07f9-b3a0-9fab849937fb@oracle.com> <37f196ee-f555-ae8a-e41f-cad3a3469a5f@oracle.com> <803bb585-83f3-9a31-2011-6a2195da7ad5@oracle.com> <57504883-b5c7-730a-d60c-6ddb0b6ace3d@oracle.com> <61c8fb44-b006-5755-c516-f74ff12af35f@oracle.com> Message-ID: <3b6b0e2b-266f-9fb1-1473-73f8615396ed@oracle.com> On 22.09.16 20:21, Sergey Bylokhov wrote: > Looks fine. > Can you please check the "thumb" in the scroll bar in text area as > well(it is invisible in the current screenshots) I also suggest as a separate task check how this code will be printed, when the dpi will be much bigger. > > On 20.09.16 19:35, Alexandr Scherbatiy wrote: >> >> Thank you for the suggested code. >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8165594/webrev.04 >> >> - the provided method is used to draw triangles in BasicArrowButton >> class >> - shift to one pixel right is added for the triangles drawing >> - AA rendering hint is set to draw a radio button >> >> Screenshots [1] and [2] shows difference between icons drawing before >> and after the fix for scales 2x and 4x. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_03.png >> >> >> [2] >> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_03.png >> >> >> >> Thanks, >> Alexandr. >> >> On 9/20/2016 5:34 PM, Semyon Sadetsky wrote: >>> I would rewrite the method that draws triangle to simplify it: >>> >>> private void paintScaledTriangle(Graphics g, double x, double y, >>> double size, >>> int direction, boolean isEnabled) { >>> size = Math.max(size , 2); >>> Path2D.Double path = new Path2D.Double(); >>> path.moveTo(-size, size/2); >>> path.lineTo(size, size/2); >>> path.lineTo(0, -size/2); >>> path.closePath(); >>> AffineTransform affineTransform = new AffineTransform(); >>> affineTransform.rotate(Math.PI * (direction - 1) / 4 ); >>> path.transform(affineTransform); >>> >>> Graphics2D g2d = (Graphics2D) g; >>> g2d.translate(x + size / 2. - 1, y + size / 2); >>> Color oldColor = g.getColor(); >>> if (!isEnabled) { >>> g2d.translate(1, 0); >>> g2d.setColor(highlight); >>> g2d.fill(path); >>> g2d.translate(-1, 0); >>> } >>> g2d.setColor(isEnabled ? darkShadow : shadow); >>> g2d.fill(path); >>> g2d.translate( - x - size / 2. + 1, - y - size / 2); >>> g2d.setColor(oldColor); >>> } >>> >>> I'm suggesting to make the paintTriangle() method accept floating >>> point coordinates to get more precise location and size for the scaled >>> version. >>> >>> Optionally, 2D AA hints can be added to get better appearance for >>> scales 1.25, 1.5, 1.75. >>> >>> --Semyon >>> >>> >>> On 9/20/2016 2:58 PM, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.02 >>>> >>>> The code formatting issues are updated. >>>> >>>> On 9/14/2016 8:02 PM, Semyon Sadetsky wrote: >>>>> Hi Alexander, >>>>> >>>>> When I press the arrow button (for example in the "111" combo) >>>>> several times I can see artifacts. They are well seen in scale x4. >>>> I have filled an issue on it: JDK-8166368 JComboBox drawing has >>>> artifacts with Windows Classic L&F on HiDPI display >>>> https://bugs.openjdk.java.net/browse/JDK-8166368 >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 9/14/2016 5:39 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8165594/webrev.01 >>>>>> >>>>>> - HiDPI icons are only drawn for scaled graphics. >>>>>> >>>>>> The screenshots [1], [2], and [3] show difference between icons >>>>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>>>> >>>>>> [1] >>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x_01.png >>>>>> >>>>>> >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x_01.png >>>>>> >>>>>> >>>>>> [3] >>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x_01.png >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 9/8/2016 10:59 AM, Andrej Golovnin wrote: >>>>>>> Hi Alexandr, >>>>>>> >>>>>>>> [1] >>>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-1x.png >>>>>>>> >>>>>>>> >>>>>>> The icons do not look right to me. Take look at the top-left part of >>>>>>> the radio button. There is a white pixel between the shadow lines. >>>>>>> And >>>>>>> in the selected state there should be a black circle. But instead it >>>>>>> is a square. The check sign of the checkbox is too thin. And the >>>>>>> arrows of the combobox and the vertical scroll bar should have a >>>>>>> single pixel at the top/bottom side. But now they have two pixels. >>>>>>> >>>>>>> It would be also nice to see a screen shot of the native Windows >>>>>>> components for comparison. >>>>>>> >>>>>>> Personally when I would make changes like that, then my code would >>>>>>> look like this: >>>>>>> >>>>>>> if (isNotHiDPI() || itMakesMoreSenseToUseTheOldCode()) { >>>>>>> // use the old good code. >>>>>>> } else { >>>>>>> // use the new code >>>>>>> } >>>>>>> >>>>>>> Best regards, >>>>>>> Andrej Golovnin >>>>>>> >>>>>>>> [2] >>>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-2x.png >>>>>>>> >>>>>>>> >>>>>>>> [3] >>>>>>>> http://cr.openjdk.java.net/~alexsch/8165594/screenshots/icons-windows-classic-4x.png >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 23 13:14:45 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Sep 2016 16:14:45 +0300 Subject: [9] Review request for 8165485 Bad rendering of Swing UI controls with Motif L&F on HiDPI display In-Reply-To: References: <8e3b8dd0-55c7-ee33-e34f-59062f3710b8@oracle.com> <9c7180d7-7184-84f5-5f77-bf07c99ddc30@oracle.com> <4aed5a0f-2810-e57c-4140-e69d0e996c1b@oracle.com> <75b22fb4-b7c5-5414-2258-7b28ed09edbd@oracle.com> Message-ID: <895691f6-7732-858e-0125-73654cf35858@oracle.com> Looks fine. Please file a bug to update the code related to scrollbars. They looks different from the x1 version(take a look to the borders and buttons). On 09.09.16 9:07, Andrej Golovnin wrote: > Hi Alexandr, > > this looks much better now. Thanks! > > Best regards, > Andrej Golovnin > > > On Thu, Sep 8, 2016 at 9:52 PM, Alexandr Scherbatiy > wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8165485/webrev.02 >> >> - shadow lines are updated >> - round line end decoration is changed to draw just a point >> >> [1], [2], and [3] screenshots show difference between icons >> drawing before and after the fix for scales 1x, 2x, and 4x. >> >> [1] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_02.png >> [2] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_02.png >> [3] >> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_02.png >> >> Thanks, >> Alexandr. >> >> >> On 9/7/2016 8:43 PM, Alexandr Scherbatiy wrote: >>> >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8165485/webrev.01 >>> >>> Round line end decoration is used to draw combo box and scroll bar >>> icons. >>> >>> [1], [2], and [3] screenshots show difference between icons >>> drawing before and after the fix for scales 1x, 2x, and 4x. >>> >>> [1] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x_01.png >>> [2] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x_01.png >>> [3] >>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x_01.png >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/7/2016 7:54 PM, Phil Race wrote: >>>> >>>> drawPolyline does not seem to be an option here because of the different >>>> colours. >>>> Filling custom shapes may be overkill. Round looks to me to be the best >>>> of these three. >>>> >>>> -phil. >>>> >>>> >>>> On 9/7/2016 9:19 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> On 9/6/2016 6:10 PM, Sergey Bylokhov wrote: >>>>>> >>>>>> It seems that there are some small artifacts on some of the components, >>>>>> please take a look to the corners of the selected checkbox. In 1x the >>>>>> corners have correct edges but in x2,x4 there are some missing pixels. >>>>>> Similar issue is in the text area(take a look to the white border). >>>>> >>>>> Links [1], [2], and [3] shows drawing the scroll bar buttons using >>>>> different types of a line ends decoration (cap, round, and square). All of >>>>> them have one or another drawing artifact with scales 2 and 4. >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-butt.png >>>>> [2] >>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-round.png >>>>> [3] >>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/motif-icons-cap-square.png >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 06.09.16 13:18, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165485 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8165485/webrev.00 >>>>>>> >>>>>>> The icons drawing is changed to use ovals and polygons for >>>>>>> JRadioButton, JCheckBox, JComboBox, and JScrollBar. >>>>>>> >>>>>>> The screenshots [1], [2], and [3] show difference between icons >>>>>>> drawing before and after the fix for scales 1x, 2x, and 4x. >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-1x.png >>>>>>> [2] >>>>>>> >>>>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-2x.png >>>>>>> [3] >>>>>>> >>>>>>> http://cr.openjdk.java.net/~alexsch/8165485/screenshots/icons-motif-4x.png >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 23 13:25:09 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Sep 2016 16:25:09 +0300 Subject: [9] Review request for 8164032 JViewport backing store image is not scaled on HiDPI display In-Reply-To: References: <061b9a2e-3fba-d26c-32a2-21db010cd292@oracle.com> <31edad12-a1aa-4d0d-5b0d-192f04ff9d84@oracle.com> <5a428d73-0d45-3794-61f2-f9f02337d180@oracle.com> <85fd32fb-fb34-414d-8905-721496666d19@oracle.com> Message-ID: <7aa47c73-c24a-f9cc-7962-648ebc2254f1@oracle.com> On 01.09.16 11:25, Alexandr Scherbatiy wrote: > According to your previous comments: > - VolatileImage.validate(GraphicsConfiguration) does not return > IMAGE_INCOMPATIBLE for a graphics configuration which default transform > was changed. > This is because the BufImgVolatileSurfaceManager has acceleration > disabled and it skips check to the valid graphics configuration. > I have filled an issue on it: JDK-8165212 VolatileImage is compatible > with GraphicsConfiguration which transform is changed This looks fine. > > - JViewport.backingStoreImage field is protected so it is not possible > to change its type. Moreover, it is not clear can a someone override > JViewport and use backingStoreImage as a buffered image so he does not > expect that the image content can be lost. > > Could we just file a new issue that the backing store image can be > changed to VolatileImage in JViewport and return to discussion where > graphics scale changing is checked: > http://cr.openjdk.java.net/~alexsch/8164032/webrev.02 I suggest to thinking about more general solution. The code which you write is only one correct solution to create a backbuffer in HiDPI mode(another on is to use VolatileImage). The code itself is not trivial so it will be good to provide some API for this. in the same way as createCompatibleImage() takes care about "color model". > On 8/30/2016 3:54 PM, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8164032/webrev.04/ >> >> The Component.createVolatileImage() is used to create a backing store >> volatile image. >> >> On 8/29/2016 4:18 PM, Sergey Bylokhov wrote: >>> On 19.08.16 10:15, Alexandr Scherbatiy wrote: >>>> On 8/18/2016 3:05 PM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.02 >>>>> >>>>> The backing store image is recreated for the case where scaled sizes >>>>> are changed. >>>> >>>> A version where a VolatileImage is used as a backing store image: >>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.03/ >>> >>> The VI case looks simpler. I guess it can be simplified even more: >>> Peobably this code is unnecessary? >>> } else if (vImg instanceof SunVolatileImage) { >>> 753 SunVolatileImage svImg = (SunVolatileImage) >>> vImg; >>> 754 if >>> (!graphicsConfig.equals(svImg.getGraphicsConfig())) { >>> 755 backingStoreImage = null; >>> 756 } >>> 757 } >>> >>> My understanding is that if VI.validate!=IMAGE_INCOMPATIBLE then we >>> can use it for drawing even if the GC is different? >> Different graphics configurations can have different default >> transforms. The backing store image should be recreated in this case. >> >> Thanks, >> Alexandr. >>> Probably we can reuse Component.createVolatileImage() instead of >>> createImage()? >>> >>> Also can you please check a performance of these two solutions? >>> >>> >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/17/2016 5:05 PM, Sergey Bylokhov wrote: >>>>>> On 17.08.16 14:02, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8164032/webrev.01 >>>>>>> >>>>>>> The generic transform is used for the backing store image scaling. >>>>>> >>>>>> As far as I understand the current fix will not work if the scale was >>>>>> changed(the JViewport will use old buffer)? >>>>>> >>>>>> It seems that the new local AbstractMultiResolutionImage contain only >>>>>> one image variant inside and looks quite similar to the >>>>>> VolatileImage, probably we can change this cache from BufferedImage >>>>>> to VolatileImage? In this case the scale of the VI will be the same >>>>>> as "g": >>>>>> g.getDeviceConfiguration().createCompatibleVolatileImage() >>>>>> >>>>>> >>>>>>> On 8/15/2016 4:58 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Alexandr. >>>>>>>> I doubt that getScaleX/getScaleY can be used here because the scale >>>>>>>> can be generic(translate+rotate+scale). How this cache will work if >>>>>>>> transform will be changed after we save "backingStoreImage"? >>>>>>>> >>>>>>>> On 15.08.16 16:16, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8164032 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8164032/webrev.00 >>>>>>>>> >>>>>>>>> The fix scales the JViewport backing store image when graphics >>>>>>>>> transform is not identity. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri Sep 23 14:01:47 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 23 Sep 2016 17:01:47 +0300 Subject: [9] Review request for 8160160: The menu displayed nothing with the option"-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". In-Reply-To: <16908a3d-030a-14e1-8bb1-ae61bd0ee6dd@oracle.com> References: <18da8062-6386-bc91-b146-0c03329c6f83@oracle.com> <21e7f336-570d-4898-4dbf-00e945ce377a@oracle.com> <9abb3797-a7c2-34d7-3a26-0df4f9df5f17@oracle.com> <06069937-3447-85ee-27e2-fb8429f08bb6@oracle.com> <16908a3d-030a-14e1-8bb1-ae61bd0ee6dd@oracle.com> Message-ID: <79433cde-319b-40cf-a905-aad06246166b@oracle.com> On 23.09.2016 15:52, Sergey Bylokhov wrote: > On 01.09.16 14:21, Semyon Sadetsky wrote: >> The proposed variant is better because if WM effects are switched off we >> will receive this bug again. > > It should not be a problem because we will work in the similar way as > native popup menu. > This version looks fine. Please fila a separate RFE to update menu > implementation to look as the native one, including the shadow. https://bugs.openjdk.java.net/browse/JDK-8166621 Do you like it? > >> >> >> On 8/31/2016 10:29 PM, Sergey Bylokhov wrote: >>> Did you try to force HW popups for GTK l&f? The current proposal will >>> lead to the situation when popup will have different border depending >>> on location in/out of the frame. >>> >>> On 31.08.16 10:54, Semyon Sadetsky wrote: >>>> Hi Sergey, >>>> >>>> This is a valid concern. The fix is updated: >>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.02/ >>>> >>>> --Semyon >>>> >>>> >>>> On 8/30/2016 11:10 PM, Sergey Bylokhov wrote: >>>>> Hi, Semyon. >>>>> I suggest to double check the HW menu/popups, they should have the >>>>> correct border, because they should use the top level window, which >>>>> should contains correct shadow effect. Note that after the fix we >>>>> should not have two borers in such cases. >>>>> >>>>> On 29.08.16 20:11, Alexandr Scherbatiy wrote: >>>>>> >>>>>> The fix looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 8/29/2016 7:08 PM, Semyon Sadetsky wrote: >>>>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.01/ >>>>>>> >>>>>>> return type of ENGINE.finishPainting() changed to Buffered image. >>>>>>> >>>>>>> img.getRGB() returns a primitive not an object. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> >>>>>>> On 8/29/2016 3:45 PM, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 8/29/2016 1:12 PM, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review fix for JDK9: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.00/ >>>>>>>>> >>>>>>>>> The menu border is not painted by GTK Adwaita theme and makes >>>>>>>>> popup >>>>>>>>> menu invisible at some circumstances. To resolve this the GTK >>>>>>>>> menu >>>>>>>>> border color is compared to the menu background color and if the >>>>>>>>> same the border is painted by means of java graphics using a bit >>>>>>>>> different color tone. >>>>>>>> - BufferedImage img = (BufferedImage) ENGINE.finishPainting(); >>>>>>>> if the ENGINE.finishPainting() always returns BufferedImage it >>>>>>>> would be better to change the return type to BufferedImage. >>>>>>>> >>>>>>>> - border == img.getRGB(w / 2, h / 2) >>>>>>>> Could we rely on that img.getRGB(0, h / 2) returns the same >>>>>>>> object >>>>>>>> as the img.getRGB(w / 2, h / 2)? May be it is use equals() methods >>>>>>>> for comparing in this case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Fri Sep 23 15:18:25 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 23 Sep 2016 18:18:25 +0300 Subject: [9] Review request for 8160160: The menu displayed nothing with the option"-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". In-Reply-To: <79433cde-319b-40cf-a905-aad06246166b@oracle.com> References: <18da8062-6386-bc91-b146-0c03329c6f83@oracle.com> <21e7f336-570d-4898-4dbf-00e945ce377a@oracle.com> <9abb3797-a7c2-34d7-3a26-0df4f9df5f17@oracle.com> <06069937-3447-85ee-27e2-fb8429f08bb6@oracle.com> <16908a3d-030a-14e1-8bb1-ae61bd0ee6dd@oracle.com> <79433cde-319b-40cf-a905-aad06246166b@oracle.com> Message-ID: <06706990-d825-2d88-5f5b-ac6517fd2eca@oracle.com> On 23.09.16 17:01, Semyon Sadetsky wrote: > On 23.09.2016 15:52, Sergey Bylokhov wrote: > >> On 01.09.16 14:21, Semyon Sadetsky wrote: >>> The proposed variant is better because if WM effects are switched off we >>> will receive this bug again. >> >> It should not be a problem because we will work in the similar way as >> native popup menu. >> This version looks fine. Please fila a separate RFE to update menu >> implementation to look as the native one, including the shadow. > https://bugs.openjdk.java.net/browse/JDK-8166621 > Do you like it? Yes, it is fine. >> >>> >>> >>> On 8/31/2016 10:29 PM, Sergey Bylokhov wrote: >>>> Did you try to force HW popups for GTK l&f? The current proposal will >>>> lead to the situation when popup will have different border depending >>>> on location in/out of the frame. >>>> >>>> On 31.08.16 10:54, Semyon Sadetsky wrote: >>>>> Hi Sergey, >>>>> >>>>> This is a valid concern. The fix is updated: >>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.02/ >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 8/30/2016 11:10 PM, Sergey Bylokhov wrote: >>>>>> Hi, Semyon. >>>>>> I suggest to double check the HW menu/popups, they should have the >>>>>> correct border, because they should use the top level window, which >>>>>> should contains correct shadow effect. Note that after the fix we >>>>>> should not have two borers in such cases. >>>>>> >>>>>> On 29.08.16 20:11, Alexandr Scherbatiy wrote: >>>>>>> >>>>>>> The fix looks good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 8/29/2016 7:08 PM, Semyon Sadetsky wrote: >>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.01/ >>>>>>>> >>>>>>>> return type of ENGINE.finishPainting() changed to Buffered image. >>>>>>>> >>>>>>>> img.getRGB() returns a primitive not an object. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> >>>>>>>> On 8/29/2016 3:45 PM, Alexandr Scherbatiy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8/29/2016 1:12 PM, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review fix for JDK9: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.00/ >>>>>>>>>> >>>>>>>>>> The menu border is not painted by GTK Adwaita theme and makes >>>>>>>>>> popup >>>>>>>>>> menu invisible at some circumstances. To resolve this the GTK >>>>>>>>>> menu >>>>>>>>>> border color is compared to the menu background color and if the >>>>>>>>>> same the border is painted by means of java graphics using a bit >>>>>>>>>> different color tone. >>>>>>>>> - BufferedImage img = (BufferedImage) ENGINE.finishPainting(); >>>>>>>>> if the ENGINE.finishPainting() always returns BufferedImage it >>>>>>>>> would be better to change the return type to BufferedImage. >>>>>>>>> >>>>>>>>> - border == img.getRGB(w / 2, h / 2) >>>>>>>>> Could we rely on that img.getRGB(0, h / 2) returns the same >>>>>>>>> object >>>>>>>>> as the img.getRGB(w / 2, h / 2)? May be it is use equals() methods >>>>>>>>> for comparing in this case. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Fri Sep 23 15:48:18 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 23 Sep 2016 18:48:18 +0300 Subject: [9] Review request for 8160160: The menu displayed nothing with the option"-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". In-Reply-To: <06706990-d825-2d88-5f5b-ac6517fd2eca@oracle.com> References: <18da8062-6386-bc91-b146-0c03329c6f83@oracle.com> <21e7f336-570d-4898-4dbf-00e945ce377a@oracle.com> <9abb3797-a7c2-34d7-3a26-0df4f9df5f17@oracle.com> <06069937-3447-85ee-27e2-fb8429f08bb6@oracle.com> <16908a3d-030a-14e1-8bb1-ae61bd0ee6dd@oracle.com> <79433cde-319b-40cf-a905-aad06246166b@oracle.com> <06706990-d825-2d88-5f5b-ac6517fd2eca@oracle.com> Message-ID: On 23.09.2016 18:18, Sergey Bylokhov wrote: > On 23.09.16 17:01, Semyon Sadetsky wrote: >> On 23.09.2016 15:52, Sergey Bylokhov wrote: >> >>> On 01.09.16 14:21, Semyon Sadetsky wrote: >>>> The proposed variant is better because if WM effects are switched >>>> off we >>>> will receive this bug again. >>> >>> It should not be a problem because we will work in the similar way as >>> native popup menu. >>> This version looks fine. Please fila a separate RFE to update menu >>> implementation to look as the native one, including the shadow. >> https://bugs.openjdk.java.net/browse/JDK-8166621 >> Do you like it? > > Yes, it is fine. > Enjoy! >>> >>>> >>>> >>>> On 8/31/2016 10:29 PM, Sergey Bylokhov wrote: >>>>> Did you try to force HW popups for GTK l&f? The current proposal will >>>>> lead to the situation when popup will have different border depending >>>>> on location in/out of the frame. >>>>> >>>>> On 31.08.16 10:54, Semyon Sadetsky wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> This is a valid concern. The fix is updated: >>>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.02/ >>>>>> >>>>>> --Semyon >>>>>> >>>>>> >>>>>> On 8/30/2016 11:10 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Semyon. >>>>>>> I suggest to double check the HW menu/popups, they should have the >>>>>>> correct border, because they should use the top level window, which >>>>>>> should contains correct shadow effect. Note that after the fix we >>>>>>> should not have two borers in such cases. >>>>>>> >>>>>>> On 29.08.16 20:11, Alexandr Scherbatiy wrote: >>>>>>>> >>>>>>>> The fix looks good to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 8/29/2016 7:08 PM, Semyon Sadetsky wrote: >>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.01/ >>>>>>>>> >>>>>>>>> return type of ENGINE.finishPainting() changed to Buffered image. >>>>>>>>> >>>>>>>>> img.getRGB() returns a primitive not an object. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8/29/2016 3:45 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8/29/2016 1:12 PM, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160160 >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8160160/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The menu border is not painted by GTK Adwaita theme and makes >>>>>>>>>>> popup >>>>>>>>>>> menu invisible at some circumstances. To resolve this the GTK >>>>>>>>>>> menu >>>>>>>>>>> border color is compared to the menu background color and if >>>>>>>>>>> the >>>>>>>>>>> same the border is painted by means of java graphics using a >>>>>>>>>>> bit >>>>>>>>>>> different color tone. >>>>>>>>>> - BufferedImage img = (BufferedImage) ENGINE.finishPainting(); >>>>>>>>>> if the ENGINE.finishPainting() always returns BufferedImage it >>>>>>>>>> would be better to change the return type to BufferedImage. >>>>>>>>>> >>>>>>>>>> - border == img.getRGB(w / 2, h / 2) >>>>>>>>>> Could we rely on that img.getRGB(0, h / 2) returns the same >>>>>>>>>> object >>>>>>>>>> as the img.getRGB(w / 2, h / 2)? May be it is use equals() >>>>>>>>>> methods >>>>>>>>>> for comparing in this case. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From peter.brunet at oracle.com Fri Sep 23 19:46:28 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 23 Sep 2016 14:46:28 -0500 Subject: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible Message-ID: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com> Please review the patch for JDK-8160893. Bug: https://bugs.openjdk.java.net/browse/JDK-8160893 Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.01/ This patch adds support to post menu related events: kAXMenuOpenedNotification, kAXMenuClosedNotification, and kAXMenuItemSelectedNotification. Also note that these changes had impacts on the current combo box behavior so you'll see combo boxes filtered out from this fix. The combo box behavior is currently broken and will be fixed at a later date but at least for now I didn't want this patch to change that (broken) behavior. TiA, Pete From peter.brunet at oracle.com Fri Sep 23 23:59:22 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 23 Sep 2016 18:59:22 -0500 Subject: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible In-Reply-To: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com> References: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com> Message-ID: <99535873-b42a-2b16-16c9-0aa23ca7ea25@oracle.com> New webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/ I added a null check at line 688 like the one at line 693. Pete On 9/23/16 2:46 PM, Pete Brunet wrote: > Please review the patch for JDK-8160893. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160893 > Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.01/ > > This patch adds support to post menu related events: > kAXMenuOpenedNotification, kAXMenuClosedNotification, and > kAXMenuItemSelectedNotification. Also note that these changes had > impacts on the current combo box behavior so you'll see combo boxes > filtered out from this fix. The combo box behavior is currently broken > and will be fixed at a later date but at least for now I didn't want > this patch to change that (broken) behavior. > > TiA, > Pete From anton.tarasov at jetbrains.com Mon Sep 26 12:22:06 2016 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Mon, 26 Sep 2016 15:22:06 +0300 Subject: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible In-Reply-To: <99535873-b42a-2b16-16c9-0aa23ca7ea25@oracle.com> References: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com> <99535873-b42a-2b16-16c9-0aa23ca7ea25@oracle.com> Message-ID: <3c17f183-b869-b496-8679-2204429bde0f@jetbrains.com> Hi Pete, The fix looks fine to me. Thanks, Anton. On 9/24/2016 2:59 AM, Pete Brunet wrote: > New webrev: > http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/ > > I added a null check at line 688 like the one at line 693. > > Pete > > On 9/23/16 2:46 PM, Pete Brunet wrote: >> Please review the patch for JDK-8160893. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160893 >> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.01/ >> >> This patch adds support to post menu related events: >> kAXMenuOpenedNotification, kAXMenuClosedNotification, and >> kAXMenuItemSelectedNotification. Also note that these changes had >> impacts on the current combo box behavior so you'll see combo boxes >> filtered out from this fix. The combo box behavior is currently broken >> and will be fixed at a later date but at least for now I didn't want >> this patch to change that (broken) behavior. >> >> TiA, >> Pete From Sergey.Bylokhov at oracle.com Tue Sep 27 18:13:10 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 27 Sep 2016 21:13:10 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: References: <0798A861-8586-4DAA-92E5-08F540B7499F@cbfiddle.com> <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> Message-ID: <97f24977-1e4f-a010-76a9-f4d9298f02b5@oracle.com> The public API Looks fine. On 21.09.16 16:06, Alexandr Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all_01 > The public API remains unchanged: > http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api > > ParagraphView and GlyphPainter2 are updated to return Recatngel2D shape > for ParagraphView.modelToView(...) call. > However, the returned rectangle has int coordinates when "i18n" is set > just because TextLayout.getCaretInfo(hit) method in class GlyphPainter2 > returns int caret info. > > Thanks, > Alexandr. > > On 9/20/2016 2:41 PM, Semyon Sadetsky wrote: >> >> Yet another question: Why the floating point API doesn't work for >> JTextPane? >> >> Also it doesn't work for JTextArea, JTextField and JTextPane if i18n >> is on. >> >> --Semyon >> >> >> On 12.09.2016 15:19, Alexandr Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all >>> public API changes: >>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api >>> >>> - @since 9 tag is added to new methods. >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/10/2016 2:36 AM, Philip Race wrote: >>>> - * Returns the tab size set for the document, defaulting to 8. >>>> - * >>>> - * @implSpec This implementation calls {@link #getTabSize() >>>> getTabSize()}. >>>> - * >>>> - * @return the tab size >>>> - */ >>>> - protected float getFractionalTabSize() { >>>> - return getTabSize(); >>>> - } >>>> - >>>> >>>> >>>> It seems this was added only in 9. >>>> Since I think I remember that asking a question about it. >>>> I note it has no @since. Moot if you are really removing it but >>>> what has it to do with the rest of this change ? >>>> >>>> -phil. >>>> >>>> On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> all changes: http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >>>>> public API changes: >>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >>>>> >>>>> - reflection is used to detect do methods with floating point API >>>>> need to be called. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>>>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> Alexander, did you consider possibility to check if method is >>>>>>>>> really over-riden then to use the old API? >>>>>>>>> >>>>>>>> Could you give a sample how it can be done? >>>>>>> I think it is possible to use a reflection to found the latest >>>>>>> overridden method which uses int coordinates and check does it >>>>>>> has a corresponding overridden method with floating point >>>>>>> arguments. But I doubt that it is a good solution. >>>>>> yes. You could use: >>>>>> useFloatingPointAPI = >>>>>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>>>>> ...).getDeclaringClass()); >>>>>> >>>>>> Otherwise, with high probability your new API will never be used. >>>>>> >>>>>> --Semyon >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Alexander, >>>>>>>>>>> >>>>>>>>>>> It is a good style to add a note recommending what to use >>>>>>>>>>> instead of the method which is being deprecated. >>>>>>>>>>> >>>>>>>>>> Could you review the updated public API there "replaced by" >>>>>>>>>> notes are added to the deprecated methods: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>>>>> >>>>>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>>>>> introduced and moreover is set to false by default. If the >>>>>>>>>>> old API is used then it doesn't matter which value it has >>>>>>>>>>> because the float values will receive ints. And for the new >>>>>>>>>>> API I would expect everything having the float precision, and >>>>>>>>>>> it is unclear what may be the reason to switch it off back to >>>>>>>>>>> integer. Especially if >>>>>>>>>>> >>>>>>>>>>> " This allows to draw text properly using graphics with >>>>>>>>>>> scaled transform." >>>>>>>>>>> >>>>>>>>>>> so an improper mode is the default? >>>>>>>>>>> >>>>>>>>>> This is has been discussed below. For example new >>>>>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int >>>>>>>>>> p1) with floating point coordinates is added to the PlainView >>>>>>>>>> which has the same method with int coordinates. Suppose >>>>>>>>>> someone has a custom password component which uses and old >>>>>>>>>> methods with int coordinates. >>>>>>>>>> -------- >>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>> >>>>>>>>>> @Override >>>>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>>>> // draw echo chars >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> -------- >>>>>>>>>> >>>>>>>>>> If we start to call drawSelectedText() with floating point >>>>>>>>>> values the customization of old components will not be used >>>>>>>>>> and the CustomPasswordField from the example starts to show >>>>>>>>>> real text instead of echo chars. This is incompatible change >>>>>>>>>> with previous JDK releases. >>>>>>>>>> >>>>>>>>>> The solution is to switch to new floating point API only when >>>>>>>>>> it is known that a component properly overrides new methods >>>>>>>>>> with floating point arguments. After that the >>>>>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>>>>> >>>>>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>>>>> sure that drawSelectedText() methods with floating point >>>>>>>>>> arguments is overridden. So Swing standard text components are >>>>>>>>>> switched to use new floating point API. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>>>>> OK .. I do not know enough about how modelToView is used by >>>>>>>>>>>>> Swing >>>>>>>>>>>>> to know what is really needed here. Someone with a bit more >>>>>>>>>>>>> Swing >>>>>>>>>>>>> background needs to chime in. I was encouraged that the >>>>>>>>>>>>> *API* surface >>>>>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>>>>> webrev >>>>>>>>>>>>> but maybe that is because you did not include everything. >>>>>>>>>>>>> For example >>>>>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>>>>> PasswordView >>>>>>>>>>>>> since that is a public class would become part of the spec >>>>>>>>>>>>> .. would they not ? >>>>>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>>>>> >>>>>>>>>>>>> Put another way I was looking for what the content of the >>>>>>>>>>>>> CCC would be. >>>>>>>>>>>> Here is the updated version of the public API change >>>>>>>>>>>> which includes overridden deprecated methods: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> -phil. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>>>>> modelToView >>>>>>>>>>>>>>> That will just hold this up as the reasoning behind >>>>>>>>>>>>>>> needing those changes is not something >>>>>>>>>>>>>>> I have yet been able to convince myself about - even >>>>>>>>>>>>>>> after reading your last email. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>>>>> p)) is not included in the current fix. I only moved the >>>>>>>>>>>>>> new methods JTextComponent.modelToView2D(int >>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret >>>>>>>>>>>>>> to this fix. These methods are used not only for caret but >>>>>>>>>>>>>> in other cases like mouse handling, text dragging and others. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>>>>> - public >>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>>>>> are added >>>>>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API >>>>>>>>>>>>>>>> in standard Java text components >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point >>>>>>>>>>>>>>>>>> I am not sure what we are gaining >>>>>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> It affects only the methods that the 3rd party code >>>>>>>>>>>>>>>>>> can over-ride >>>>>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal >>>>>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>>>>> Is there any other method that matters / is used in >>>>>>>>>>>>>>>>>> this way ? >>>>>>>>>>>>>>>>> I have found the following methods which relate to >>>>>>>>>>>>>>>>> text drawing, can be overridden and could have floating >>>>>>>>>>>>>>>>> point coordinates: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is also a method which relates to a caret >>>>>>>>>>>>>>>>> position in a text: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point >>>>>>>>>>>>>>>>> p) >>>>>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they >>>>>>>>>>>>>>>>>> will get the JDK >>>>>>>>>>>>>>>>>> super-class version, thus losing any customisation >>>>>>>>>>>>>>>>>> they might have done >>>>>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class >>>>>>>>>>>>>>>>> which overrides >>>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>>> and draws echo chars instead of text. >>>>>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and >>>>>>>>>>>>>>>>>> always call the float versions >>>>>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>>>>> 118 if (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>>>>>> 121 p0-elem.getStartOffset(), >>>>>>>>>>>>>>>>>> 122 p1-elem.getStartOffset()); >>>>>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>>>>> method is: >>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace >>>>>>>>>>>>>>>>> at the end >>>>>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>>>>> make calls >>>>>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>>>>> * {@code drawSelectedText} so that the way >>>>>>>>>>>>>>>>> selected and >>>>>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Applications can rely on this behaviour and stopping >>>>>>>>>>>>>>>>> to call the >>>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>>> with int coordinates will be incompatible change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Is there a more fine grained way to detect >>>>>>>>>>>>>>>>>>>> programmer awareness or lack of awareness of the new >>>>>>>>>>>>>>>>>>>> methods? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Here is a slightly updated version which adds >>>>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>>>>> and enabled for standard Swing text component >>>>>>>>>>>>>>>>>>> classes. This has advantage that selection will work >>>>>>>>>>>>>>>>>>> for text component in users applications on HiDPI >>>>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> But it still has the same problem. Applications >>>>>>>>>>>>>>>>>>> which use custom View classes needs to updated them >>>>>>>>>>>>>>>>>>> to implement corresponding text drawing methods with >>>>>>>>>>>>>>>>>>> floating point arguments and enable the floating >>>>>>>>>>>>>>>>>>> point API usage. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 >>>>>>>>>>>>>>>>>>>>> Provide public API for text related methods in >>>>>>>>>>>>>>>>>>>>> SwingUtilities2 >>>>>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think that this can be handled in the following way: >>>>>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>>>>> By default it is false and all work as before. >>>>>>>>>>>>>>>>>>>>> The issue with selected text is reproduced. >>>>>>>>>>>>>>>>>>>>> An application with enabled property does not >>>>>>>>>>>>>>>>>>>>> have issue with the selected text but a user should >>>>>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>>>>> all methods with floating point values if he >>>>>>>>>>>>>>>>>>>>> uses corresponding methods with integer values. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Here is a proposed solution where new public >>>>>>>>>>>>>>>>>>>>> system property >>>>>>>>>>>>>>>>>>>>> "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and >>>>>>>>>>>>>>>>>>>>>>> the 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each >>>>>>>>>>>>>>>>>>>>>>> glyph advance in >>>>>>>>>>>>>>>>>>>>>>> StandardGlyphVector.initPositions() method is >>>>>>>>>>>>>>>>>>>>>>> 99.999992. >>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, >>>>>>>>>>>>>>>>>>>>>>> advance, N * advance); >>>>>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float >>>>>>>>>>>>>>>>>>>>>>> position 99.999998 is shifted one pixel left >>>>>>>>>>>>>>>>>>>>>>> which affects the text selection code in Swing: >>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero >>>>>>>>>>>>>>>>>>>>>> translate the transformed coordinates are: >>>>>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but >>>>>>>>>>>>>>>>>>>>>>>>> there still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text >>>>>>>>>>>>>>>>>>>>>>>>> related. Can you take a look. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of >>>>>>>>>>>>>>>>>>>>>>>> the text. >>>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related >>>>>>>>>>>>>>>>>>>>>>>>>> to the fact that char width can be fractional >>>>>>>>>>>>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > -- Best regards, Sergey. From philip.race at oracle.com Tue Sep 27 20:02:08 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 27 Sep 2016 13:02:08 -0700 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <97f24977-1e4f-a010-76a9-f4d9298f02b5@oracle.com> References: <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> <97f24977-1e4f-a010-76a9-f4d9298f02b5@oracle.com> Message-ID: <57EAD040.5020101@oracle.com> I have looked at the full webrev and it seems fine. -phil. On 9/27/16, 11:13 AM, Sergey Bylokhov wrote: > The public API Looks fine. > > On 21.09.16 16:06, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all_01 >> The public API remains unchanged: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api >> >> ParagraphView and GlyphPainter2 are updated to return Recatngel2D shape >> for ParagraphView.modelToView(...) call. >> However, the returned rectangle has int coordinates when "i18n" is set >> just because TextLayout.getCaretInfo(hit) method in class GlyphPainter2 >> returns int caret info. >> >> Thanks, >> Alexandr. >> >> On 9/20/2016 2:41 PM, Semyon Sadetsky wrote: >>> >>> Yet another question: Why the floating point API doesn't work for >>> JTextPane? >>> >>> Also it doesn't work for JTextArea, JTextField and JTextPane if i18n >>> is on. >>> >>> --Semyon >>> >>> >>> On 12.09.2016 15:19, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> all changes: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all >>>> public API changes: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api >>>> >>>> - @since 9 tag is added to new methods. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 9/10/2016 2:36 AM, Philip Race wrote: >>>>> - * Returns the tab size set for the document, defaulting to 8. >>>>> - * >>>>> - * @implSpec This implementation calls {@link #getTabSize() >>>>> getTabSize()}. >>>>> - * >>>>> - * @return the tab size >>>>> - */ >>>>> - protected float getFractionalTabSize() { >>>>> - return getTabSize(); >>>>> - } >>>>> - >>>>> >>>>> >>>>> It seems this was added only in 9. >>>>> Since I think I remember that asking a question about it. >>>>> I note it has no @since. Moot if you are really removing it but >>>>> what has it to do with the rest of this change ? >>>>> >>>>> -phil. >>>>> >>>>> On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> all changes: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >>>>>> public API changes: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >>>>>> >>>>>> - reflection is used to detect do methods with floating point API >>>>>> need to be called. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>>>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> Alexander, did you consider possibility to check if method is >>>>>>>>>> really over-riden then to use the old API? >>>>>>>>>> >>>>>>>>> Could you give a sample how it can be done? >>>>>>>> I think it is possible to use a reflection to found the latest >>>>>>>> overridden method which uses int coordinates and check does it >>>>>>>> has a corresponding overridden method with floating point >>>>>>>> arguments. But I doubt that it is a good solution. >>>>>>> yes. You could use: >>>>>>> useFloatingPointAPI = >>>>>>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>>>>>> ...).getDeclaringClass()); >>>>>>> >>>>>>> Otherwise, with high probability your new API will never be used. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>> >>>>>>>>>>>> It is a good style to add a note recommending what to use >>>>>>>>>>>> instead of the method which is being deprecated. >>>>>>>>>>>> >>>>>>>>>>> Could you review the updated public API there "replaced by" >>>>>>>>>>> notes are added to the deprecated methods: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>>>>>> introduced and moreover is set to false by default. If the >>>>>>>>>>>> old API is used then it doesn't matter which value it has >>>>>>>>>>>> because the float values will receive ints. And for the new >>>>>>>>>>>> API I would expect everything having the float precision, and >>>>>>>>>>>> it is unclear what may be the reason to switch it off back to >>>>>>>>>>>> integer. Especially if >>>>>>>>>>>> >>>>>>>>>>>> " This allows to draw text properly using graphics with >>>>>>>>>>>> scaled transform." >>>>>>>>>>>> >>>>>>>>>>>> so an improper mode is the default? >>>>>>>>>>>> >>>>>>>>>>> This is has been discussed below. For example new >>>>>>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int >>>>>>>>>>> p1) with floating point coordinates is added to the PlainView >>>>>>>>>>> which has the same method with int coordinates. Suppose >>>>>>>>>>> someone has a custom password component which uses and old >>>>>>>>>>> methods with int coordinates. >>>>>>>>>>> -------- >>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>> >>>>>>>>>>> @Override >>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>>>>> // draw echo chars >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> -------- >>>>>>>>>>> >>>>>>>>>>> If we start to call drawSelectedText() with floating point >>>>>>>>>>> values the customization of old components will not be used >>>>>>>>>>> and the CustomPasswordField from the example starts to show >>>>>>>>>>> real text instead of echo chars. This is incompatible change >>>>>>>>>>> with previous JDK releases. >>>>>>>>>>> >>>>>>>>>>> The solution is to switch to new floating point API only when >>>>>>>>>>> it is known that a component properly overrides new methods >>>>>>>>>>> with floating point arguments. After that the >>>>>>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>>>>>> >>>>>>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>>>>>> sure that drawSelectedText() methods with floating point >>>>>>>>>>> arguments is overridden. So Swing standard text components are >>>>>>>>>>> switched to use new floating point API. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>>>>>> OK .. I do not know enough about how modelToView is used by >>>>>>>>>>>>>> Swing >>>>>>>>>>>>>> to know what is really needed here. Someone with a bit more >>>>>>>>>>>>>> Swing >>>>>>>>>>>>>> background needs to chime in. I was encouraged that the >>>>>>>>>>>>>> *API* surface >>>>>>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>>>>>> webrev >>>>>>>>>>>>>> but maybe that is because you did not include everything. >>>>>>>>>>>>>> For example >>>>>>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>>>>>> PasswordView >>>>>>>>>>>>>> since that is a public class would become part of the spec >>>>>>>>>>>>>> .. would they not ? >>>>>>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Put another way I was looking for what the content of the >>>>>>>>>>>>>> CCC would be. >>>>>>>>>>>>> Here is the updated version of the public API change >>>>>>>>>>>>> which includes overridden deprecated methods: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>>>>>> modelToView >>>>>>>>>>>>>>>> That will just hold this up as the reasoning behind >>>>>>>>>>>>>>>> needing those changes is not something >>>>>>>>>>>>>>>> I have yet been able to convince myself about - even >>>>>>>>>>>>>>>> after reading your last email. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> p)) is not included in the current fix. I only moved the >>>>>>>>>>>>>>> new methods JTextComponent.modelToView2D(int >>>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret >>>>>>>>>>>>>>> to this fix. These methods are used not only for caret but >>>>>>>>>>>>>>> in other cases like mouse handling, text dragging and >>>>>>>>>>>>>>> others. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>>>>>> - public >>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>>>>>> are added >>>>>>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API >>>>>>>>>>>>>>>>> in standard Java text components >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point >>>>>>>>>>>>>>>>>>> I am not sure what we are gaining >>>>>>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It affects only the methods that the 3rd party code >>>>>>>>>>>>>>>>>>> can over-ride >>>>>>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal >>>>>>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>>>>>> Is there any other method that matters / is used in >>>>>>>>>>>>>>>>>>> this way ? >>>>>>>>>>>>>>>>>> I have found the following methods which relate to >>>>>>>>>>>>>>>>>> text drawing, can be overridden and could have floating >>>>>>>>>>>>>>>>>> point coordinates: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There is also a method which relates to a caret >>>>>>>>>>>>>>>>>> position in a text: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> p) >>>>>>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they >>>>>>>>>>>>>>>>>>> will get the JDK >>>>>>>>>>>>>>>>>>> super-class version, thus losing any customisation >>>>>>>>>>>>>>>>>>> they might have done >>>>>>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class >>>>>>>>>>>>>>>>>> which overrides >>>>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>>>> and draws echo chars instead of text. >>>>>>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and >>>>>>>>>>>>>>>>>>> always call the float versions >>>>>>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>>>>>> 112 p1 = >>>>>>>>>>>>>>>>>>> Math.min(getDocument().getLength(), p1); >>>>>>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>>>>>> 118 if >>>>>>>>>>>>>>>>>>> (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>>>>>> 120 x = >>>>>>>>>>>>>>>>>>> Utilities.drawComposedText(this, attr, g, x, y, >>>>>>>>>>>>>>>>>>> 121 >>>>>>>>>>>>>>>>>>> p0-elem.getStartOffset(), >>>>>>>>>>>>>>>>>>> 122 >>>>>>>>>>>>>>>>>>> p1-elem.getStartOffset()); >>>>>>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>>>>>> method is: >>>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace >>>>>>>>>>>>>>>>>> at the end >>>>>>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>>>>>> make calls >>>>>>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>>>>>> * {@code drawSelectedText} so that the way >>>>>>>>>>>>>>>>>> selected and >>>>>>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Applications can rely on this behaviour and stopping >>>>>>>>>>>>>>>>>> to call the >>>>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>>>> with int coordinates will be incompatible change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Is there a more fine grained way to detect >>>>>>>>>>>>>>>>>>>>> programmer awareness or lack of awareness of the new >>>>>>>>>>>>>>>>>>>>> methods? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Here is a slightly updated version which adds >>>>>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>>>>>> and enabled for standard Swing text component >>>>>>>>>>>>>>>>>>>> classes. This has advantage that selection will work >>>>>>>>>>>>>>>>>>>> for text component in users applications on HiDPI >>>>>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> But it still has the same problem. Applications >>>>>>>>>>>>>>>>>>>> which use custom View classes needs to updated them >>>>>>>>>>>>>>>>>>>> to implement corresponding text drawing methods with >>>>>>>>>>>>>>>>>>>> floating point arguments and enable the floating >>>>>>>>>>>>>>>>>>>> point API usage. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 >>>>>>>>>>>>>>>>>>>>>> Provide public API for text related methods in >>>>>>>>>>>>>>>>>>>>>> SwingUtilities2 >>>>>>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think that this can be handled in the >>>>>>>>>>>>>>>>>>>>>> following way: >>>>>>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>>>>>> By default it is false and all work as before. >>>>>>>>>>>>>>>>>>>>>> The issue with selected text is reproduced. >>>>>>>>>>>>>>>>>>>>>> An application with enabled property does not >>>>>>>>>>>>>>>>>>>>>> have issue with the selected text but a user should >>>>>>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>>>>>> all methods with floating point values if he >>>>>>>>>>>>>>>>>>>>>> uses corresponding methods with integer values. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Here is a proposed solution where new public >>>>>>>>>>>>>>>>>>>>>> system property >>>>>>>>>>>>>>>>>>>>>> "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and >>>>>>>>>>>>>>>>>>>>>>>> the 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each >>>>>>>>>>>>>>>>>>>>>>>> glyph advance in >>>>>>>>>>>>>>>>>>>>>>>> StandardGlyphVector.initPositions() method is >>>>>>>>>>>>>>>>>>>>>>>> 99.999992. >>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, >>>>>>>>>>>>>>>>>>>>>>>> advance, N * advance); >>>>>>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float >>>>>>>>>>>>>>>>>>>>>>>> position 99.999998 is shifted one pixel left >>>>>>>>>>>>>>>>>>>>>>>> which affects the text selection code in Swing: >>>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero >>>>>>>>>>>>>>>>>>>>>>> translate the transformed coordinates are: >>>>>>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but >>>>>>>>>>>>>>>>>>>>>>>>>> there still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text >>>>>>>>>>>>>>>>>>>>>>>>>> related. Can you take a look. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of >>>>>>>>>>>>>>>>>>>>>>>>> the text. >>>>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related >>>>>>>>>>>>>>>>>>>>>>>>>>> to the fact that char width can be fractional >>>>>>>>>>>>>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > > From philip.race at oracle.com Tue Sep 27 21:02:29 2016 From: philip.race at oracle.com (Philip Race) Date: Tue, 27 Sep 2016 14:02:29 -0700 Subject: [9] Review request for 8163124 Add floating point API support to javax.swing.text.Caret In-Reply-To: <36c65570-c213-9d7c-b146-3ca8a0621a6d@oracle.com> References: <11f274ad-27ae-3330-7a7f-93f66c2ecc6d@oracle.com> <57A8FD3A.5040700@oracle.com> <4932b261-ec98-435d-3271-9de33e30bd6e@oracle.com> <57AA3DEE.1090602@oracle.com> <1c855e83-f713-d21f-ccfc-3a253713e932@oracle.com> <8e8aec05-73a1-a60b-d0a2-1b7590c75d71@oracle.com> <57B4B1D2.9030702@oracle.com> <85e9924e-221f-9404-f4b1-56bfea67730b@oracle.com> <57BE88E8.1070409@oracle.com> <36c65570-c213-9d7c-b146-3ca8a0621a6d@oracle.com> Message-ID: <57EADE65.9000207@oracle.com> Somewhat contrived but OK. Is there an up-to-date webrev for this proposal ? -phil. On 9/21/16, 9:21 AM, Alexandr Scherbatiy wrote: > > When a font size is small and UI scale is large it is possible that a > char advance can be smaller than 1. For example, if font is Dialog > plain with size 2 and UI scale is 32 the 'j' char width has value > 0.47. For this case saved int caret position which is used to move a > caret to next line does not have enough precision to be placed between > the first and the second 'j' char. > > I have prepared the test [1]. It should be run with the applied patch > [2] for the fix JDK-8156217 because it contains implementation of the > TextComponent.modelToView2D(pos) method. The test shows a JTextArea > with two lines "jjjjjjjjjjj" and uses a custom caret implementation. > Pressing the arrow key to the right and down leads that the caret is > moved before the first character on the second line instead of the > second character. > > [1] > http://cr.openjdk.java.net/~alexsch/8163124/samples/MagicCaretPositionTest.java > [2] http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all_01 > > Thanks, > Alexandr. > > > On 8/25/2016 8:58 AM, Philip Race wrote: >> On 8/24/16, 9:45 AM, Alexander Scherbatiy wrote: >>> On 17/08/16 22:49, Phil Race wrote: >>>> Sorry, but I have had some trouble trying to picture this. >>>> If the caret is between "b" and "c", being off by a fractional >>>> value seems >>>> unlikely to make it jump to between "a" and "b". >>>> It might now "round" to somewhere in the trailing pixel of "b" but >>>> nowhere >>>> near the leading edge. >>> I suppose yes. >>> >>> Another case is when a caret is in the center of the "b". In this >>> case it can be moved to another character if fractional values are >>> not taken into account. However, may be it does not matter which >>> character "a" or "c" would be chosen because they have nearly the >>> same distance to the center of the "b". >> >> Indeed. And I think that is no different than today that "in the >> middle" means >> it is 50:50 which way it goes with integers too. >> Also unless this position was set by some code that just picked a >> position >> out thin air, I would expect this to always be "between" the >> characters as >> a result of normal calculation of the caret. >> >> -phil. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -phil. >>>> >>>> >>>> On 08/11/2016 09:55 AM, Alexandr Scherbatiy wrote: >>>>> >>>>> I am sorry. The JTextComponent.viewToModel(Point) method returns >>>>> the closest location for the provided point. If the caret position >>>>> is N.25 the distance to the right character is 0.25 and to the >>>>> left one is greater than 0.75. Even in for the worst case the >>>>> distance to the right character is less than 1 and to the left is >>>>> greater than 1 (suppose a character width is greater than 1). For >>>>> the provided cases the caret should always be placed in the proper >>>>> closest location. >>>>> >>>>> There is just a question could a user just compare the provided >>>>> magic caret position (which coordinates are rounded) with the >>>>> result of rectangle from the method >>>>> JTextComponent.modelToView2(position) which returns the floating >>>>> point positions. So for the same position the rounded point can be >>>>> (N, y) and the rectangle can have bounds (N.25, y, w, h). >>>>> Comparing these results can lead that the magic caret point does >>>>> not belong to the provided rectangle but it is definitely that the >>>>> x coordinate of this rectangle is the closest one to this point. >>>>> >>>>> By the way, I can merge the added JTextComponent.modelToView2D(int >>>>> pos)/viewToModel2D(Point2D pt) public methods with the fix for the >>>>> 8156217 Selected text is shifted on HiDPI display >>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04/ >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/10/2016 5:22 PM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Suppose there is a text area with two lines with the same text: >>>>>> abcdefghij >>>>>> abcdefghij >>>>>> >>>>>> The char 'c' on the fist line has offset 2 and some coordinates >>>>>> (x1, y1) where x1 can have a floating point values like 21.25. >>>>>> The char 'c' on the second line has offset 13 and coordinates >>>>>> (x2, y2) where x2 is equal to x1. >>>>>> >>>>>> Setting the caret to the first 'c' character sets the magic caret >>>>>> position to (round (x1), round (y1)) position. >>>>>> Pressing the arrow down key calculates the new y position and >>>>>> uses the x position from the magic caret position which is >>>>>> round(21.5) = 21. >>>>>> Now the new offset can be calculated as >>>>>> textComponent.viewToModel(new Point(21, newY)) which returns >>>>>> offset 12 for char 'b' on the second line instead the offset 13 >>>>>> for char 'c'. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 8/9/2016 11:32 PM, Philip Race wrote: >>>>>>> But characters are of varying width. Being on the "20th" char on >>>>>>> line N >>>>>>> may mean being on the "25th" on line N+1. >>>>>>> >>>>>>> So I am claiming this is nothing new and we really do not need >>>>>>> do anything here. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 8/9/16, 1:06 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 8/9/2016 12:44 AM, Phil Race wrote: >>>>>>>>> I was not familiar with this "magic caret" but from reading it >>>>>>>>> seems like it has just one use/purpose. >>>>>>>>> In the event that someone has multi-line text that you can >>>>>>>>> navigate around with up/down arrow keys >>>>>>>>> and that text has lines of varying length, you want a >>>>>>>>> "preferred" horizontal position for the caret >>>>>>>>> to be remembered so the caret is placed at that position >>>>>>>>> whenever the line of text has a length >>>>>>>>> greater than the caret position. Is there anything more to it >>>>>>>>> than that ? >>>>>>>>> >>>>>>>>> Obviously the caret needs to be placed correctly in the >>>>>>>>> context of the text, so the precise position, >>>>>>>>> even in an all-integer world, is not going to line up on every >>>>>>>>> single line, unless you have monospaced text. >>>>>>>>> ie the "pixel" position is going to get converted into a >>>>>>>>> position on the leading or trailing edge of some glyph >>>>>>>>> >>>>>>>>> So I wonder, does adding float matter .. is the extra >>>>>>>>> precision valuable here ? >>>>>>>> It may depend on the rounding of a point position. >>>>>>>> Suppose there are two lines with the same text. The caret is >>>>>>>> on the first line can have x position N.25. Pressing down the >>>>>>>> arrow key can round it to the N and the caret can be set to a >>>>>>>> previous char on the second line. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 08/04/2016 05:44 AM, Alexandr Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you review the fix: >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8163124 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8163124/webrev.00 >>>>>>>>>> >>>>>>>>>> The text position can have floating point value on HiDPI >>>>>>>>>> display. The Caret interface should be updated to allow use >>>>>>>>>> floating point positions. >>>>>>>>>> >>>>>>>>>> The fix adds the following public API with floating point >>>>>>>>>> positions: >>>>>>>>>> javax.swing.text.Caret.getMagicCaretPosition2D() >>>>>>>>>> javax.swing.text.Caret.setMagicCaretPosition2D(Point2D p) >>>>>>>>>> javax.swing.text.JTextComponent.modelToView2D(int pos) >>>>>>>>>> javax.swing.text.JTextComponent.viewToModel2D(Point2D pt) >>>>>>>>>> javax.swing.text.ParagraphView.getClosestPositionTo(int pos, >>>>>>>>>> Position.Bias b, Shape a, int direction, Position.Bias[], int >>>>>>>>>> rowIndex, float x) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The fix replaces >>>>>>>>>> Caret.getMagicCaretPosition()/setMagicCaretPosition(Point p) >>>>>>>>>> to >>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>> p) in all places >>>>>>>>>> except DefaultCaret because DefaultCaret extends Rectangle >>>>>>>>>> so its coordinates always have int values. >>>>>>>>>> I have filled a separated enhancement for this JDK-8163174 >>>>>>>>>> Add DefaultCaret2D which supports floating point API >>>>>>>>>> >>>>>>>>>> To make a custom caret use floating point API it is also >>>>>>>>>> necessary that PlainView.modelToView() returns a rectangle >>>>>>>>>> with floating point values. It can be done after the fix >>>>>>>>>> JDK-8156217 Selected text is shifted on HiDPI display >>>>>>>>>> which implements Utilities.getTabbedTextWidth(Segment s, >>>>>>>>>> FontMetrics metrics, float x, TabExpander e, int startOffset) >>>>>>>>>> method. >>>>>>>>>> I have filled a separated issue on it: >>>>>>>>>> JDK-8163175 PlainView.modelToView() method should return >>>>>>>>>> Rectangle2D >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> > From alok.sharma at hpe.com Mon Sep 26 05:30:24 2016 From: alok.sharma at hpe.com (Sharma, Alok Kumar (OSTL)) Date: Mon, 26 Sep 2016 05:30:24 +0000 Subject: OpenJDK JDK-7067885 code changes for community review In-Reply-To: <88e9828b-9609-f33e-78e8-ad31361dc828@oracle.com> References: <549b7026-cbf3-8bc3-a593-561699431554@oracle.com> <88e9828b-9609-f33e-78e8-ad31361dc828@oracle.com> Message-ID: Thanks Alexander for you review. Mercurial diff for updated source change: diff -r 021369229cfd src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java --- a/src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java Tue Sep 06 13:09:29 2016 -0400 +++ b/src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java Fri Sep 23 12:15:51 2016 +0530 @@ -32,6 +32,7 @@ import java.io.FileNotFoundException; import java.util.*; import java.util.concurrent.Callable; +import java.nio.file.*; /** * @author Michael Martak @@ -240,10 +241,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); Below is the explanation for fix. Problem description: FileChooser behavior when there is a soft link to a non-existent file/directory. Soft link to be displayed with an error/exception when attempt is made to open it. Instead the soft link name is not displayed in the file chooser. Analysis: JFileChooser() internally uses java.io.exists() to check whether file exists. In this scenario JFileChooser() checks dangling symlink existence using java.io.exists(). java.io.exists() api does not handle dangling symlink and returns false. JFileChooser() expects exists() api to return true for dangling symlink but, java.io.exists() returns false. Code changes: We have made changes in JFilechooser to use Non-Blocking java.nio.exists() api which check for file existence. java.nio.exists() handles dangling symlinks it accepts second argument link option which determines whether to follow the link or not and returns true for dangling symlinks. Regards, Alok -----Original Message----- From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] Sent: Tuesday, September 20, 2016 8:19 PM To: Sharma, Alok Kumar (OSTL) Cc: swing-dev at openjdk.java.net Subject: Re: OpenJDK JDK-7067885 code changes for community review Hello Alok, Is it possible to update the line where File.exists() is used just converting the file to a Path and using java.nio.exists() check? Thanks, Alexandr. On 9/16/2016 1:20 PM, Alexey Ivanov wrote: > Hi Alok, > > This change should be discussed on swing-dev mailing list because you > modify behavior of javax.swing.JFileChooser, and on core-libs-dev > because you also modify java.io.File. > > I agree with Alan, using the new API appears to be a better > alternative than changing java.io.File. > > > Regards, > Alexey > > On 12.09.2016 19:08, Alan Bateman wrote: >> Best to follow-up on swing-dev as I assume the right thing is to >> update JFileChooser rather than changing java.io.File to be mutable. >> You did acknowledge near the end of your mail that the new file >> system API supports sym links so it may be that JFileChooser could >> use that. >> >> -Alan >> >> >> On 12/09/2016 08:41, Sharma, Alok Kumar (OSTL) wrote: >>> Following is the fix for JDK-7067885. I am not sure which mailing ID >>> to post this. >>> >>> Bug: FileChooser does not display soft link name if link is to >>> nonexistent file/directory >>> https://bugs.openjdk.java.net/browse/JDK-7067885 >>> >>> This bug is unassigned. Can someone please look into these changes >>> and get back to me? Explanation of fix is at the end of the source >>> code diff. >>> >>> Mercurial diff for source change: >>> ------------------------------------------------------------------- >>> diff -r 021369229cfd src/java.base/share/classes/java/io/File.java >>> --- a/src/java.base/share/classes/java/io/File.java Tue Sep 06 >>> 13:09:29 2016 -0400 >>> +++ b/src/java.base/share/classes/java/io/File.java Mon Sep 12 >>> 11:27:07 2016 +0530 >>> @@ -164,6 +164,27 @@ >>> private final String path; >>> >>> /** >>> + * The flag indicates whether to follow the symlink. >>> + */ >>> + private boolean follow_link = true; >>> + >>> + /** >>> + * Sets the follow_link of file. >>> + * description: Sets follow_link on or off. >>> + * @param follow_link the value that determines whether to >>> follow the symlink or not. >>> + * TRUE: file.io.exists() checks the file existence using >>> stat() which follows the symlink. >>> + * >>> + * FALSE: file.io.exists() checks the file existence using >>> lstat() if stat() fails to retrieve >>> + * the file info. lstat() if file is a symbolic link, then >>> it returns information >>> + * about the link itself. >>> + * @return Returns ZERO at success >>> + */ >>> + public int set_follow_link(boolean follow_link) { >>> + this.follow_link=follow_link; >>> + return 0; >>> + } >>> + >>> + /** >>> * Enum type that indicates the status of a file path. >>> */ >>> private static enum PathStatus { INVALID, CHECKED }; diff -r >>> 021369229cfd src/java.base/unix/native/libjava/UnixFileSystem_md.c >>> --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Tue Sep >>> 06 13:09:29 2016 -0400 >>> +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon Sep >>> 12 11:27:07 2016 +0530 >>> @@ -51,6 +51,7 @@ >>> #define dirent64 dirent >>> #define readdir64_r readdir_r >>> #define stat64 stat >>> +#define lstat64 lstat >>> #ifndef MACOSX >>> #define statvfs64 statvfs >>> #endif >>> @@ -62,6 +63,7 @@ >>> jfieldID path; >>> } ids; >>> >>> +jfieldID ufs_follow_link; >>> >>> JNIEXPORT void JNICALL >>> Java_java_io_UnixFileSystem_initIDs(JNIEnv *env, jclass cls) @@ >>> -70,6 +72,8 @@ >>> if (!fileClass) return; >>> ids.path = (*env)->GetFieldID(env, fileClass, >>> "path", "Ljava/lang/String;"); >>> + ufs_follow_link = (*env)->GetFieldID(env, fileClass, >>> + "follow_link", "Z"); >>> } >>> >>> /* -- Path operations -- */ >>> @@ -113,20 +117,42 @@ >>> return JNI_FALSE; >>> } >>> >>> +static jboolean >>> +lstatMode(const char *path, int *mode) { >>> + struct stat64 sb; >>> + if (lstat64(path, &sb) == 0) { >>> + *mode = sb.st_mode; >>> + return JNI_TRUE; >>> + } >>> + return JNI_FALSE; >>> +} >>> >>> JNIEXPORT jint JNICALL >>> Java_java_io_UnixFileSystem_getBooleanAttributes0(JNIEnv *env, >>> jobject this, >>> jobject file) { >>> jint rv = 0; >>> + jint follow_link = 0; >>> >>> WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) { >>> int mode; >>> - if (statMode(path, &mode)) { >>> - int fmt = mode & S_IFMT; >>> - rv = (jint) (java_io_FileSystem_BA_EXISTS >>> - | ((fmt == S_IFREG) ? >>> java_io_FileSystem_BA_REGULAR : 0) >>> - | ((fmt == S_IFDIR) ? >>> java_io_FileSystem_BA_DIRECTORY : 0)); >>> + follow_link = (*env)->GetBooleanField(env, file, >>> ufs_follow_link); >>> + if ( follow_link ) { >>> + if (statMode(path, &mode)) { >>> + int fmt = mode & S_IFMT; >>> + rv = (jint) (java_io_FileSystem_BA_EXISTS >>> + | ((fmt == S_IFREG) ? >>> java_io_FileSystem_BA_REGULAR : 0) >>> + | ((fmt == S_IFDIR) ? >>> java_io_FileSystem_BA_DIRECTORY : 0)); >>> + } >>> + } >>> + else { >>> + if (lstatMode(path, &mode)) { >>> + int fmt = mode & S_IFMT; >>> + rv = (jint) (java_io_FileSystem_BA_EXISTS >>> + | ((fmt == S_IFREG) ? >>> java_io_FileSystem_BA_REGULAR : 0) >>> + | ((fmt == S_IFDIR) ? >>> java_io_FileSystem_BA_DIRECTORY : 0)); >>> + } >>> } >>> } END_PLATFORM_STRING(env, path); >>> return rv; >>> diff -r 021369229cfd >>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>> --- >>> a/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>> Tue Sep 06 13:09:29 2016 -0400 >>> +++ >>> b/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>> Mon Sep 12 11:27:07 2016 +0530 >>> @@ -521,6 +521,7 @@ >>> f = createFileSystemRoot(f); >>> } >>> try { >>> + f.set_follow_link(false); >>> f = ShellFolder.getShellFolder(f); >>> } catch (FileNotFoundException e) { >>> // Not a valid file (wouldn't show in native >>> file chooser) >>> ------------------------------------------ >>> >>> Below is the explanation for fix. >>> >>> Problem description: >>> FileChooser behavior when there is a soft link to a non-existent >>> file/directory. >>> Soft link to be displayed with an error/exception when attempt is >>> made to >>> open it. Instead the soft link name is not displayed in the file >>> chooser. >>> >>> Analysis: >>> JFileChooser() internally uses java.io.exists() to check whether >>> file exists. >>> In this scenario JFileChooser() checks dangling symlink existence >>> using java.io.exists(). >>> java.io.exists() api does not handle dangling symlink and returns >>> false. >>> >>> JFileChooser() expects exists() api to return true for dangling >>> symlink but, java.io.exists() returns false. >>> >>> We see that there are two exists() apis in JAVA java.io.exists() and >>> java.nio.exists(). >>> >>> java.nio.exists() handles dangling symlinks it accepts second >>> argument link option which >>> determines whether to follow the link or not and returns true for >>> dangling symlinks. >>> java.io.exists() follows the symlink and returns false if target >>> file doesn't exist. >>> >>> We have enhanced the java.io.exists() api to return true if it is a >>> dangling symlink. >>> >>> Changes in code: >>> >>> New variable "follow_link" is introduced in >>> "jdk/src/java.base/share/classes/java/io/File.java", we check for >>> this flag in exists() code >>> if its set then we handle symlinks. In case of dangling symlink >>> java.io.exists() api checks file existence >>> symlink itself not the target file and returns true. >>> >>> JFileChooser() issue (JDK-7067885) gets resolved with these changes. >>> >>> Testing: >>> I have covered the testing for the below apis. >>> Jfilechooser >>> getShellFolder >>> FileSystemView >>> and ran /openjdk9/jdk/test/javax/swing/JFileChooser/* tests. >>> >> > From alexandr.scherbatiy at oracle.com Wed Sep 28 17:03:25 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 28 Sep 2016 21:03:25 +0400 Subject: [9] Review request for 7067885 FileChooser does not display soft link name if link is to nonexistent file/directory In-Reply-To: References: <549b7026-cbf3-8bc3-a593-561699431554@oracle.com> <88e9828b-9609-f33e-78e8-ad31361dc828@oracle.com> Message-ID: <36843f8b-779e-43d4-7af7-00e6582734bf@oracle.com> The fix looks good to me. The link to the webrev: http://cr.openjdk.java.net/~alexsch/alok.sharma/7067885/webrev.00 I updated the email subject to follow the review request rule. Thanks, Alexandr. On 26/09/16 09:30, Sharma, Alok Kumar (OSTL) wrote: > Thanks Alexander for you review. > > Mercurial diff for updated source change: > > diff -r 021369229cfd src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java > --- a/src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java Tue Sep 06 13:09:29 2016 -0400 > +++ b/src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java Fri Sep 23 12:15:51 2016 +0530 > @@ -32,6 +32,7 @@ > import java.io.FileNotFoundException; > import java.util.*; > import java.util.concurrent.Callable; > +import java.nio.file.*; > > /** > * @author Michael Martak > @@ -240,10 +241,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); > > Below is the explanation for fix. > > Problem description: > FileChooser behavior when there is a soft link to a non-existent file/directory. > Soft link to be displayed with an error/exception when attempt is made to > open it. Instead the soft link name is not displayed in the file chooser. > > Analysis: > JFileChooser() internally uses java.io.exists() to check whether file exists. > In this scenario JFileChooser() checks dangling symlink existence using java.io.exists(). > java.io.exists() api does not handle dangling symlink and returns false. > > JFileChooser() expects exists() api to return true for dangling symlink but, java.io.exists() returns false. > > > Code changes: > We have made changes in JFilechooser to use Non-Blocking java.nio.exists() api which check for file existence. > > java.nio.exists() handles dangling symlinks it accepts second argument link option which > determines whether to follow the link or not and returns true for dangling symlinks. > > > Regards, > Alok > > -----Original Message----- > From: Alexandr Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] > Sent: Tuesday, September 20, 2016 8:19 PM > To: Sharma, Alok Kumar (OSTL) > Cc: swing-dev at openjdk.java.net > Subject: Re: OpenJDK JDK-7067885 code changes for community review > > Hello Alok, > > Is it possible to update the line where File.exists() is used just converting the file to a Path and using java.nio.exists() check? > > Thanks, > Alexandr. > > On 9/16/2016 1:20 PM, Alexey Ivanov wrote: >> Hi Alok, >> >> This change should be discussed on swing-dev mailing list because you >> modify behavior of javax.swing.JFileChooser, and on core-libs-dev >> because you also modify java.io.File. >> >> I agree with Alan, using the new API appears to be a better >> alternative than changing java.io.File. >> >> >> Regards, >> Alexey >> >> On 12.09.2016 19:08, Alan Bateman wrote: >>> Best to follow-up on swing-dev as I assume the right thing is to >>> update JFileChooser rather than changing java.io.File to be mutable. >>> You did acknowledge near the end of your mail that the new file >>> system API supports sym links so it may be that JFileChooser could >>> use that. >>> >>> -Alan >>> >>> >>> On 12/09/2016 08:41, Sharma, Alok Kumar (OSTL) wrote: >>>> Following is the fix for JDK-7067885. I am not sure which mailing ID >>>> to post this. >>>> >>>> Bug: FileChooser does not display soft link name if link is to >>>> nonexistent file/directory >>>> https://bugs.openjdk.java.net/browse/JDK-7067885 >>>> >>>> This bug is unassigned. Can someone please look into these changes >>>> and get back to me? Explanation of fix is at the end of the source >>>> code diff. >>>> >>>> Mercurial diff for source change: >>>> ------------------------------------------------------------------- >>>> diff -r 021369229cfd src/java.base/share/classes/java/io/File.java >>>> --- a/src/java.base/share/classes/java/io/File.java Tue Sep 06 >>>> 13:09:29 2016 -0400 >>>> +++ b/src/java.base/share/classes/java/io/File.java Mon Sep 12 >>>> 11:27:07 2016 +0530 >>>> @@ -164,6 +164,27 @@ >>>> private final String path; >>>> >>>> /** >>>> + * The flag indicates whether to follow the symlink. >>>> + */ >>>> + private boolean follow_link = true; >>>> + >>>> + /** >>>> + * Sets the follow_link of file. >>>> + * description: Sets follow_link on or off. >>>> + * @param follow_link the value that determines whether to >>>> follow the symlink or not. >>>> + * TRUE: file.io.exists() checks the file existence using >>>> stat() which follows the symlink. >>>> + * >>>> + * FALSE: file.io.exists() checks the file existence using >>>> lstat() if stat() fails to retrieve >>>> + * the file info. lstat() if file is a symbolic link, then >>>> it returns information >>>> + * about the link itself. >>>> + * @return Returns ZERO at success >>>> + */ >>>> + public int set_follow_link(boolean follow_link) { >>>> + this.follow_link=follow_link; >>>> + return 0; >>>> + } >>>> + >>>> + /** >>>> * Enum type that indicates the status of a file path. >>>> */ >>>> private static enum PathStatus { INVALID, CHECKED }; diff -r >>>> 021369229cfd src/java.base/unix/native/libjava/UnixFileSystem_md.c >>>> --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Tue Sep >>>> 06 13:09:29 2016 -0400 >>>> +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon Sep >>>> 12 11:27:07 2016 +0530 >>>> @@ -51,6 +51,7 @@ >>>> #define dirent64 dirent >>>> #define readdir64_r readdir_r >>>> #define stat64 stat >>>> +#define lstat64 lstat >>>> #ifndef MACOSX >>>> #define statvfs64 statvfs >>>> #endif >>>> @@ -62,6 +63,7 @@ >>>> jfieldID path; >>>> } ids; >>>> >>>> +jfieldID ufs_follow_link; >>>> >>>> JNIEXPORT void JNICALL >>>> Java_java_io_UnixFileSystem_initIDs(JNIEnv *env, jclass cls) @@ >>>> -70,6 +72,8 @@ >>>> if (!fileClass) return; >>>> ids.path = (*env)->GetFieldID(env, fileClass, >>>> "path", "Ljava/lang/String;"); >>>> + ufs_follow_link = (*env)->GetFieldID(env, fileClass, >>>> + "follow_link", "Z"); >>>> } >>>> >>>> /* -- Path operations -- */ >>>> @@ -113,20 +117,42 @@ >>>> return JNI_FALSE; >>>> } >>>> >>>> +static jboolean >>>> +lstatMode(const char *path, int *mode) { >>>> + struct stat64 sb; >>>> + if (lstat64(path, &sb) == 0) { >>>> + *mode = sb.st_mode; >>>> + return JNI_TRUE; >>>> + } >>>> + return JNI_FALSE; >>>> +} >>>> >>>> JNIEXPORT jint JNICALL >>>> Java_java_io_UnixFileSystem_getBooleanAttributes0(JNIEnv *env, >>>> jobject this, >>>> jobject file) { >>>> jint rv = 0; >>>> + jint follow_link = 0; >>>> >>>> WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) { >>>> int mode; >>>> - if (statMode(path, &mode)) { >>>> - int fmt = mode & S_IFMT; >>>> - rv = (jint) (java_io_FileSystem_BA_EXISTS >>>> - | ((fmt == S_IFREG) ? >>>> java_io_FileSystem_BA_REGULAR : 0) >>>> - | ((fmt == S_IFDIR) ? >>>> java_io_FileSystem_BA_DIRECTORY : 0)); >>>> + follow_link = (*env)->GetBooleanField(env, file, >>>> ufs_follow_link); >>>> + if ( follow_link ) { >>>> + if (statMode(path, &mode)) { >>>> + int fmt = mode & S_IFMT; >>>> + rv = (jint) (java_io_FileSystem_BA_EXISTS >>>> + | ((fmt == S_IFREG) ? >>>> java_io_FileSystem_BA_REGULAR : 0) >>>> + | ((fmt == S_IFDIR) ? >>>> java_io_FileSystem_BA_DIRECTORY : 0)); >>>> + } >>>> + } >>>> + else { >>>> + if (lstatMode(path, &mode)) { >>>> + int fmt = mode & S_IFMT; >>>> + rv = (jint) (java_io_FileSystem_BA_EXISTS >>>> + | ((fmt == S_IFREG) ? >>>> java_io_FileSystem_BA_REGULAR : 0) >>>> + | ((fmt == S_IFDIR) ? >>>> java_io_FileSystem_BA_DIRECTORY : 0)); >>>> + } >>>> } >>>> } END_PLATFORM_STRING(env, path); >>>> return rv; >>>> diff -r 021369229cfd >>>> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>>> --- >>>> a/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>>> Tue Sep 06 13:09:29 2016 -0400 >>>> +++ >>>> b/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java >>>> Mon Sep 12 11:27:07 2016 +0530 >>>> @@ -521,6 +521,7 @@ >>>> f = createFileSystemRoot(f); >>>> } >>>> try { >>>> + f.set_follow_link(false); >>>> f = ShellFolder.getShellFolder(f); >>>> } catch (FileNotFoundException e) { >>>> // Not a valid file (wouldn't show in native >>>> file chooser) >>>> ------------------------------------------ >>>> >>>> Below is the explanation for fix. >>>> >>>> Problem description: >>>> FileChooser behavior when there is a soft link to a non-existent >>>> file/directory. >>>> Soft link to be displayed with an error/exception when attempt is >>>> made to >>>> open it. Instead the soft link name is not displayed in the file >>>> chooser. >>>> >>>> Analysis: >>>> JFileChooser() internally uses java.io.exists() to check whether >>>> file exists. >>>> In this scenario JFileChooser() checks dangling symlink existence >>>> using java.io.exists(). >>>> java.io.exists() api does not handle dangling symlink and returns >>>> false. >>>> >>>> JFileChooser() expects exists() api to return true for dangling >>>> symlink but, java.io.exists() returns false. >>>> >>>> We see that there are two exists() apis in JAVA java.io.exists() and >>>> java.nio.exists(). >>>> >>>> java.nio.exists() handles dangling symlinks it accepts second >>>> argument link option which >>>> determines whether to follow the link or not and returns true for >>>> dangling symlinks. >>>> java.io.exists() follows the symlink and returns false if target >>>> file doesn't exist. >>>> >>>> We have enhanced the java.io.exists() api to return true if it is a >>>> dangling symlink. >>>> >>>> Changes in code: >>>> >>>> New variable "follow_link" is introduced in >>>> "jdk/src/java.base/share/classes/java/io/File.java", we check for >>>> this flag in exists() code >>>> if its set then we handle symlinks. In case of dangling symlink >>>> java.io.exists() api checks file existence >>>> symlink itself not the target file and returns true. >>>> >>>> JFileChooser() issue (JDK-7067885) gets resolved with these changes. >>>> >>>> Testing: >>>> I have covered the testing for the below apis. >>>> Jfilechooser >>>> getShellFolder >>>> FileSystemView >>>> and ran /openjdk9/jdk/test/javax/swing/JFileChooser/* tests. >>>> From alexandr.scherbatiy at oracle.com Wed Sep 28 17:22:06 2016 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 28 Sep 2016 21:22:06 +0400 Subject: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible In-Reply-To: <3c17f183-b869-b496-8679-2204429bde0f@jetbrains.com> References: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com> <99535873-b42a-2b16-16c9-0aa23ca7ea25@oracle.com> <3c17f183-b869-b496-8679-2204429bde0f@jetbrains.com> Message-ID: The fix looks good to me. I have also added awt-dev alias because fix changes the native part. Thanks, Alexandr. On 26/09/16 16:22, Anton Tarasov wrote: > Hi Pete, > > The fix looks fine to me. > > Thanks, > Anton. > > On 9/24/2016 2:59 AM, Pete Brunet wrote: >> New webrev: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/ >> >> I added a null check at line 688 like the one at line 693. >> >> Pete >> >> On 9/23/16 2:46 PM, Pete Brunet wrote: >>> Please review the patch for JDK-8160893. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160893 >>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.01/ >>> >>> This patch adds support to post menu related events: >>> kAXMenuOpenedNotification, kAXMenuClosedNotification, and >>> kAXMenuItemSelectedNotification. Also note that these changes had >>> impacts on the current combo box behavior so you'll see combo boxes >>> filtered out from this fix. The combo box behavior is currently broken >>> and will be fixed at a later date but at least for now I didn't want >>> this patch to change that (broken) behavior. >>> >>> TiA, >>> Pete > From semyon.sadetsky at oracle.com Thu Sep 29 07:55:37 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 29 Sep 2016 10:55:37 +0300 Subject: [9] Review request for 8153522: Update JLightweightFrame to allow non-integer (and X/Y) scales Message-ID: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8153522 webrev: http://cr.openjdk.java.net/~ssadetsky/8153522/webrev.00/ LightweightFrame Swing embedding API is updated for capability with floating point scale to make JavaFX SwingNode correctly shown on Windows platform. Backward API compatibility is preserved but methods with old signatures are marked as deprecated. --Semyon From Sergey.Bylokhov at oracle.com Thu Sep 29 12:51:37 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 29 Sep 2016 15:51:37 +0300 Subject: [9] Review request for 8153522: Update JLightweightFrame to allow non-integer (and X/Y) scales In-Reply-To: References: Message-ID: <4078c9d6-7ce9-497d-9f28-74eaaa22c3f5@oracle.com> Why we need the old API since it is sun.awt package? On 29.09.16 10:55, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8153522 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8153522/webrev.00/ > > LightweightFrame Swing embedding API is updated for capability with > floating point scale to make JavaFX SwingNode correctly shown on Windows > platform. > > Backward API compatibility is preserved but methods with old signatures > are marked as deprecated. > > --Semyon > -- Best regards, Sergey. From peter.brunet at oracle.com Thu Sep 29 13:35:54 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 29 Sep 2016 08:35:54 -0500 Subject: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible In-Reply-To: References: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com> <99535873-b42a-2b16-16c9-0aa23ca7ea25@oracle.com> <3c17f183-b869-b496-8679-2204429bde0f@jetbrains.com> Message-ID: <0144990c-4025-ca44-fe72-b5c2e513e1bf@oracle.com> Thanks, I will wait a bit before pushing in case awt-dev folks have any input. -Pete On 9/28/16 12:22 PM, Alexander Scherbatiy wrote: > The fix looks good to me. > > I have also added awt-dev alias because fix changes the native part. > > Thanks, > Alexandr. > > On 26/09/16 16:22, Anton Tarasov wrote: >> Hi Pete, >> >> The fix looks fine to me. >> >> Thanks, >> Anton. >> >> On 9/24/2016 2:59 AM, Pete Brunet wrote: >>> New webrev: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/ >>> >>> I added a null check at line 688 like the one at line 693. >>> >>> Pete >>> >>> On 9/23/16 2:46 PM, Pete Brunet wrote: >>>> Please review the patch for JDK-8160893. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160893 >>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.01/ >>>> >>>> This patch adds support to post menu related events: >>>> kAXMenuOpenedNotification, kAXMenuClosedNotification, and >>>> kAXMenuItemSelectedNotification. Also note that these changes had >>>> impacts on the current combo box behavior so you'll see combo boxes >>>> filtered out from this fix. The combo box behavior is currently >>>> broken >>>> and will be fixed at a later date but at least for now I didn't want >>>> this patch to change that (broken) behavior. >>>> >>>> TiA, >>>> Pete >> > From semyon.sadetsky at oracle.com Thu Sep 29 14:13:18 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 29 Sep 2016 17:13:18 +0300 Subject: [9] Review request for 8153522: Update JLightweightFrame to allow non-integer (and X/Y) scales In-Reply-To: <4078c9d6-7ce9-497d-9f28-74eaaa22c3f5@oracle.com> References: <4078c9d6-7ce9-497d-9f28-74eaaa22c3f5@oracle.com> Message-ID: <61324c09-32cd-727e-7999-8aaf1c8756ae@oracle.com> On 9/29/2016 3:51 PM, Sergey Bylokhov wrote: > Why we need the old API since it is sun.awt package? For compatibility. SwingNode doesn't yet use the new one. And there are may be some external apps has been using this API. No? > > On 29.09.16 10:55, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8153522 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8153522/webrev.00/ >> >> LightweightFrame Swing embedding API is updated for capability with >> floating point scale to make JavaFX SwingNode correctly shown on Windows >> platform. >> >> Backward API compatibility is preserved but methods with old signatures >> are marked as deprecated. >> >> --Semyon >> > > From Sergey.Bylokhov at oracle.com Fri Sep 30 11:34:17 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Sep 2016 14:34:17 +0300 Subject: [9] Review request for 8156217 Selected text is shifted on HiDPI display In-Reply-To: <97f24977-1e4f-a010-76a9-f4d9298f02b5@oracle.com> References: <73ea24e4-331e-a5b5-3609-28e5ddc6f5b0@oracle.com> <5797CEA6.10001@oracle.com> <47c44221-9775-0c06-1029-8a90568772b6@oracle.com> <57B1FF51.4030909@oracle.com> <0c5f92d9-9717-5b34-6e25-2597540310ca@oracle.com> <57B643F1.9050703@oracle.com> <224d6e13-4a61-d2b2-468a-f9aea476023b@oracle.com> <69474153-6bb6-2119-24fa-bd90cb98a387@oracle.com> <2592f145-d2ff-1785-149b-5dc8c7c4b7c3@oracle.com> <19e58281-7f77-f35e-7a15-853821db8492@oracle.com> <57D3477C.2090503@oracle.com> <95cd6ee3-a6c6-b3e7-0922-f26b5a8f29fa@oracle.com> <97f24977-1e4f-a010-76a9-f4d9298f02b5@oracle.com> Message-ID: On 27.09.16 21:13, Sergey Bylokhov wrote: > The public API Looks fine. Just a few small notes which I would like to highlight one more time. The fix looks fine, I still think that the change on Java2D(like on OSX) side will be better approach for Swing. This change should additionally tested later. - How it will work if some bufferedImage is used as a backbuffer for the Window. - What happens if the window will be moved to the screen with different DPI. We cannot simply upscale/downscale based on screen dpi, because the size of the window(after .pack()) can depend from the text, and text metrics are not necessary will have the same scale as the screen. - What happens if the component have one GraphicConfig, but the actual graphics, which was passed to paint, have another one. - I guess we also should revert the fix on OSX if this one will be considered as a better approach. The benefits of the fix in Java2D is that everything(all backbuffers, multiscreen, all components, selection, cursors, etc) will just work without the new API. The disadvantage is that in Swing on the HiDPI screen we can have one pixel error in the glyph position. > > On 21.09.16 16:06, Alexandr Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all_01 >> The public API remains unchanged: >> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api >> >> ParagraphView and GlyphPainter2 are updated to return Recatngel2D shape >> for ParagraphView.modelToView(...) call. >> However, the returned rectangle has int coordinates when "i18n" is set >> just because TextLayout.getCaretInfo(hit) method in class GlyphPainter2 >> returns int caret info. >> >> Thanks, >> Alexandr. >> >> On 9/20/2016 2:41 PM, Semyon Sadetsky wrote: >>> >>> Yet another question: Why the floating point API doesn't work for >>> JTextPane? >>> >>> Also it doesn't work for JTextArea, JTextField and JTextPane if i18n >>> is on. >>> >>> --Semyon >>> >>> >>> On 12.09.2016 15:19, Alexandr Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> all changes: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/all >>>> public API changes: >>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.07/public-api >>>> >>>> - @since 9 tag is added to new methods. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 9/10/2016 2:36 AM, Philip Race wrote: >>>>> - * Returns the tab size set for the document, defaulting to 8. >>>>> - * >>>>> - * @implSpec This implementation calls {@link #getTabSize() >>>>> getTabSize()}. >>>>> - * >>>>> - * @return the tab size >>>>> - */ >>>>> - protected float getFractionalTabSize() { >>>>> - return getTabSize(); >>>>> - } >>>>> - >>>>> >>>>> >>>>> It seems this was added only in 9. >>>>> Since I think I remember that asking a question about it. >>>>> I note it has no @since. Moot if you are really removing it but >>>>> what has it to do with the rest of this change ? >>>>> >>>>> -phil. >>>>> >>>>> On 9/9/16, 11:51 AM, Alexandr Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> all changes: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/all >>>>>> public API changes: >>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.06/public-api >>>>>> >>>>>> - reflection is used to detect do methods with floating point API >>>>>> need to be called. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 9/1/2016 9:17 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/1/2016 8:26 PM, Alexandr Scherbatiy wrote: >>>>>>>> On 9/1/2016 7:27 PM, Alexandr Scherbatiy wrote: >>>>>>>>> On 9/1/2016 6:49 PM, Semyon Sadetsky wrote: >>>>>>>>>> >>>>>>>>>> Alexander, did you consider possibility to check if method is >>>>>>>>>> really over-riden then to use the old API? >>>>>>>>>> >>>>>>>>> Could you give a sample how it can be done? >>>>>>>> I think it is possible to use a reflection to found the latest >>>>>>>> overridden method which uses int coordinates and check does it >>>>>>>> has a corresponding overridden method with floating point >>>>>>>> arguments. But I doubt that it is a good solution. >>>>>>> yes. You could use: >>>>>>> useFloatingPointAPI = >>>>>>> PlainView.class.equals(getClass().getMethod("drawUnselectedText", >>>>>>> ...).getDeclaringClass()); >>>>>>> >>>>>>> Otherwise, with high probability your new API will never be used. >>>>>>> >>>>>>> --Semyon >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 9/1/2016 3:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>> On 9/1/2016 11:31 AM, Semyon Sadetsky wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Alexander, >>>>>>>>>>>> >>>>>>>>>>>> It is a good style to add a note recommending what to use >>>>>>>>>>>> instead of the method which is being deprecated. >>>>>>>>>>>> >>>>>>>>>>> Could you review the updated public API there "replaced by" >>>>>>>>>>> notes are added to the deprecated methods: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.02 >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I did not get for what the useFloatingPointAPI property was >>>>>>>>>>>> introduced and moreover is set to false by default. If the >>>>>>>>>>>> old API is used then it doesn't matter which value it has >>>>>>>>>>>> because the float values will receive ints. And for the new >>>>>>>>>>>> API I would expect everything having the float precision, and >>>>>>>>>>>> it is unclear what may be the reason to switch it off back to >>>>>>>>>>>> integer. Especially if >>>>>>>>>>>> >>>>>>>>>>>> " This allows to draw text properly using graphics with >>>>>>>>>>>> scaled transform." >>>>>>>>>>>> >>>>>>>>>>>> so an improper mode is the default? >>>>>>>>>>>> >>>>>>>>>>> This is has been discussed below. For example new >>>>>>>>>>> drawSelectedText(Graphics2D g, float x, float y, int p0, int >>>>>>>>>>> p1) with floating point coordinates is added to the PlainView >>>>>>>>>>> which has the same method with int coordinates. Suppose >>>>>>>>>>> someone has a custom password component which uses and old >>>>>>>>>>> methods with int coordinates. >>>>>>>>>>> -------- >>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>> >>>>>>>>>>> @Override >>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, int y, >>>>>>>>>>> int p0, int p1) throws BadLocationException { >>>>>>>>>>> // draw echo chars >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> -------- >>>>>>>>>>> >>>>>>>>>>> If we start to call drawSelectedText() with floating point >>>>>>>>>>> values the customization of old components will not be used >>>>>>>>>>> and the CustomPasswordField from the example starts to show >>>>>>>>>>> real text instead of echo chars. This is incompatible change >>>>>>>>>>> with previous JDK releases. >>>>>>>>>>> >>>>>>>>>>> The solution is to switch to new floating point API only when >>>>>>>>>>> it is known that a component properly overrides new methods >>>>>>>>>>> with floating point arguments. After that the >>>>>>>>>>> PlainView.useFloatingPointAPI flag can be set to true. >>>>>>>>>>> >>>>>>>>>>> For example, BasicPasswordFieldUI sets the >>>>>>>>>>> PasswordView.useFloatingPointAPI flag to true because it is >>>>>>>>>>> sure that drawSelectedText() methods with floating point >>>>>>>>>>> arguments is overridden. So Swing standard text components are >>>>>>>>>>> switched to use new floating point API. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 19.08.2016 11:03, Alexandr Scherbatiy wrote: >>>>>>>>>>>>> On 8/19/2016 2:25 AM, Philip Race wrote: >>>>>>>>>>>>>> OK .. I do not know enough about how modelToView is used by >>>>>>>>>>>>>> Swing >>>>>>>>>>>>>> to know what is really needed here. Someone with a bit more >>>>>>>>>>>>>> Swing >>>>>>>>>>>>>> background needs to chime in. I was encouraged that the >>>>>>>>>>>>>> *API* surface >>>>>>>>>>>>>> of the changes was much smaller than it had seemed from the >>>>>>>>>>>>>> webrev >>>>>>>>>>>>>> but maybe that is because you did not include everything. >>>>>>>>>>>>>> For example >>>>>>>>>>>>>> although they are just subclassing the method overrides in >>>>>>>>>>>>>> PasswordView >>>>>>>>>>>>>> since that is a public class would become part of the spec >>>>>>>>>>>>>> .. would they not ? >>>>>>>>>>>>>> Just like the "int" counterparts today :- >>>>>>>>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/text/PasswordView.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Put another way I was looking for what the content of the >>>>>>>>>>>>>> CCC would be. >>>>>>>>>>>>> Here is the updated version of the public API change >>>>>>>>>>>>> which includes overridden deprecated methods: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api.01 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/15/16, 11:48 AM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 15/08/16 21:43, Phil Race wrote: >>>>>>>>>>>>>>>> Why is the caret support added in here ? Same for the >>>>>>>>>>>>>>>> modelToView >>>>>>>>>>>>>>>> That will just hold this up as the reasoning behind >>>>>>>>>>>>>>>> needing those changes is not something >>>>>>>>>>>>>>>> I have yet been able to convince myself about - even >>>>>>>>>>>>>>>> after reading your last email. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The main change for the Caret public API (methods >>>>>>>>>>>>>>> Caret.getMagicCaretPosition2D()/setMagicCaretPosition2D(Point2D >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> p)) is not included in the current fix. I only moved the >>>>>>>>>>>>>>> new methods JTextComponent.modelToView2D(int >>>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) from the fix for the Caret >>>>>>>>>>>>>>> to this fix. These methods are used not only for caret but >>>>>>>>>>>>>>> in other cases like mouse handling, text dragging and >>>>>>>>>>>>>>> others. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08/15/2016 04:13 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you review the updated fix? >>>>>>>>>>>>>>>>> webrev which contains only change in public API: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/public-api >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> webrev with contains all changes: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.05/all >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - methods with int coordinates are deprecated >>>>>>>>>>>>>>>>> - public >>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() methods >>>>>>>>>>>>>>>>> are added to the PlainView and WrappedPlainView classes >>>>>>>>>>>>>>>>> - JTextComponent.modelToView2D(int >>>>>>>>>>>>>>>>> pos)/viewToModel2D(Point2D pt) public methods from fix >>>>>>>>>>>>>>>>> JDK-8163124 Add floating point API support to >>>>>>>>>>>>>>>>> javax.swing.text.Caret >>>>>>>>>>>>>>>>> are added >>>>>>>>>>>>>>>>> - some @implSpec descriptions are removed from the new >>>>>>>>>>>>>>>>> text drawing methods with floating point arguments >>>>>>>>>>>>>>>>> - Built-in L&Fs are updated to use floating point API >>>>>>>>>>>>>>>>> in standard Java text components >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 7/28/2016 5:38 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> See comments inline. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 7/26/2016 11:57 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>> I have a lot of doubts about this as well as trouble >>>>>>>>>>>>>>>>>>> getting my head around all of it. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Given that apps need to 'buy in' to the floating point >>>>>>>>>>>>>>>>>>> I am not sure what we are gaining >>>>>>>>>>>>>>>>>>> but I need to make sure I understand the problem. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It affects only the methods that the 3rd party code >>>>>>>>>>>>>>>>>>> can over-ride >>>>>>>>>>>>>>>>>>> in subclasses and that are called by the JDK internal >>>>>>>>>>>>>>>>>>> code. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> There are just two protected methods that matter :- >>>>>>>>>>>>>>>>>>> PlainView.drawSelectedText(..) >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> PlainView.drawUnselectedText(..) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The hidpi precison matters since they are drawing a >>>>>>>>>>>>>>>>>>> sub-range of the text. >>>>>>>>>>>>>>>>>>> Is there any other method that matters / is used in >>>>>>>>>>>>>>>>>>> this way ? >>>>>>>>>>>>>>>>>> I have found the following methods which relate to >>>>>>>>>>>>>>>>>> text drawing, can be overridden and could have floating >>>>>>>>>>>>>>>>>> point coordinates: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> javax.swing.text.PlainView.drawLine(...) >>>>>>>>>>>>>>>>>> javax.swing.text.PlainView.lineToRect(...) >>>>>>>>>>>>>>>>>> javax.swing.text.PasswordView.drawEchoCharacter(...) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.modelToView(...) >>>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.viewToModel(...) >>>>>>>>>>>>>>>>>> javax.swing.plaf.TextUI.getToolTipText(...) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There is also a method which relates to a caret >>>>>>>>>>>>>>>>>> position in a text: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> javax.swing.text.DefaultCaret.setMagicCaretPosition(Point >>>>>>>>>>>>>>>>>> p) >>>>>>>>>>>>>>>>>> This requires additional investigation because >>>>>>>>>>>>>>>>>> DefaultCaret extends Rectangle and so its coordinates >>>>>>>>>>>>>>>>>> can't be float. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Since 3rd party code is not over-riding these they >>>>>>>>>>>>>>>>>>> will get the JDK >>>>>>>>>>>>>>>>>>> super-class version, thus losing any customisation >>>>>>>>>>>>>>>>>>> they might have done >>>>>>>>>>>>>>>>>>> in the no-longer-called int version. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Assuming that is correct, what customisation would be >>>>>>>>>>>>>>>>>>> lost and how much does it matter? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The example is javax.swing.text.PasswordView class >>>>>>>>>>>>>>>>>> which overrides >>>>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>>>> and draws echo chars instead of text. >>>>>>>>>>>>>>>>>> The similar can be done in a custom component: >>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>> public class CustomPasswordField extends FieldView { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> @Override >>>>>>>>>>>>>>>>>> protected int drawSelectedText(Graphics g, int x, >>>>>>>>>>>>>>>>>> int y, int p0, int p1) throws BadLocationException { >>>>>>>>>>>>>>>>>> // draw echo chars >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Switching to support new methods with floating point >>>>>>>>>>>>>>>>>> coordinates will lead that real text will be shown for >>>>>>>>>>>>>>>>>> old applications in password fields. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> My prefernce is to deprecate the int versions and >>>>>>>>>>>>>>>>>>> always call the float versions >>>>>>>>>>>>>>>>>>> rather than the opt-in approach. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Actually my real preference would be to come up with >>>>>>>>>>>>>>>>>>> something that does >>>>>>>>>>>>>>>>>>> not involve drawing the text in chunks like this. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ie Swing should use AttributedCharacterIterator .. it >>>>>>>>>>>>>>>>>>> looks like the code to >>>>>>>>>>>>>>>>>>> do this might already be there ! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 106 private float drawElement(int lineIndex, Element >>>>>>>>>>>>>>>>>>> elem, Graphics g, >>>>>>>>>>>>>>>>>>> 107 float x, float y, boolean fractionalCharBounds) >>>>>>>>>>>>>>>>>>> 108 throws BadLocationException >>>>>>>>>>>>>>>>>>> 109 { >>>>>>>>>>>>>>>>>>> 110 int p0 = elem.getStartOffset(); >>>>>>>>>>>>>>>>>>> 111 int p1 = elem.getEndOffset(); >>>>>>>>>>>>>>>>>>> 112 p1 = Math.min(getDocument().getLength(), >>>>>>>>>>>>>>>>>>> p1); >>>>>>>>>>>>>>>>>>> 113 >>>>>>>>>>>>>>>>>>> 114 if (lineIndex == 0) { >>>>>>>>>>>>>>>>>>> 115 x += firstLineOffset; >>>>>>>>>>>>>>>>>>> 116 } >>>>>>>>>>>>>>>>>>> 117 AttributeSet attr = elem.getAttributes(); >>>>>>>>>>>>>>>>>>> 118 if >>>>>>>>>>>>>>>>>>> (Utilities.isComposedTextAttributeDefined(attr)) { >>>>>>>>>>>>>>>>>>> 119 g.setColor(unselected); >>>>>>>>>>>>>>>>>>> 120 x = Utilities.drawComposedText(this, >>>>>>>>>>>>>>>>>>> attr, g, x, y, >>>>>>>>>>>>>>>>>>> 121 >>>>>>>>>>>>>>>>>>> p0-elem.getStartOffset(), >>>>>>>>>>>>>>>>>>> 122 >>>>>>>>>>>>>>>>>>> p1-elem.getStartOffset()); >>>>>>>>>>>>>>>>>>> 123 } else { >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In fact what *that* illustrates is that applications >>>>>>>>>>>>>>>>>>> already cannot expect >>>>>>>>>>>>>>>>>>> their over-ridden methods to be called, so this fix is >>>>>>>>>>>>>>>>>>> trying to fix something >>>>>>>>>>>>>>>>>>> that can't be fixed. >>>>>>>>>>>>>>>>>> The javadoc for the "protected PlainView.drawLine(...)" >>>>>>>>>>>>>>>>>> method is: >>>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>>> /** >>>>>>>>>>>>>>>>>> * Renders a line of text, suppressing whitespace >>>>>>>>>>>>>>>>>> at the end >>>>>>>>>>>>>>>>>> * and expanding any tabs. This is implemented to >>>>>>>>>>>>>>>>>> make calls >>>>>>>>>>>>>>>>>> * to the methods {@code drawUnselectedText} and >>>>>>>>>>>>>>>>>> * {@code drawSelectedText} so that the way >>>>>>>>>>>>>>>>>> selected and >>>>>>>>>>>>>>>>>> * unselected text are rendered can be customized. >>>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Applications can rely on this behaviour and stopping >>>>>>>>>>>>>>>>>> to call the >>>>>>>>>>>>>>>>>> drawSelectedText(...)/drawUnselectedText(...) methods >>>>>>>>>>>>>>>>>> with int coordinates will be incompatible change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So why can't we do that ? Just deprecate those int >>>>>>>>>>>>>>>>>>> methods, don't add >>>>>>>>>>>>>>>>>>> the float methods and use ACI .. >>>>>>>>>>>>>>>>>> New float methods allow to easily migrate on new API >>>>>>>>>>>>>>>>>> for applications without significant changes. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BTW getTabSize() is supposed to be a character count >>>>>>>>>>>>>>>>>>> isn't it ? Not a pixel >>>>>>>>>>>>>>>>>>> count. So why does it need a float version. >>>>>>>>>>>>>>>>>> Could you review the updated fix: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.04 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - methods with int coordinates which can be >>>>>>>>>>>>>>>>>> overridden are deprecated >>>>>>>>>>>>>>>>>> - getFractionalTabSize() method is removed >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -phil >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 06/30/2016 08:50 AM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> On 6/28/2016 8:14 PM, Alan Snyder wrote: >>>>>>>>>>>>>>>>>>>>> Suppose an application is only partially fixed to >>>>>>>>>>>>>>>>>>>>> use/override the floating point methods. Perhaps it >>>>>>>>>>>>>>>>>>>>> uses a library that has not been fixed. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Is there a more fine grained way to detect >>>>>>>>>>>>>>>>>>>>> programmer awareness or lack of awareness of the new >>>>>>>>>>>>>>>>>>>>> methods? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Here is a slightly updated version which adds >>>>>>>>>>>>>>>>>>>> public >>>>>>>>>>>>>>>>>>>> isUseFloatingPointAPI()/setUseFloatingPointAPI() >>>>>>>>>>>>>>>>>>>> methods to the PlainView and WrappedPlainView classes: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.02 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Using the floating point API is disabled by default >>>>>>>>>>>>>>>>>>>> and enabled for standard Swing text component >>>>>>>>>>>>>>>>>>>> classes. This has advantage that selection will work >>>>>>>>>>>>>>>>>>>> for text component in users applications on HiDPI >>>>>>>>>>>>>>>>>>>> display. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> But it still has the same problem. Applications >>>>>>>>>>>>>>>>>>>> which use custom View classes needs to updated them >>>>>>>>>>>>>>>>>>>> to implement corresponding text drawing methods with >>>>>>>>>>>>>>>>>>>> floating point arguments and enable the floating >>>>>>>>>>>>>>>>>>>> point API usage. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Alan >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Jun 28, 2016, at 9:59 AM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I tried to merge this fix with the 8132119 >>>>>>>>>>>>>>>>>>>>>> Provide public API for text related methods in >>>>>>>>>>>>>>>>>>>>>> SwingUtilities2 >>>>>>>>>>>>>>>>>>>>>> and found a flow in the used algorithm. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> For each method that uses integer coordinates the >>>>>>>>>>>>>>>>>>>>>> fix adds a pair with floating point arguments. >>>>>>>>>>>>>>>>>>>>>> The fix 8156217 uses only methods with floating >>>>>>>>>>>>>>>>>>>>>> point values to correctly handle a selected text. >>>>>>>>>>>>>>>>>>>>>> This leads that overridden method with integer >>>>>>>>>>>>>>>>>>>>>> arguments in user code is not called anymore. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think that this can be handled in the following >>>>>>>>>>>>>>>>>>>>>> way: >>>>>>>>>>>>>>>>>>>>>> - Add a property that enables to use methods with >>>>>>>>>>>>>>>>>>>>>> floating point arguments in Swing. >>>>>>>>>>>>>>>>>>>>>> By default it is false and all work as before. >>>>>>>>>>>>>>>>>>>>>> The issue with selected text is reproduced. >>>>>>>>>>>>>>>>>>>>>> An application with enabled property does not >>>>>>>>>>>>>>>>>>>>>> have issue with the selected text but a user should >>>>>>>>>>>>>>>>>>>>>> override >>>>>>>>>>>>>>>>>>>>>> all methods with floating point values if he >>>>>>>>>>>>>>>>>>>>>> uses corresponding methods with integer values. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Here is a proposed solution where new public >>>>>>>>>>>>>>>>>>>>>> system property >>>>>>>>>>>>>>>>>>>>>> "javax.swing.floatingPoints.enabled" is added: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.01 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - Fix the enhancement JDK-8157461 Glyph image >>>>>>>>>>>>>>>>>>>>>> rendering for HiDPI displays >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 6/16/2016 6:07 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>> On 6/16/2016 4:47 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I tried to look deeper in the code and it seems >>>>>>>>>>>>>>>>>>>>>>>> there is a rounding issue when float values are >>>>>>>>>>>>>>>>>>>>>>>> summed up. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Suppose a transform with scale 1.5 is used and >>>>>>>>>>>>>>>>>>>>>>>> the 'a' char advance is 10 in a dev space. >>>>>>>>>>>>>>>>>>>>>>>> The 'a' char has advance 10 / 1.5 = >>>>>>>>>>>>>>>>>>>>>>>> 6.666666666666667 as double value and 6.6666665 >>>>>>>>>>>>>>>>>>>>>>>> when it is cast to float in user space. >>>>>>>>>>>>>>>>>>>>>>>> The width of a string which consists of 15 'a' >>>>>>>>>>>>>>>>>>>>>>>> chars is 15 * 6.6666665 = 100.000000. >>>>>>>>>>>>>>>>>>>>>>>> But the same width calculated as sum of each >>>>>>>>>>>>>>>>>>>>>>>> glyph advance in >>>>>>>>>>>>>>>>>>>>>>>> StandardGlyphVector.initPositions() method is >>>>>>>>>>>>>>>>>>>>>>>> 99.999992. >>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>> double scale = 1.5; >>>>>>>>>>>>>>>>>>>>>>>> float advance = (float) (10 / scale); >>>>>>>>>>>>>>>>>>>>>>>> int N = 15; >>>>>>>>>>>>>>>>>>>>>>>> System.out.printf("%d * %f = %f\n", N, >>>>>>>>>>>>>>>>>>>>>>>> advance, N * advance); >>>>>>>>>>>>>>>>>>>>>>>> float sum = 0; >>>>>>>>>>>>>>>>>>>>>>>> for (int i = 0; i < N; i++) { >>>>>>>>>>>>>>>>>>>>>>>> sum += advance; >>>>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>>>> System.out.printf("sum: %f\n", sum); >>>>>>>>>>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Because of this a string drawn from float >>>>>>>>>>>>>>>>>>>>>>>> position 99.999998 is shifted one pixel left >>>>>>>>>>>>>>>>>>>>>>>> which affects the text selection code in Swing: >>>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>>>> g.scale(1.5, 1.5); >>>>>>>>>>>>>>>>>>>>>>>> String TEXT = "aaaaaaaaaaaaaaaa"; >>>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); // 99.999992 >>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, >>>>>>>>>>>>>>>>>>>>>>>> y); // non-selected text >>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); // >>>>>>>>>>>>>>>>>>>>>>>> selected text is shifted to one pixel left >>>>>>>>>>>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>>>>>>>>>> The last step is how coordinates are scaled in >>>>>>>>>>>>>>>>>>>>>>> Graphics2D.drawString() method. >>>>>>>>>>>>>>>>>>>>>>> If the graphics has scale 1.5 and zero >>>>>>>>>>>>>>>>>>>>>>> translate the transformed coordinates are: >>>>>>>>>>>>>>>>>>>>>>> (99.999992 + 0) * 1.5 = 149.999985 >>>>>>>>>>>>>>>>>>>>>>> (100.000000 + 0) * 1.5 = 150.000000 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Both of them are rounded to the same value. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If the translate is set to integer 1 value: >>>>>>>>>>>>>>>>>>>>>>> (99.999992 + 1) * 1.5 = 151.499989 // shifted >>>>>>>>>>>>>>>>>>>>>>> to one pixel left >>>>>>>>>>>>>>>>>>>>>>> (100.000000 + 1) * 1.5 = 151.500000 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> A position 99.999992 in user space is rounded to >>>>>>>>>>>>>>>>>>>>>>> 151 in dev space. >>>>>>>>>>>>>>>>>>>>>>> A position 100.000000 in user space is rounded to >>>>>>>>>>>>>>>>>>>>>>> 152 in dev space. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> And this difference can depend on the translate >>>>>>>>>>>>>>>>>>>>>>> even it has integer value in user space because it >>>>>>>>>>>>>>>>>>>>>>> is multiplied on the graphics scale. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 6/2/2016 11:41 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 5/31/2016 10:40 PM, Phil Race wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I applied this and it is *much* better but >>>>>>>>>>>>>>>>>>>>>>>>>> there still seem to be some tiny quirks. >>>>>>>>>>>>>>>>>>>>>>>>>> When I drag the mouse to select text down and >>>>>>>>>>>>>>>>>>>>>>>>>> then up again, as I pass the >>>>>>>>>>>>>>>>>>>>>>>>>> original mouse click point vertically, repaint >>>>>>>>>>>>>>>>>>>>>>>>>> seem to jiggle vertically by a pixel. >>>>>>>>>>>>>>>>>>>>>>>>>> Perhaps a rounding issue in the repaint code's >>>>>>>>>>>>>>>>>>>>>>>>>> calculation of the location of >>>>>>>>>>>>>>>>>>>>>>>>>> the target y. I think I may see the same in >>>>>>>>>>>>>>>>>>>>>>>>>> left/right dragging along a line too. >>>>>>>>>>>>>>>>>>>>>>>>>> So I think this is repaint and not text >>>>>>>>>>>>>>>>>>>>>>>>>> related. Can you take a look. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I am able to reproduce this only using a >>>>>>>>>>>>>>>>>>>>>>>>> floating point scale. >>>>>>>>>>>>>>>>>>>>>>>>> It looks like 2d issue. I used a test which >>>>>>>>>>>>>>>>>>>>>>>>> draws a text in two pieces. The second piece of >>>>>>>>>>>>>>>>>>>>>>>>> the text is shifted from the first piece by the >>>>>>>>>>>>>>>>>>>>>>>>> floating point size of the the first piece of >>>>>>>>>>>>>>>>>>>>>>>>> the text. >>>>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>>>> Rectangle2D rect = >>>>>>>>>>>>>>>>>>>>>>>>> font.getStringBounds(TEXT, 0, index, >>>>>>>>>>>>>>>>>>>>>>>>> g.getFontMetrics().getFontRenderContext()); >>>>>>>>>>>>>>>>>>>>>>>>> float selectedTextPosition = (float) >>>>>>>>>>>>>>>>>>>>>>>>> rect.getWidth(); >>>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(0, index), x, y); >>>>>>>>>>>>>>>>>>>>>>>>> g.drawString(TEXT.substring(index, >>>>>>>>>>>>>>>>>>>>>>>>> TEXT.length()), x + selectedTextPosition, y); >>>>>>>>>>>>>>>>>>>>>>>>> ----------- >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> The second piece of the text can be shifted in >>>>>>>>>>>>>>>>>>>>>>>>> the 2 cases: >>>>>>>>>>>>>>>>>>>>>>>>> a) graphics scale is 1.5 and translation is 1. >>>>>>>>>>>>>>>>>>>>>>>>> b) graphics scale is 2.25 without applied >>>>>>>>>>>>>>>>>>>>>>>>> translation >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I have filed an issue on it: >>>>>>>>>>>>>>>>>>>>>>>>> JDK-8158370 Text drawn from float pointing >>>>>>>>>>>>>>>>>>>>>>>>> position and with float pointing scale is shifted >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8158370 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -phil. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 05/06/2016 12:31 PM, Alexandr Scherbatiy >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Could you review the fix: >>>>>>>>>>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156217 >>>>>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8156217/webrev.00 >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> This is the second part of the fix related >>>>>>>>>>>>>>>>>>>>>>>>>>> to the fact that char width can be fractional >>>>>>>>>>>>>>>>>>>>>>>>>>> in user space. >>>>>>>>>>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/swing-dev/2016-May/005814.html >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> The Font.getStringBounds(...) method is used >>>>>>>>>>>>>>>>>>>>>>>>>>> for the fractional string width calculation by >>>>>>>>>>>>>>>>>>>>>>>>>>> Swing in user space. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 30 14:53:43 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Sep 2016 17:53:43 +0300 Subject: [9] Review request for 8163167: [PIT] javax/swing/JTextArea/ScrollbarFlicker/ScrollFlickerTest.java always fail In-Reply-To: <2aa30c0d-231a-f052-d351-f5ecdb8ccf5d@oracle.com> References: <6d2444db-6cef-c6fb-1714-10431462bc3c@oracle.com> <9cc78350-edb6-7904-4a44-e5bd27532f33@oracle.com> <948780ff-fdb8-0b57-8714-8d3a6599ad5f@oracle.com> <224dab41-d43f-5a8c-f027-196e6bdac4a8@oracle.com> <68ca4d96-12da-0cf9-c843-f0e8dc74b814@oracle.com> <923e8f8c-60f8-9070-e0bd-cafeda47ecac@oracle.com> <233d8b57-7adc-497b-7004-bb1b4a427bd1@oracle.com> <30f462f7-2348-3249-d0cc-a7818356b7b4@oracle.com> <7378e929-31d4-0c3a-267a-f85ebf9d303e@oracle.com> <4af938e3-b86c-406a-b499-b1e8a08a67cf@oracle.com> <2aa30c0d-231a-f052-d351-f5ecdb8ccf5d@oracle.com> Message-ID: <05e0bf7d-5c59-7a93-b321-dcd0c08639c7@oracle.com> On 01.09.16 16:38, Semyon Sadetsky wrote: >> If the test is correct why you tries to change it? The test found a >> bug when we get more notifications than expected. > The issue was to count normal notifications from revalidation. Now the > counter starts to count after the layout is done. But if layout was done, why we get any notifications? Should the check be (cnt != 0)? >> >>>> I assume that each notification should be called when the size of >>>> JViewport or View were changed? >>>> >>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 23.08.16 11:59, Alexander Scherbatiy wrote: >>>>>>>>>>>>> The fix looks good to me. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>> On 23/08/16 11:40, Semyon Sadetsky wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8163167 >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8163167/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> The cause of this test bug is revalidating JScrollPane >>>>>>>>>>>>>> layout may >>>>>>>>>>>>>> take >>>>>>>>>>>>>> various number of iterations on different L&Fs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To fix the test the counter listener is added after the >>>>>>>>>>>>>> layout >>>>>>>>>>>>>> revalidation has been started. >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 30 15:45:39 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Sep 2016 18:45:39 +0300 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK Message-ID: Hello. Please review the fix for jdk9. This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug is about official deprecation of them. We can replace old constants by the new one in the whole jdk, but I updated only the code in InputEvent to make change smaller and safer. So at least the new code in jdk and the code in applications will start to use the new constants. The changes in jconsole are necessary to fix deprecation warning. jprt build passed, no new issues were found by jck/jtreg tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8143077 Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 30 15:55:06 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Sep 2016 18:55:06 +0300 Subject: [9] Review request for 8153522: Update JLightweightFrame to allow non-integer (and X/Y) scales In-Reply-To: <61324c09-32cd-727e-7999-8aaf1c8756ae@oracle.com> References: <4078c9d6-7ce9-497d-9f28-74eaaa22c3f5@oracle.com> <61324c09-32cd-727e-7999-8aaf1c8756ae@oracle.com> Message-ID: On 29.09.16 17:13, Semyon Sadetsky wrote: > On 9/29/2016 3:51 PM, Sergey Bylokhov wrote: > >> Why we need the old API since it is sun.awt package? > For compatibility. SwingNode doesn't yet use the new one. Probably Kevin can provide some info on how we usually synchronize the changes between jdk and FX, I assume that we should save the old one and remove them after FX will use it as a boot/minimum jdk? > And there are may be some external apps has been using this API. No? It will not be accessible to applications in jdk. >> >> On 29.09.16 10:55, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8153522 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153522/webrev.00/ >>> >>> LightweightFrame Swing embedding API is updated for capability with >>> floating point scale to make JavaFX SwingNode correctly shown on Windows >>> platform. >>> >>> Backward API compatibility is preserved but methods with old signatures >>> are marked as deprecated. >>> >>> --Semyon >>> >> >> > -- Best regards, Sergey. From mandy.chung at oracle.com Fri Sep 30 16:01:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Sep 2016 09:01:41 -0700 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK In-Reply-To: References: Message-ID: <38FC8343-B900-4D18-86AA-D882DD9B9F43@oracle.com> The jconsole change looks fine. I?m including serviceability-dev and bcc core-libs-dev as serviceability-dev is the right mailing list for jconsole change. Mandy > On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov wrote: > > Hello. > > Please review the fix for jdk9. > > This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug is about official deprecation of them. > > We can replace old constants by the new one in the whole jdk, but I updated only the code in InputEvent to make change smaller and safer. So at least the new code in jdk and the code in applications will start to use the new constants. > > The changes in jconsole are necessary to fix deprecation warning. > > jprt build passed, no new issues were found by jck/jtreg tests. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143077 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00 > > -- > Best regards, Sergey. From kevin.rushforth at oracle.com Fri Sep 30 16:23:22 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 30 Sep 2016 09:23:22 -0700 Subject: [9] Review request for 8153522: Update JLightweightFrame to allow non-integer (and X/Y) scales In-Reply-To: References: <4078c9d6-7ce9-497d-9f28-74eaaa22c3f5@oracle.com> <61324c09-32cd-727e-7999-8aaf1c8756ae@oracle.com> Message-ID: <57EE917A.9080007@oracle.com> Sergey Bylokhov wrote: > On 29.09.16 17:13, Semyon Sadetsky wrote: >> On 9/29/2016 3:51 PM, Sergey Bylokhov wrote: >> >>> Why we need the old API since it is sun.awt package? >> For compatibility. SwingNode doesn't yet use the new one. > > Probably Kevin can provide some info on how we usually synchronize the > changes between jdk and FX, I assume that we should save the old one > and remove them after FX will use it as a boot/minimum jdk? Yes, that is how we would typically do this. And to add to the problem for JDK 9, we are stuck building FX with jdk-9+109 until https://bugs.openjdk.java.net/browse/JDK-8161704 is fixed. -- Kevin >> And there are may be some external apps has been using this API. No? > > It will not be accessible to applications in jdk. > >>> >>> On 29.09.16 10:55, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153522 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153522/webrev.00/ >>>> >>>> LightweightFrame Swing embedding API is updated for capability with >>>> floating point scale to make JavaFX SwingNode correctly shown on >>>> Windows >>>> platform. >>>> >>>> Backward API compatibility is preserved but methods with old >>>> signatures >>>> are marked as deprecated. >>>> >>>> --Semyon >>>> >>> >>> >> > > From semyon.sadetsky at oracle.com Fri Sep 30 16:42:54 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 30 Sep 2016 19:42:54 +0300 Subject: [9] Review request for 8153522: Update JLightweightFrame to allow non-integer (and X/Y) scales In-Reply-To: <57EE917A.9080007@oracle.com> References: <4078c9d6-7ce9-497d-9f28-74eaaa22c3f5@oracle.com> <61324c09-32cd-727e-7999-8aaf1c8756ae@oracle.com> <57EE917A.9080007@oracle.com> Message-ID: On 9/30/2016 7:23 PM, Kevin Rushforth wrote: > > > Sergey Bylokhov wrote: >> On 29.09.16 17:13, Semyon Sadetsky wrote: >>> On 9/29/2016 3:51 PM, Sergey Bylokhov wrote: >>> >>>> Why we need the old API since it is sun.awt package? >>> For compatibility. SwingNode doesn't yet use the new one. >> >> Probably Kevin can provide some info on how we usually synchronize >> the changes between jdk and FX, I assume that we should save the old >> one and remove them after FX will use it as a boot/minimum jdk? > > Yes, that is how we would typically do this. And to add to the problem > for JDK 9, we are stuck building FX with jdk-9+109 until > https://bugs.openjdk.java.net/browse/JDK-8161704 is fixed. > > -- Kevin Did you mean I need to keep both class versions (old and new) with different names? But the old class version is not required for compilation. You will be able to build FX using b109 after the fix. --Semyon > > >>> And there are may be some external apps has been using this API. No? >> >> It will not be accessible to applications in jdk. >> >>>> >>>> On 29.09.16 10:55, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153522 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153522/webrev.00/ >>>>> >>>>> LightweightFrame Swing embedding API is updated for capability with >>>>> floating point scale to make JavaFX SwingNode correctly shown on >>>>> Windows >>>>> platform. >>>>> >>>>> Backward API compatibility is preserved but methods with old >>>>> signatures >>>>> are marked as deprecated. >>>>> >>>>> --Semyon >>>>> >>>> >>>> >>> >> >> From kevin.rushforth at oracle.com Fri Sep 30 17:51:15 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 30 Sep 2016 10:51:15 -0700 Subject: [9] Review request for 8153522: Update JLightweightFrame to allow non-integer (and X/Y) scales In-Reply-To: References: <4078c9d6-7ce9-497d-9f28-74eaaa22c3f5@oracle.com> <61324c09-32cd-727e-7999-8aaf1c8756ae@oracle.com> <57EE917A.9080007@oracle.com> Message-ID: <57EEA613.8090009@oracle.com> Semyon Sadetsky wrote: > > > On 9/30/2016 7:23 PM, Kevin Rushforth wrote: >> >> >> Sergey Bylokhov wrote: >>> On 29.09.16 17:13, Semyon Sadetsky wrote: >>>> On 9/29/2016 3:51 PM, Sergey Bylokhov wrote: >>>> >>>>> Why we need the old API since it is sun.awt package? >>>> For compatibility. SwingNode doesn't yet use the new one. >>> >>> Probably Kevin can provide some info on how we usually synchronize >>> the changes between jdk and FX, I assume that we should save the old >>> one and remove them after FX will use it as a boot/minimum jdk? >> >> Yes, that is how we would typically do this. And to add to the >> problem for JDK 9, we are stuck building FX with jdk-9+109 until >> https://bugs.openjdk.java.net/browse/JDK-8161704 is fixed. >> >> -- Kevin > Did you mean I need to keep both class versions (old and new) with > different names? > But the old class version is not required for compilation. You will be > able to build FX using b109 after the fix. As long as FX (built with 109 as boot JDK) will also continue to run on the latest JDK then that's what matters. I haven't actually looked at the change to see whether there is a problem. I was just answering the general question of how we usually migrate to new JDK API to avoid breaking things. -- Kevin > > --Semyon >> >> >>>> And there are may be some external apps has been using this API. No? >>> >>> It will not be accessible to applications in jdk. >>> >>>>> >>>>> On 29.09.16 10:55, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8153522 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8153522/webrev.00/ >>>>>> >>>>>> LightweightFrame Swing embedding API is updated for capability with >>>>>> floating point scale to make JavaFX SwingNode correctly shown on >>>>>> Windows >>>>>> platform. >>>>>> >>>>>> Backward API compatibility is preserved but methods with old >>>>>> signatures >>>>>> are marked as deprecated. >>>>>> >>>>>> --Semyon >>>>>> >>>>> >>>>> >>>> >>> >>> > From jbluettduncan at gmail.com Fri Sep 30 16:08:58 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Fri, 30 Sep 2016 17:08:58 +0100 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK In-Reply-To: References: Message-ID: Hi Sergey, I'm not a reviewer, but after reading the deprecation messages in Event.java * @deprecated It is recommended that {@code AWTEvent} class and its > subclasses > * be used instead. I get the impression they would read better without the redundant "class" in the middle, like so. * @deprecated It is recommended that {@code AWTEvent} and its subclasses > * be used instead. Kind regards, Jonathan On 30 September 2016 at 16:45, Sergey Bylokhov wrote: > Hello. > > Please review the fix for jdk9. > > This is request to deprecate the obsolete flags inside InputEvent. This > constants were marked as obsolete in jdk1.4 and were replaced by the new > one. In jdk1.4 the documentation were update with notion that the new > constants should be used. And this bug is about official deprecation of > them. > > We can replace old constants by the new one in the whole jdk, but I > updated only the code in InputEvent to make change smaller and safer. So at > least the new code in jdk and the code in applications will start to use > the new constants. > > The changes in jconsole are necessary to fix deprecation warning. > > jprt build passed, no new issues were found by jck/jtreg tests. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143077 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00 > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Fri Sep 30 16:24:08 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 30 Sep 2016 18:24:08 +0200 Subject: [9] Review Request: 8143077 Deprecate InputEvent._MASK in favor of InputEvent._DOWN_MASK In-Reply-To: <38FC8343-B900-4D18-86AA-D882DD9B9F43@oracle.com> References: <38FC8343-B900-4D18-86AA-D882DD9B9F43@oracle.com> Message-ID: <57EE91A8.9010808@oracle.com> Looks good. Erik > On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov wrote: > > Hello. > > Please review the fix for jdk9. > > This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug is about official deprecation of them. > > We can replace old constants by the new one in the whole jdk, but I updated only the code in InputEvent to make change smaller and safer. So at least the new code in jdk and the code in applications will start to use the new constants. > > The changes in jconsole are necessary to fix deprecation warning. > > jprt build passed, no new issues were found by jck/jtreg tests. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143077 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00 > > -- > Best regards, Sergey.