Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v5]
On Thu, 17 Jun 2021 20:49:59 GMT, Alexander Zvegintsev wrote: >> This fix is to explicitly specify that `Taskbar::getIconImage` may return an >> object different from passed to `Taskbar::setIconImage`. >> >> Actually it is always returns a different object on macOS(the only OS which >> supports this feature), but I want to save some options if we decide to >> rework this. > > Alexander Zvegintsev has updated the pull request incrementally with one > additional commit since the last revision: > > @apiNote added, Suggests -> Requests Marked as reviewed by prr (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3250
Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v4]
On Thu, 17 Jun 2021 20:31:07 GMT, Phil Race wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> header fix > > src/java.desktop/share/classes/java/awt/Taskbar.java line 341: > >> 339: /** >> 340: * Obtains an image of this application's icon. >> 341: * > > As discussed off-line, preface this with "@apiNote" updated - PR: https://git.openjdk.java.net/jdk/pull/3250
Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v5]
> This fix is to explicitly specify that `Taskbar::getIconImage` may return an > object different from passed to `Taskbar::setIconImage`. > > Actually it is always returns a different object on macOS(the only OS which > supports this feature), but I want to save some options if we decide to > rework this. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: @apiNote added, Suggests -> Requests - Changes: - all: https://git.openjdk.java.net/jdk/pull/3250/files - new: https://git.openjdk.java.net/jdk/pull/3250/files/312abff4..4e5273e5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3250=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3250=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250 PR: https://git.openjdk.java.net/jdk/pull/3250
Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v4]
On Thu, 17 Jun 2021 17:33:48 GMT, Alexander Zvegintsev
wrote:
>> This fix is to explicitly specify that `Taskbar::getIconImage` may return an
>> object different from passed to `Taskbar::setIconImage`.
>>
>> Actually it is always returns a different object on macOS(the only OS which
>> supports this feature), but I want to save some options if we decide to
>> rework this.
>
> Alexander Zvegintsev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> header fix
src/java.desktop/share/classes/java/awt/Taskbar.java line 325:
> 323:
> 324: /**
> 325: * Suggests the system to change this application's icon to the
> provided {@code image}.
Suggests -> Requests
src/java.desktop/share/classes/java/awt/Taskbar.java line 341:
> 339: /**
> 340: * Obtains an image of this application's icon.
> 341: *
As discussed off-line, preface this with "@apiNote"
-
PR: https://git.openjdk.java.net/jdk/pull/3250
Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v4]
> This fix is to explicitly specify that `Taskbar::getIconImage` may return an > object different from passed to `Taskbar::setIconImage`. > > Actually it is always returns a different object on macOS(the only OS which > supports this feature), but I want to save some options if we decide to > rework this. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: header fix - Changes: - all: https://git.openjdk.java.net/jdk/pull/3250/files - new: https://git.openjdk.java.net/jdk/pull/3250/files/b5432e78..312abff4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3250=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3250=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250 PR: https://git.openjdk.java.net/jdk/pull/3250
Re: RFR: 8264125: Specification of Taskbar::getIconImage doesn't mention that the returned image might not be equal to the Taskbar::setIconImage one. (eg on Mac OS) [v3]
> This fix is to explicitly specify that `Taskbar::getIconImage` may return an > object different from passed to `Taskbar::setIconImage`. > > Actually it is always returns a different object on macOS(the only OS which > supports this feature), but I want to save some options if we decide to > rework this. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: update - Changes: - all: https://git.openjdk.java.net/jdk/pull/3250/files - new: https://git.openjdk.java.net/jdk/pull/3250/files/a265fc99..b5432e78 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3250=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3250=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3250.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3250/head:pull/3250 PR: https://git.openjdk.java.net/jdk/pull/3250
Re: [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Wed, 16 Jun 2021 10:34:50 GMT, Alexey Ushakov wrote: >> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159: >> >>> 157: [computeEncoder endEncoding]; >>> 158: [cb commit]; >>> 159: #endif >> >> This is better than changing the background color, but should be carefully >> checked. @jayathirthrao @aghaisas please take a look. >> Since this affects every blit to the window I suggest running a full test >> run. > > @jayathirthrao @aghaisas please let me know if I can push this change into > JDK17 repository @avu If all our automated tests are green but we still have some issues, then an additional automated test needs to be added. - PR: https://git.openjdk.java.net/jdk17/pull/62
Re: [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov wrote: > Implemented blit via compute kernel What I have observed with this patch is - It does not break all shaped or translucent windows - but, a manual JCK test does show the black background. - PR: https://git.openjdk.java.net/jdk17/pull/62
Re: [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov wrote: > Implemented blit via compute kernel With this patch shaped windows with translucent/color background are showing only black background. In manual JCK shaped window test also this difference in behaviour is seen. This behaviour difference can be checked using Ruler.java test case attached in https://bugs.openjdk.java.net/browse/JDK-8267963 - PR: https://git.openjdk.java.net/jdk17/pull/62
Re: [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Thu, 17 Jun 2021 07:06:24 GMT, Jayathirth D V wrote: >> Implemented blit via compute kernel > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136: > >> 134: NSUInteger w = computePipelineState.threadExecutionWidth; >> 135: >> 136: // Workaround for some OS/device bug reporting incorrect >> maxTotalThreadsPerThreadgroup > > @avu Do we know in which hardware we have this issue? Also do we have any > reference to Apple bug? > Also if we use thread group as 1 what is the performance impact in such > hardware? Forced maxTotalThreadsPerThreadgroup to 1 and tested in Intel SoC 2015 Macbook Pro, as expected i see almost ~50% reduction in FPS numbers in many use cases in RenderPerfTest. This final blit hits common operation and we would be able to make better decision whether this performance reduction is okay or not based on hardware in which we are seeing Apple bug. - PR: https://git.openjdk.java.net/jdk17/pull/62
Re: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled
On Mon, 14 Jun 2021 19:26:46 GMT, Phil Race wrote:
>>> As far as I understand it is not directly related to the JTable and the bug
>>> is reproduced if some specific font is used when any text is printed? Did
>>> you check why the CTextPipe does not support it directly? It looks like the
>>> JavaCT_DrawGlyphVector uses pure core graphics, which I think should
>>> support this font?
>>
>> Hi Sergey, Thank you for the comments.
>>
>> JTable is not directly related, but it has child JComponents under texts.
>> It's the trigger to meet the conditions to call the function.
>>
>> In this case, the font was specified as "LucidaGrande" or "Dialog" by L
>> Non English character to print is another condition.
>> sun.font.CFont creates a composite font by the standard Mac cascade list. In
>> my environment, font[4] is Japanese font, even if it's CFont("LucidaGrande").
>>
>> CTextPipe.doDrawGlyphs uses one strike pointer, which is for one font. To
>> support composite fonts, I think CTextPipe needs to handle array of strikes,
>> and to switch fonts by slot data. I don't think this is a right way.
>>
>> CTextPipe.drawGlyphVector receives only GlyphVector data and no Unicode
>> character data. So, we cannot use fallback methods.
>
> @toshiona - is this PR dead ?
@prrace
I'm deeply sorry for the long delay.
I completely changed the patch to use a different layer (SwingUtilities2.java).
> The immediately next method in this file, drawGlyphVector(..) surely would
> have the same problem ?
Yes, I had to say the bottom methods (Core Graphics Framework's
CGContextShowGlyphsWithAdvances and CGContextShowGlyphsAtPoint) seem no
capability to handle multi fonts.
> And then the drawChars method too ?
No. If we can use Unicode codes, fallback mechanism can work.
> Does this not in fact affect all code points for which the slot != 0 ?
Yes. I believe all slot !=0 glyphs have the issue.
> Do we really want to print all code points from slot > 0 as shapes ?
No, it's a kind of workaround. I thought the effects of the change can be
minimized.
> And if this code isn't expecting to handle composite fonts, how did we get
> here with one ?
> Or maybe the problem is that the printing path code needs to handle this
> downstream not upstream ?
The new version changed the branching conditions. If it's MacOS, that won't
branch to the printing path, which uses Glyph codes.
Well, I still couldn't create an automate test.
I appreciate any advices.
-
PR: https://git.openjdk.java.net/jdk/pull/3619
Re: RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled [v2]
> Hi, > > Could you review the fix? > When non-English characters were printed from JTable on MacOS, > CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, > CTextPipe seems not support glyph with slot number of composite fonts. > > The slot data mask of GlyphVector is 0xff00. In my environment, Japanese > font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, > unexpected glyph was drawn. > > This patch checks slot data of each character. If slot data exists, it will > branch to GlyphVector's drawing path. > > Well, I couldn't create automatic test for this fix. This method seems to be > called for printing only. I appreciate any advice. > Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. > > Regards, > Toshio Nakamura Toshio Nakamura has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 2nd proposal - Revert previous change - Merge branch 'master' into 8240756 merge master - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled - Changes: - all: https://git.openjdk.java.net/jdk/pull/3619/files - new: https://git.openjdk.java.net/jdk/pull/3619/files/9d99458c..c2910791 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3619=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3619=00-01 Stats: 1152276 lines in 9449 files changed: 556262 ins; 566916 del; 29098 mod Patch: https://git.openjdk.java.net/jdk/pull/3619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619 PR: https://git.openjdk.java.net/jdk/pull/3619
Re: [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Wed, 16 Jun 2021 11:57:01 GMT, Jayathirth D V wrote: >> @jayathirthrao @aghaisas please let me know if I can push this change into >> JDK17 repository > > @avu i have given all test run. I will get back to you once it is done. Automated jtreg/JCK test run is green. - PR: https://git.openjdk.java.net/jdk17/pull/62
Re: [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov wrote: > Implemented blit via compute kernel src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136: > 134: NSUInteger w = computePipelineState.threadExecutionWidth; > 135: > 136: // Workaround for some OS/device bug reporting incorrect > maxTotalThreadsPerThreadgroup @avu Do we know in which hardware we have this issue? Also do we have any reference to Apple bug? Also if we use thread group as 1 what is the performance impact in such hardware? - PR: https://git.openjdk.java.net/jdk17/pull/62
