Re: RFR: 8181571: printing to CUPS fails on mac sandbox app [v3]

On Thu, 12 Aug 2021 19:34:44 GMT, Phil Race wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Return null if printers are not found in sandboxed app on MacOS > > src/java.

Re: RFR: 8181571: printing to CUPS fails on mac sandbox app [v3]

cupsServer() function and not changing the interface string to >> "localhost". >> Security changes in 10.12.4 reject the TCP connection which they say confuses >> network-client access with print access. They don't seem interested in >> loosening that change. > >

Re: RFR: 8181571: printing to CUPS fails on mac sandbox app [v2]

cupsServer() function and not changing the interface string to >> "localhost". >> Security changes in 10.12.4 reject the TCP connection which they say confuses >> network-client access with print access. They don't seem interested in >> loosening that change. > >

Re: RFR: 8181571: printing to CUPS fails on mac sandbox app

On Wed, 28 Jul 2021 17:18:12 GMT, NikolayTach wrote: > [JDK-8247768 ](https://bugs.openjdk.java.net/browse/JDK-8247768) > Same here played 6 times yet moved, 8 issues missed. What is the relation between JDK-8247768 and the current pull request? Should something be updated in the pull request

Integrated: 8265761: Font with missed font family name is not properly printed on Windows

On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses > [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) > method wi

Re: RFR: 8265761: Font with missed font family name is not properly printed on Windows [v2]

On Wed, 28 Apr 2021 13:55:28 GMT, Alexander Scherbatiy wrote: >> PDFBox 1.8 uses >> [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) >>

Re: RFR: 8265761: Font with missed font family name is not properly printed on Windows [v2]

e fix properly prints all three lines: > [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font > with empty font family name. Alexander Scherbatiy has

Re: RFR: 8265761: Font with missed font family name is not properly printed on Windows

On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses > [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) > method wi

Re: RFR: 8265761: Font with missed font family name is not properly printed on Windows

On Sun, 25 Apr 2021 20:53:11 GMT, Sergey Bylokhov wrote: >> Would it be better to use isBlank() instead of isEmpty() to check a font >> family name is blank? >> >> if (family.isBlank()) { >> return false; >> } > > I think so. I changed the test SampleBow font

Re: RFR: 8265761: Font with missed font family name is not properly printed on Windows

On Fri, 23 Apr 2021 07:02:45 GMT, Sergey Bylokhov wrote: >> PDFBox 1.8 uses >> [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) >> method with scaled glyphs

Re: RFR: 8265761: Font with missed font family name is not properly printed on Windows

On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses > [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) > method wi

RFR: 8265761: Font with missed font family name is not properly printed on Windows

PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses

Integrated: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows

On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy wrote: > Printing text using GlyphVector outline has bad quality on printers with low > DPI on Windows. > The GDI system used for text printing on Windows accepts only integer path > coordinates. > Rounding GlyphVector outl

Re: RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows [v2]

est.java > java/awt/print/PrinterJob/PrintLatinCJKTest.java > java/awt/print/PrinterJob/PrintTextTest.java > java/awt/print/PrinterJob/SwingUIText.java > java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java > java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlo

Re: RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows [v2]

On Wed, 10 Mar 2021 09:31:32 GMT, Prasanta Sadhukhan wrote: >> Alexander Scherbatiy has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Use DASSERT to check SetGraphicsMode and WorldTransform results >> -

RFR: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows

Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. The GDI system used for text printing on Windows accepts only integer path coordinates. Rounding GlyphVector outline coordinates leads to distorted printed text. The issue had been reported as

Integrated: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows

On Thu, 12 Nov 2020 10:32:16 GMT, Alexander Scherbatiy wrote: > Printing text using GlyphVector outline has bad quality on printers with low > DPI on Windows. > The GDI system used for text printing on Windows accepts only integer path > coordinates. > Rounding GlyphVector outl

Re: RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows

On Sat, 28 Nov 2020 20:07:22 GMT, Sergey Bylokhov wrote: >> I prepared a simple [print >> test](http://cr.openjdk.java.net/~alexsch/8256264/performance/PrintTextPerformanceTest.java) >> sample which uses 4 different fonts (plain and bold) with different sizes >> and prints 640 lines on 10

Re: RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows [v3]

bled "sun.java2d.print.enablePathPrecisionScale" option. > > [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) > shows difference of GlyphVector outline printing before and after the fix. Alexander

Re: RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows

On Fri, 20 Nov 2020 06:31:24 GMT, Sergey Bylokhov wrote: >> Printing text using GlyphVector outline has bad quality on printers with low >> DPI on Windows. >> The GDI system used for text printing on Windows accepts only integer path >> coordinates. >> Rounding GlyphVector outline coordinates

Re: RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows [v2]

bled "sun.java2d.print.enablePathPrecisionScale" option. > > [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) > shows difference of GlyphVector outline printing before and after the fix. Alexander

RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows

Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. The GDI system used for text printing on Windows accepts only integer path coordinates. Rounding GlyphVector outline coordinates leads to distorted printed text. To reproduce the issue run the

RFR: 8245938 Remove unused print_stack(void) method from XToolkit.c

Hello, Could you review a simple cleanup 8245938 Remove unused print_stack(void) method from XToolkit.c   Bug: https://bugs.openjdk.java.net/browse/JDK-8245938   Fix: http://cr.openjdk.java.net/~alexsch/8245938/webrev.00 The unused print_stack function is removed from XToolkit.c. The reason

Re: [OpenJDK 2D-Dev] [9] Review Request: 8177461 Wrong references are used in the javadoc in the java.desktop module

The fix looks good to me. Thanks, Alexandr. On 23/03/17 18:24, Sergey Bylokhov wrote: Hello, Please review the fix for jdk9. In java.desktop module in a various places we use incorrect links. Most of them are in the documentation in non-public classes/methods(But there are two places in

[9] Review request for 8177625 apple.laf.JRSUIConstants.getConstantName(int) checks for THUMB_START twice

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8177625 webrev: http://cr.openjdk.java.net/~alexsch/8177625/webrev.00 The typo with twice used THUMB_START constant is fixed. Thanks, Alexandr.

Re: [9] Review request for 8175301 Java GUI hangs on Windows when Display set to 125%

Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8175301/webrev.01 There are two places where D3DSurfaceData.swapBuffers() is called D3DScreenUpdateManager.run() and D3DGraphicsConfig.flip(...). D3DScreenUpdateManager.run() uses the surface bounds which are

Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

he high-resolution image into it using a specific scale and rendering hints. Thanks, Alexandr. Regards, Prem *From:*Alexander Scherbatiy *Sent:* Thursday, October 13, 2016 3:21 PM *To:* Prem Balakrishnan; Sergey Bylokhov; awt-dev@openjdk.java.net <mailto:awt-dev@openjdk.java.net> *Su

Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

On 06/10/16 15:28, Prem Balakrishnan wrote: Hi*,* ** Please review fix for JDK 9, *Bug:*https://bugs.openjdk.java.net/browse/JDK-8162959 *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/ I have adapted the same

Re: [9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

On 30/09/16 19:48, Alexander Scherbatiy wrote: On 30/09/16 19:33, Sergey Malenkov wrote: I'm not sure. It can be a "false" scrolling when you accidentally touched a Magic Mouse. I think we should use threshold on the phase end, to ignore accumulatedDelta less than 0.1 Could

Re: [9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

tation=0,preciseWheelRotation=-0.0222015380859375 wheelRotation=0,preciseWheelRotation=-0.0233306884765625 We ignored first two events, because of 0 & 0.0 We should not ignore last event, where 1 & 0.0 Seems we need to fix DeltaAccumulator. On Fri, Sep 30, 2016 at 2:25 PM, Alexan

Re: [9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

e better if the the scroll will start immediately on first touch? On 30.09.16 17:59, Alexander Scherbatiy wrote: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8166591/webrev.06 - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch a scroll event

Re: [9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

=-0.0222015380859375 wheelRotation=0,preciseWheelRotation=-0.0233306884765625 We ignored first two events, because of 0 & 0.0 We should not ignore last event, where 1 & 0.0 Seems we need to fix DeltaAccumulator. On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy <alexandr.scherba...@oracle.com>

Re: [9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8166591/webrev.05 The momentumPhase is used to detect the trackpad events. Thanks, Alexandr. On 30/09/16 14:58, Sergey Malenkov wrote: # C [AppKit+0x3a528e] -[NSApplication _crashOnException:]+0x6d The app is

Re: [9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8166591/webrev.04 The fix uses the proposed changes below and sets a wheel rotation to +1 or -1 when the scroll phase is ended and the accumulates delta value is small than the threshold. Thanks, Alexandr. On

Re: [9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8166591/webrev.03 - NSEvent constructor call is updated in the CTrayIcon.m - The SCROLL_MASK_PHASE_CANCELLED and SCROLL_MASK_PHASE_ENDED scroll masks are added. Thanks, Alexandr. On 29/09/16 17:29, Sergey

Re: RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are not accessible

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:

[9] Review request for 8166591 [macos 10.12] Trackpad scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8166591 webrev: http://cr.openjdk.java.net/~alexsch/8166591/webrev.02 This issue has been risen and investigated by JetBrains team in the email:

Re: [9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention

On 10/08/16 19:24, Alexandr Scherbatiy wrote: On 8/9/2016 11:18 AM, Rajeev Chamyal wrote: Hello All, Please review the following webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8151787 Webrev: http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/

Re: [9] Review request for JDK-7156316: [macosx] Ctrl+Space does generate Unknown keychar

On 27/06/16 21:57, Manajit Halder wrote: Hi All, Kindly review the fix for JDK9. *Bug*: https://bugs.openjdk.java.net/browse/JDK-7156316 _ _ *Webrev*: http://cr.openjdk.java.net/~mhalder/7156316/webrev.00/ *Issue: * [macosx]

Re: [9] Review Request: 8157320 The CheckboxMenuItem can not be selected

The fix looks good to me. Thanks, Alexandr. On 25/05/16 00:43, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. The fix for JDK-6191390 [1] does not take into account that the action(final long when) method is overridden in the XCheckboxMenuItemPeer.java and after JDK-6191390

Re: [8] Review request for JDK-8158178: java.awt.SplashScreen.getSize() returns incorrect size for high dpi splash screens

The fix looks good to me. Thanks, Alexandr. On 31/05/16 00:14, Robin Stevens wrote: Hello, please review the patch for JDK-8158178 (https://bugs.openjdk.java.net/browse/JDK-8158178): http://cr.openjdk.java.net/~alexsch/robin.stevens/8158178/jdk8/webrev.00/

Re: [9] Review request for JDK-8158178 java.awt.SplashScreen.getSize() returns incorrect size for high dpi splash screens

The fix looks good to me. Thanks, Alexandr. On 31/05/16 00:13, Robin Stevens wrote: Hello, Please review the update to the MultiResolutionSplashTest http://cr.openjdk.java.net/~alexsch/robin.stevens/8158178/webrev.00/

Re: [9] Review Request: 8155785 Add @Deprecated annotations to the Applet API classes

The fix looks good to me. Thanks, Alexandr. On 13/05/16 06:56, Sergey Bylokhov wrote: cc swing-dev. Looks fine. On 13.05.16 4:41, Daniil Titov wrote: Hello, Please review the fix for JDK 9. The fix adds @Deprecated annotations to the Applet API classes as per JEP 289 “Deprecate

Re: [9] Review request for 8154539 Examine the desktop module's use of sun.misc.SoftCache

Cache$ValueCell". Thanks, Alexandr. ? -phil. On 5/11/16, 2:59 PM, Mandy Chung wrote: On May 11, 2016, at 2:55 PM, Alexander Scherbatiy<alexandr.scherba...@oracle.com> wrote: On 12/05/16 01:50, Phil Race wrote: Alexander ... I am concurrently deleting GThreadHelper (see webrev I just

Re: [9] Review request for 8154539 Examine the desktop module's use of sun.misc.SoftCache

to the java.desktop module. Thanks, Alexandr. On 12/05/16 00:15, Mandy Chung wrote: On May 11, 2016, at 1:07 PM, Alexander Scherbatiy <alexandr.scherba...@oracle.com> wrote: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8154539 webrev

[9] Review request for 8154539 Examine the desktop module's use of sun.misc.SoftCache

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8154539 webrev: http://cr.openjdk.java.net/~alexsch/8154539/webrev.00 This is a request from the jigsaw team to get rid of the dependency to jdk.unsupported module from the java.desktop module. The fix

Re: [9] Review request for 8017112 JTabbedPane components have inconsistent accessibility tree

necessary at the beginning of the method? Usually we use the "instance of" to get AccessibleContext in code like this: AccessibleContext accContext = ((Accessible)this).getAccessibleContext(); But it seems we have not the cast here, or it is necessary for some reason? On 28.04.16 22:39, Alexan

Re: [9] Review request for JDK-8151787 Unify the HiDPI splash screen image naming convention

The fix looks good to me. Thanks, Alexandr. On 29/04/16 13:49, Rajeev Chamyal wrote: Hello Alexandr, Please review the updated fix. http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/ - Will the java-scale2x image be chosen

[9] Review request for 8017112 JTabbedPane components have inconsistent accessibility tree

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8017112 webrev: http://cr.openjdk.java.net/~alexsch/8017112/webrev.00 Component.getAccessibleIndexInParent() takes parent from components hierarchy which can be different from the accessibility tree

Re: [9] Review request for 8132706 [macosx] Toolkit.getImage() throws NPE for null URL

On 18/04/16 20:55, Sergey Bylokhov wrote: On 18.04.16 18:36, Alexander Scherbatiy wrote: On 4/15/2016 10:55 PM, Sergey Bylokhov wrote: On 15.04.16 21:49, Phil Race wrote: I think that even if no exception is thrown we ought to document what happens. Which of course means that we need

Re: [9] Review request for 8132706 [macosx] Toolkit.getImage() throws NPE for null URL

is called with ABORT info flag. The case with null path or URL should follow the same ToolkitImage errors handling rule. Thanks, Alexandr. -phil. On 04/15/2016 11:47 AM, Alexander Scherbatiy wrote: On 15/04/16 22:11, Phil Race wrote: And it prints the stack trace ?? This gets ev

Re: [9] Review request for 8147842: IME Composition Window is displayed at incorrect location

On 4/1/2016 1:29 PM, Semyon Sadetsky wrote: Please review the updated version : http://cr.openjdk.java.net/~ssadetsky/8147842/webrev.01/ fix was changed to avoid possible recursion in native IME evens handling which the SendMessage() call might cause. The SendMessage call has been added

Re: [9] Review request for 8132706 [macosx] Toolkit.getImage() throws NPE for null URL

On 15/04/16 22:54, Sergey Bylokhov wrote: On 15.04.16 21:47, Alexander Scherbatiy wrote: If the second option is acceptable probably the Toolkit.getImage() javadoc can be updated. As far as I understand, we always throw NPE in case of SecManager, and throw NPE w/o secManager since 7u40

Re: [9] Review request for 8132706 [macosx] Toolkit.getImage() throws NPE for null URL

the NPE. The second one can break some old applications which do not expect that the exception can be thrown in this case. If the second option is acceptable probably the Toolkit.getImage() javadoc can be updated. Thanks, Alexandr. -phil. On 04/15/2016 11:10 AM, Alexander Scherbatiy

Re: [9] Review Request: 8154016 [macosx] Some HiDPI code can be removed

The fix looks good to me. Thanks, Alexandr. On 15/04/16 20:22, Sergey Bylokhov wrote: Hello, Please review the fix for jdk9. Noop code was removed. It was not removed before, because it was assumed that it can be reused for HiDPI support(but it was implemented differently) Bug:

Re: [9] Review request for 8132706 [macosx] Toolkit.getImage() throws NPE for null URL

can rely on. I am not sure if it is now possible to change the Toolkit.getImage(URL) method behavior that it does not throw NPE with null URL when the SecurityManager is set. Thanks, Alexandr. Regards Prasanta On 4/15/2016 8:32 PM, Alexander Scherbatiy wrote: Hello, Could you review

[9] Review request for 8132706 [macosx] Toolkit.getImage() throws NPE for null URL

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8132706 webrev: http://cr.openjdk.java.net/~alexsch/8132706/webrev.00 The fix makes the Toolkit.getDefaultToolkit().getImage(URL) return a ToolkitImage based on URLImageSource with null url as it was before

Re: Public RequestFocusController/AWTAccessor API

Hello Reto, Could you provide use cases which illustrate tasks the requested API is intended to solve in your application? Please, also create a request in the bug system http://bugreport.java.com/bugreport Thanks, Alexandr. On 11/04/16 12:26, Alexander Scherbatiy wrote

Re: Public RequestFocusController/AWTAccessor API

Resending the request to awt-dev alias. Thanks, Alexandr. On 4/4/2016 4:54 PM, Reto Merz wrote: Hello, Jigsaw will disallow access to internal packages. We have written a complex validation and focus management implementation for our closed-source RIA and maintain it since JRE 1.4. For

Re: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support

e to allow non-integer (and X/Y) scales https://bugs.openjdk.java.net/browse/JDK-8153522 Thanks, Alexandr. ...jim On 9/22/2015 2:33 AM, Alexander Scherbatiy wrote: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8073320 we

Re: [9] Review Request for 8080395: consider making sun.awt.CausedFocusEvent functionality public

during deserialization. - readResolve() is added to FocusEvent to handle the null cause test. - deserialization compatibility test scenarios added --Semyon On 11/6/2015 3:57 PM, Alexander Scherbatiy wrote: There is a problem with FocusEvent deserialization that the read cause value is not checked to

Re: [9] Review Request: 8151773 [macosx] TrayIcon.imageAutoSize property is ignored

The fix looks good to me. Thanks, Alexandr. On 15/03/16 04:54, Sergey Bylokhov wrote: Hello, Please review the small fix for jdk9. According to specification if imageAutoSize property was set to true the image should be the stretched or shrunk to fit the tray icon space. But on OSX this

Re: [9] Review Request for several test bugs: 8150535, 8151033, 8151037 etc.

The fix looks good to me. Thanks, Alexandr. On 24/03/16 18:17, Yuri Nesterenko wrote: Hi, please review this test-only fix, a leftover from Jigsaw M3 integration. Some 7 tests fixed but note that not all of them always pass even fixed. Webrev: http://cr.openjdk.java.net/~yan/8150535/webrev.01

Re: [9] Review Request for 8036915: setLocationRelativeTo stopped working in Ubuntu 13.10 (Unity)

On 18/02/16 14:26, Semyon Sadetsky wrote: I have found the way to avoid iterative queries for frame insets. The updated webrev: http://cr.openjdk.java.net/~ssadetsky/8036915/webrev.01/ - 269 if (wm_set_insets != null && !isNull(wm_set_insets)) isNull(Insets i) function checks the given

Re: Review request for 8151998 VS2010 ThemeReader.cpp(758) : error C3861: 'round': identifier not found

Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8151998/webrev.01 The _MSC_VER predefined macros is used for the Visual Studio version detection. Thanks, Alexandr. On 3/16/2016 4:27 PM, Alexander Scherbatiy wrote: Hello, Could you review the fix: bug

Re: [9] Review request for JDK-8145173 HiDPI splash screen support on Windows

March 2016 18:26 To: Alexander Scherbatiy; Sergey Bylokhov; awt-dev@openjdk.java.net; build-...@openjdk.java.net Subject: RE: [9] Review request for JDK-8145173 HiDPI splash screen support on Windows Hello All, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8145173/webrev

Re: [9] Review request for 8150844 [hidpi] [macosx] should -Dsun.java2d.uiScale be taken into account for OS X?

so the test will fail on OS X until it is fixed (having this line removed). It should be fine because bug number 8151303 is mentioned in the @bug tag and is counted as a known issue. Thanks, Alexandr. On 3/16/2016 11:29 AM, Alexander Scherbatiy wrote: Hello, Could yo

Re: [9] RFR for 8151714: [TEST] add a manual test test for JOptionPane dialog multires. icons

The MultiResolutionJOptionPaneIconTest extends JFrame so it shoud be created and used on EDT as others Swing components. Thanks, Alexndr. On 14/03/16 18:26, Alexander Stepanov wrote: Hello Semyon, > JOptionPane.showInternalInputDialog() is an utility method Yes, the initial intention was

Review request for 8151998 VS2010 ThemeReader.cpp(758) : error C3861: 'round': identifier not found

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8151998 webrev: http://cr.openjdk.java.net/~alexsch/8151998/webrev.00 The fix uses the "ROUND_TO_INT(num) ((int) floor((num) + 0.5))" instead round function which is not compiled by VS2010. Thanks,

Re: [9] Review request for 8150844 [hidpi] [macosx] should -Dsun.java2d.uiScale be taken into account for OS X?

on OSX: try { 50 UIManager.setLookAndFeel( 51 "com.sun.java.swing.plaf.gtk.GTKLookAndFeel"); 52 } catch (Exception e) { 53 return; 54 } On 16.03.16 15:12, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjd

Re: [9] RFR for 8151714: [TEST] add a manual test test for JOptionPane dialog multires. icons

fix: http://cr.openjdk.java.net/~avstepan/8151714/webrev.02/ (the transform-based scale check was also removed as it seems that the fix for JDK-8150844 is near to be pushed). Thanks, Alexander On 3/16/2016 8:55 PM, Alexander Scherbatiy wrote: The MultiResolutionJOptionPaneIconTest extends JFr

Re: [9] Review request for 8150844 [hidpi] [macosx] should -Dsun.java2d.uiScale be taken into account for OS X?

ugScale) 257 : nativeGetScaleFactor(displayID)); 258 } else { 259 scale = 1; 260 } 261 } 262 On 16.03.16 11:29, Alexander Scherbatiy wrote: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8150844 webrev: http://cr.openjdk.java.net/~al

[9] Review request for 8150844 [hidpi] [macosx] should -Dsun.java2d.uiScale be taken into account for OS X?

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8150844 webrev: http://cr.openjdk.java.net/~alexsch/8150844/webrev.00 The sun.java2d.uiScale property is now used in CGraphicsDevice. The requested tests are updated. Thanks, Alexandr.

Re: [9] Review request for JDK-8145173 HiDPI splash screen support on Windows

: Alexander Scherbatiy Sent: 14 March 2016 17:28 To: Rajeev Chamyal Cc: Sergey Bylokhov; awt-dev@openjdk.java.net Subject: Re: [9] Review request for JDK-8145173 HiDPI splash screen support on Windows On 3/14/2016 8:03 AM, Rajeev Chamyal wrote: Hello Sergey, Could you please review

Re: [9] Review request for JDK-8145173 HiDPI splash screen support on Windows

Regards, Rajeev Chamyal *From:*Rajeev Chamyal *Sent:* 01 March 2016 15:45 *To:* awt-dev@openjdk.java.net <mailto:awt-dev@openjdk.java.net>; Sergey Bylokhov; Alexander Scherbatiy *Subject:* RE: [9] Review request for JDK-8145173

Re: [9] RFR for 8150724: [TEST] HiDPI: create a test for multiresolution icons

/2016 3:14 PM, Alexander Scherbatiy wrote: On 10/03/16 16:22, Alexander Stepanov wrote: Hello Alexandr, Thank you for the comment. Please note that: 1. this hard-coded icon size for the tab is seemingly used only for Mac OS X L, please see http://cr.openjdk.java.net/~avstepan/8150724/screenshots

Re: thoughts on multiresolution images

Hello Alan, Thank you for the feedback. On 04/03/16 19:59, Alan Snyder wrote: I am writing to share some thoughts based on recent experience using multiresolution images. My experience was not entirely pleasant. I am using JDK 8, although I see no relevant differences in JDK 9. One of

Re: [9] RFR for 8150724: [TEST] HiDPI: create a test for multiresolution icons

UI components look in the same way as native Mac OS X controls. In this case the tabbed pane icons should look like icons for NSTabView control. Thanks, Alexandr. Thanks, Alexander On 3/9/2016 7:10 PM, Alexander Scherbatiy wrote: On 03/03/16 18:45, Alexander Stepanov wrote: Could

Re: [9] RFR for 8151269: [TEST] add test covering getSource() method for multiresolution image

The test looks good to me. Thanks, Alexandr. On 04/03/16 17:17, Alexander Stepanov wrote: Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8151269/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8151269 ? Just a single test added. Thanks,

Re: [9] RFR for 8150724: [TEST] HiDPI: create a test for multiresolution icons

On 03/03/16 18:45, Alexander Stepanov wrote: Could you please review the updated version of the test? http://cr.openjdk.java.net/~avstepan/8150724/webrev.01 Line 106 tabbedPane.addTab("", icon, p); was replaced with 109 tabbedPane.addTab("", p); 110

Re: [9] Review request for JDK-8145174 HiDPI splash screen support on Linux

. I see. It can be an enhancement to support fractional scales too. For example image.java-scale150%.ext and image.java-scale144dpi.ext for scale factor 1.5. Thanks, Alexandr. Regards, Rajeev Chamyal *From:*Alexander Scherbatiy *Sent:* 18 February 2016 02:55 *To:* Rajeev Chamyal; awt-dev@op

Re: [9] Review request for JDK-8145174 HiDPI splash screen support on Linux

On 12/02/16 16:21, Rajeev Chamyal wrote: Hello All, Could you please review the following fix. Bug : https://bugs.openjdk.java.net/browse/JDK-8145174 Webrev : http://cr.openjdk.java.net/~rchamyal/8145174/webrev.00/ This is an

Re: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L on Win 8.1 with HiDPI display

be independent of the monitor in a multi-mon situation and so when we move to a 2nd monitor that inverted size remains valid ? If so looks good to me. -phil. On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsc

Re: Review Request for 8142861: [TEST_BUG] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI)

is still failing because of JDK-8143062. Should it be added to any exclude list? It is mentioned in the test @bug list. It should be enough because it means that the test should pass when the bug 8143062 is fixed. Thanks, Alexandr. Thanks, Alexander On 2/5/2016 1:51 PM, Alexander

Re: Review Request for 8142861: [TEST_BUG] MultiResolution image: add a manual test for two-display configuration (HiDPI + non-HiDPI)

There are just small comments about lines: 119 Graphics2D g = (Graphics2D) gr; 120 if (g != null) { g.drawImage(IMG, 0, 0, this); } Is it necessary to cast the Graphics to Graphics2D because Graphics also has drawImage(...) method? Is it necessary to check the

Re: Review Request for 8062946 : Transparent JDialog will lose transparency upon iconify/deiconify sequence.

pte/prem/8062946/webrev.01/> Regards, Prem *From:*Ambarish Rapte *Sent:* Tuesday, February 02, 2016 2:47 PM *To:* Alexander Scherbatiy; Prem Balakrishnan; Semyon Sadetsky; Sergey Bylokhov; Rajeev Chamyal; swing-...@openjdk.java.net <mailto:swing-...@openjdk.java.net&

Re: [9] Review request for 8147440 HiDPI (Windows): Swing components have incorrect sizes after changing display resolution

On 05/02/16 12:59, Alexander Stepanov wrote: Hello Alexandr, WRT WindowResizingOnDPIChangingTest - I have quite similar manual test on review: http://mail.openjdk.java.net/pipermail/awt-dev/2016-January/010569.html (but it requires two-display configuration). Could these tests coexist later

Re: [9] Review Request for 8139218: Dialog that opens and closes quickly changes focus in original focusowner

The fix looks good to me. Thanks, Alexandr. On 22/12/15 14:20, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8139218 webrev: http://cr.openjdk.java.net/~ssadetsky/8139218/webrev.00/ The root cause: when window gain focus come for

Review request for 8139508 Debug option does not work in appletviewer

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8139508 webrev: http://cr.openjdk.java.net/~alexsch/8139508/jdk9-client/webrev.00 The appletviewer debug support is removed. Thanks, Alexandr.

Re: Review Request for 8147966: [TEST] add a test for multiresolution image properties

The test looks good to me. Thanks, Alexandr. On 22/01/16 20:41, Alexander Stepanov wrote: Hello, Could you please review the fix http://cr.openjdk.java.net/~avstepan/8147966/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8147966 Just one simple test to cover

Re: [9] Review Request for 8146162: [TEST_BUG] sun/awt/shell/ShellFolderMemoryLeak.java fails with Jigsaw

The fix looks good to me. Thanks, Alexandr. On 11/01/16 17:56, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8146162 webrev: http://cr.openjdk.java.net/~ssadetsky/8146162/webrev.00/ @modules corrected and

Re: Review request for 8143316 Crash Trend in 1.9.0-ea-b93 (sun.awt.DefaultMouseInfoPeer.fillPointWithCoords)

/12/15 15:06, Alexander Scherbatiy wrote: Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8143316 webrev: http://cr.openjdk.java.net/~alexsch/8143316/webrev.00 The the native MouseInfo.fillPointWithCoords() method can access the devices before

Re: [9] Review Request for 8145795: [TEST_BUG][PIT] java/awt/Window/ScreenLocation/ScreenLocationTest.java fails (can assign Integer.MAX_VALUE to Window dimensions)

On 12/22/2015 6:41 PM, Semyon Sadetsky wrote: Right. This is regression of 8073320. Fix is annulled. Thanks. It would be better to update the test to take the scale factor into the account. Something like A_BIG_SIZE = Integer.MAX_VALUE / SCALE_FACTOR. Thanks, Alexandr.

Re: [9] Review Request for 8145784: https://bugs.openjdk.java.net/browse/JDK-8145784

The fix looks good to me. Thanks, Alexandr. On 12/23/2015 5:48 PM, Semyon Sadetsky wrote: The fix was changed because it is not possible to get individual screen windows under Xinerama correctly. Please, review the updated solution:

Re: Review request for 8041928: MouseEvent.getModifiersEx gives wrong result

The fix looks good to me. Thanks, Alexandr. On 12/23/2015 9:23 AM, Rajeev Chamyal wrote: Fix looks good to me. Regards, Rajeev Chamyal -Original Message- From: Ambarish Rapte Sent: 23 December 2015 01:32 To: Ambarish Rapte; Rajeev Chamyal; Sergey Bylokhov; Semyon Sadetsky;

Re: [9] Review Request for 8145795: [TEST_BUG][PIT] java/awt/Window/ScreenLocation/ScreenLocationTest.java fails (can assign Integer.MAX_VALUE to Window dimensions)

w object is placed and sized in a way that corresponds closely to the desktop settings." Thanks, Alexandr. --Semyon On 12/23/2015 6:41 PM, Alexander Scherbatiy wrote: On 12/22/2015 6:41 PM, Semyon Sadetsky wrote: Right. This is regression of 8073320. Fix is annulled. Thanks. It wo

Re: [9] Review Request: 8143054 [macosx] KeyEvent modifiers do not contain information about mouse buttons

The fix looks good to me. Thanks, Alexandr. On 11/18/2015 6:50 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk9. On macosx when we create a KeyEvent we ignore the mouse state of all mouse buttons, which means that mouse modifiers are missing. The only KeyEvent is

Re: [9] Review request for 8134152: Public API for java 8 DataFlavor fields do not have @since tag

The fix looks good to me. Thanks, Alexandr. On 30/11/15 18:40, Semyon Sadetsky wrote: +1 --Semyon On 11/30/2015 3:52 PM, Alexey Ivanov wrote: Hello, Please review the following documentation fix for jdk9: bug: https://bugs.openjdk.java.net/browse/JDK-8134152 webrev:

Re: Review Request for 8055197: TextField deletes multiline strings

. Many Thanks Ambarish -Original Message- From: Alexander Scherbatiy Sent: Friday, November 06, 2015 5:36 PM To: Ambarish Rapte Cc: awt-dev@openjdk.java.net Subject: Re: Review Request for 8055197: TextField deletes multiline strings On 11/5/2015 2:34 PM, Alexander Scherbatiy wrote: On 11/5

Review request for 8143064 Icons are not properly rendered with Windows L on HiDPI display

Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8143064 webrev: http://cr.openjdk.java.net/~alexsch/8143064/webrev.00 Icon image sizes are scaled in sun.swing.CachedPainter. Thanks, Alexandr.

  1   2   3   4   5   >