<Swing Dev> [9] Review request for 8156217 Selected text is shifted on HiDPI display

Semyon Sadetsky semyon.sadetsky at oracle.com
Thu Sep 1 15:49:44 UTC 2016


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 
>>>>>>>>>>>> <alexandr.scherbatiy at oracle.com 
>>>>>>>>>>>> <mailto:alexandr.scherbatiy at oracle.com>> 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: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20160901/03e492ed/attachment.html>


More information about the swing-dev mailing list