On Mon, 28 Feb 2022 23:27:50 GMT, DamonGuy <d...@openjdk.java.net> wrote:
>> Html does not fit in JButton at certain sizes because default Insets cause >> html to be displayed off-center. >> >> Changes made to SwingUtilities.java layoutCompoundLabelImpl method to enable >> clipping if html does not fit, similar to regular text. AquaButtonUI.java >> now detects when html does not fit, and an implementation for alternate >> insets that are recursively tested for regular text inside >> layoutAndGetText() are now also being used for html content. >> >> Created test (Bug8015854.java) with the same format as the test described on >> the issue. The button is of size 37x37 with an image of a red square sized >> 19x19. The test checks for red pixels on the edges of where the square image >> should be from the center of the button. The test fails with the non-changed >> jdk, but passes with the changes. > > DamonGuy has updated the pull request incrementally with one additional > commit since the last revision: > > Updated code organization. Removed unnecessary catch blocks and comments. > Added null check for frame disposal. Hi Jeremy, > _Mailing list message from [Jeremy Wood](mailto:micklen...@gmail.com) on > [client-libs-dev](mailto:client-libs-...@mail.openjdk.java.net):_ > > Damon: > > Sorry for joining this chat late. Is the core problem here that Swing is > positioning graphic elements incorrectly -- and those bad positions are > platform-independent? Yes, it looks that this issue is platform-independent and can be reproduced with other Look-and-Feels on other platforms. > > If so: this might be a good candidate for me to try to rewrite a test to > avoid the Robot class. I have a Graphics2D implementation > <https://github.com/mickleness/pumpernickel/blob/master/src/main/java/com/pump/graphics/vector/VectorGraphics2D.java> > that catalogs rendering operations. If just the act of reviewing those > catalogued instructions can detect the underlying problem: this might be a > simpler/faster alternative. (I?m assuming tests written using the Robot class > are more expensive to run and more brittle.) > > Does this sound like something that might benefit this test case? (I can have > a look at it in a few days.) > > Regards, - Jeremy The code you reference cannot be used in OpenJDK until _the author of the code_ contributes it to OpenJDK. You're right headful tests are more expensive to run. @prsadhuk mentioned that `Robot.getPixelColor` may produce an incorrect result which @honkar-jdk came across. In fact, @DamonGuy sees the artefacts too: on a High DPI display (and built-in Retina display of MacBook is a High DPI display), one pixel in user's space is represented with several physical pixels. In such a case, `getPixelColor` still returns only one pixel. In [Harshitha's](https://github.com/honkar-jdk) #7219, the table header border had 1px width. The robot correctly captured the specified part of the screen but the line was drawn on the second row of the physical pixels. Damon needs to account for antialiasing. The image needs to be scaled up for Retina display, its borders aren't sharp anymore. Painting the `JButton` to `BufferedImage` could resolve these problems, the test could check for the red color without adding a tolerance. If there's no frame and button is painted to `BufferedImage`, the test could be made _headless_. Perhaps, we should advise this approach when the test doesn't need to process any input. ------------- PR: https://git.openjdk.java.net/jdk/pull/7310
