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
>>
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: *
> 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
>
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
>>
> 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
>
> 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
>
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
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:
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
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
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
>>>
> 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
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:
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
14 matches
Mail list logo
