On Mon, 15 Mar 2021 23:47:16 GMT, Phil Race wrote:
> Initial testing it looks OK with OpenGL but it renders as garbage with the
> metal pipeline.
> I'd guess metal isn't expecting 4bpp and the stride is wrong.
> I see updates in OGLTextRenderer so something similar likely needed for metal.
>
On Mon, 15 Mar 2021 18:04:26 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to
On Mon, 15 Mar 2021 10:25:50 GMT, Dmitry Batrak wrote:
> This is the implementation used by JetBrains Runtime for the last 4 years,
> after some cleanup, and with one problem,
> found while preparing the pull request, fixed.
> Even though typical scenarios for a UI application should be
On Mon, 15 Mar 2021 15:59:36 GMT, Alexey Ushakov wrote:
>> This is the implementation used by JetBrains Runtime for the last 4 years,
>> after some cleanup, and with one problem,
>> found while preparing the pull request, fixed.
>> Even though typical scenarios for a UI application should be
On Mon, 15 Mar 2021 18:57:28 GMT, Phil Race wrote:
>> From a build perspective this partially reverts
>> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
>> the harfbuzz sources separate and still supports building and running
>> against a system harfbuzz which is only of
On Mon, 15 Mar 2021 18:52:38 GMT, Magnus Ihse Bursie wrote:
> I was actually thinking that such a change would be simpler; more or less
> amounting to changing from LIBRARY to STATIC_LIBRARY. But if you feel that it
> is too much work, fine...
If you say so .. I have no idea what build
On Mon, 15 Mar 2021 18:35:12 GMT, Phil Race wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8255790: GTKL: Java 16 crashes on initialising GTKL on Manjaro Linux
>
>> Just thinking out loud, you don't think it would
> From a build perspective this partially reverts
> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
> the harfbuzz sources separate and still supports building and running against
> a system harfbuzz which is only of interest or relevance on Linux.
>
> I ended up having
On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes wrote:
>> Anton Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 114 commits:
>>
>> - JDK-8262491: bsd_aarch64 part
>> - JDK-8263002: bsd_aarch64 part
>> - Merge
On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley wrote:
>> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to
>> define the value for the macro?
>
> Robustness, clarity, maintainability, convention. Why not?
I've tried to implement the suggestion, but it pulled more
On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson wrote:
>> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block
>> belongs to Thread for now. Since W^X is an attribute of any operating system
>> thread, I assumed Thread to be the right place for W^X bookkeeping.
>>
>>
On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race wrote:
> From a build perspective this partially reverts
> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
> the harfbuzz sources separate and still supports building and running against
> a system harfbuzz which is only of
On Mon, 15 Mar 2021 10:46:45 GMT, Alexander Zvegintsev
wrote:
>> From a build perspective this partially reverts
>> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
>> the harfbuzz sources separate and still supports building and running
>> against a system harfbuzz
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
> In some cases wrapping of `InputStream` with `BufferedInputStream` is
> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
> not require any buffer having one within.
>
> Other cases are related to reading either a byte or short `byte[]`: in both
> cases
On Mon, 15 Mar 2021 18:01:20 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to
On Mon, 15 Mar 2021 15:04:49 GMT, Daniel Fuchs wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix error message
>
> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 434:
>
>> 432:
On Mon, 15 Mar 2021 12:19:19 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to
On Mon, 15 Mar 2021 12:19:19 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to
On Sat, 13 Mar 2021 00:34:33 GMT, Sergey Bylokhov wrote:
>> From a build perspective this partially reverts
>> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
>> the harfbuzz sources separate and still supports building and running
>> against a system harfbuzz which is
On Mon, 15 Mar 2021 11:41:07 GMT, Alan Bateman wrote:
>> Done
>
>> Done
>
> I think I'd prefer if the exception message would say that the JMOD is
> invalid or that the JMOD file is truncated (because I don't think anyone
> seeing this exception will know anything about the header).
Fixed
> In some cases wrapping of `InputStream` with `BufferedInputStream` is
> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
> not require any buffer having one within.
>
> Other cases are related to reading either a byte or short `byte[]`: in both
> cases
On Sun, 14 Mar 2021 19:32:11 GMT, Сергей Цыпанов
wrote:
> Done
I think I'd prefer if the exception message would say that the JMOD is invalid
or that the JMOD file is truncated (because I don't think anyone seeing this
exception will know anything about the header).
-
PR:
On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race wrote:
> From a build perspective this partially reverts
> https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
> the harfbuzz sources separate and still supports building and running against
> a system harfbuzz which is only of
This is the implementation used by JetBrains Runtime for the last 4 years,
after some cleanup, and with one problem,
found while preparing the pull request, fixed.
Even though typical scenarios for a UI application should be covered, it's not
a complete solution. In particular, emoji-s
still
On Sun, 14 Mar 2021 22:48:18 GMT, Sergey Bylokhov wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use InputStream.readNBytes() and fix JLinkNegativeTest
>
>
> In some cases wrapping of `InputStream` with `BufferedInputStream` is
> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
> not require any buffer having one within.
>
> Other cases are related to reading either a byte or short `byte[]`: in both
> cases
On Fri, 12 Mar 2021 00:36:34 GMT, Sergey Bylokhov wrote:
>> I fixed some conversion logic within JDK-8256331.
>
> OK, just to confirm. I wrote that text for OGL because it was the fastest way
> to transfer+convert the data from the video card to the memory. And as far as
> I understand the
On Fri, 12 Mar 2021 07:19:06 GMT, Aleksey Shipilev wrote:
> Ok, I removed the "DCL" from that code and used the objects directly. AFAICS,
> synchronization is redundant on those local objects. What would be a good
> test for this change?
I guess that synchronization became redundant because
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote:
> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering
> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple
> Metal API.
>
On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal
31 matches
Mail list logo
