On Wed, 5 Apr 2023 21:36:57 GMT, Glavo wrote:
>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 77:
>>
>>> 75: */
>>> 76: @ForceInline
>>> 77: public static boolean isARM() {
>>
>> It should define what’s the difference to aarch64 for example will aarch64
>>
On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Wed, 5 Apr 2023 21:18:43 GMT, Glavo wrote:
>> There should be no difference; I was hesitant to drop the ADDRESS_SIZE check
>> without knowing more about the foreign api dependencies. ADDRESS_SIZE is
>> computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
>> But I can't think of how it can be
On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Wed, 5 Apr 2023 20:28:17 GMT, Bernd wrote:
> It should define what’s the difference to aarch64 for example will aarch64
> also be arm, but arm32 wont? (Or remove)
I think x86 and ARM are a bit confusing in this regard, as they can refer to
32-bit architectures in a narrow sense and 32-bit
On Wed, 5 Apr 2023 20:40:32 GMT, Roger Riggs wrote:
>> src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48:
>>
>>> 46: // might be running in a 32-bit VM on a 64-bit platform.
>>> 47: // addressSize will be correctly 32
>>> 48: if (Architecture.isX64() &&
On Wed, 5 Apr 2023 20:31:43 GMT, Bernd wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> test/jdk/jdk/internal/util/ArchTest.java line 58:
>
>> 56:
On Wed, 5 Apr 2023 20:25:43 GMT, Bernd wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct spelling of isAARCH64 in WIndows AttachProviderImpl
>
> src/java.base/share/classes/jdk/internal/foreign/CABI.java line
On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
> Define an internal jdk.internal.util.Architecture enumeration and static
> methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X,
> PPC64LE`
> Note
On Wed, 5 Apr 2023 04:44:14 GMT, Tejesh R wrote:
> > Tested changes and confirmed it works as expected. I noticed the focus
> > still shows for Metal & Motif. Should Metal be updated to reflect the same
> > change?
>
> Yeah, it's because the fix is Windows OS specific (Changes applied in
> Define an internal jdk.internal.util.Architecture enumeration and static
> methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X,
> PPC64LE`
> Note
On Wed, 5 Apr 2023 18:53:12 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
> Define an internal jdk.internal.util.Architecture enumeration and static
> methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X,
> PPC64LE`
> Note
On Wed, 5 Apr 2023 17:15:13 GMT, Roger Riggs wrote:
> Yes, the capitalization names should be disciplined. In the enum, there are
> all uppercase, following the style of manifest constants and enums. In the
> build they are always lower case. Camel case is usually used for method
> names.
Please review a docs-only change to add `@spec` tags into `java.desktop` public
API files
-
Commit messages:
- JDK-8305593: Add @spec tags in java.desktop
Changes: https://git.openjdk.org/jdk/pull/13360/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=13360=00
Issue:
On Wed, 5 Apr 2023 16:23:08 GMT, Glavo wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X86,
`data` array has size of `MAX_BUFFER` like `wname`, but it has a char type, so
its size is twice smaller than actual path limit, because paths returned by
`RegEnumValueW` use wide chars. We need to double this limit.
-
Commit messages:
- 8305667: Some fonts installed in user
On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs wrote:
> Define an internal jdk.internal.util.Architecture enumeration and static
> methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86,
On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs wrote:
> Define an internal jdk.internal.util.Architecture enumeration and static
> methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86,
Define an internal jdk.internal.util.Architecture enumeration and static
methods to replace uses of the system property `os.arch`.
The enumeration values are defined to match those used in the build.
The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE`
Note that `amd64`
There are freezes reported on some Linux configurations which are believed to
may be caused by the toolkit thread quickly reacquiring AWT_LOCK while polling
for events, which starves EDT waiting on that lock.
Adding new `awt.lock.fair` system property can help diagnosing such issues.
On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev wrote:
> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly
> frequent operations. When working over the network (remote X session), those
> can take several *seconds* to complete, introducing repeated freezes even
> when
> It was implemented in JetBrains Runtime a year ago and was ported &
> refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or
> bilinear-mipmap style algorithms depending on the text antialiasing
On Wed, 1 Feb 2023 16:10:51 GMT, Nikita Gubarkov wrote:
>> It was implemented in JetBrains Runtime a year ago and was ported &
>> refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or
>>
> It was implemented in JetBrains Runtime a year ago and was ported &
> refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or
> bilinear-mipmap style algorithms depending on the text antialiasing
This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
`java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a
heuristic to determine whether the question it's answering is "simple" or not.
The bug described in 8304350 only occurs in the simple=true
On Wed, 1 Feb 2023 16:17:02 GMT, Nikita Gubarkov wrote:
> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows
> and breaks maximization logic, so reshape window only if it's not maximized.
This pull request has now been integrated.
Changeset: f69d88c5
Author:
> This testcase Checking whether the Component becoming the Focus Owner and
> FocusEvent.FOCUS_GAINED will be received by the Component when the focus is
> requested on the component using requestFocus.
>
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got
On Wed, 5 Apr 2023 09:06:18 GMT, Sergey Bylokhov wrote:
> What exact operation is slow?
`X11GraphicsDevice.pGetBounds()`; I didn't measure further down.
-
PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1497180738
On Tue, 4 Apr 2023 21:56:12 GMT, Sergey Bylokhov wrote:
> I don't see why we need this in mainline. I'd prefer to not have it unless we
> need it.
I believe it is better to have all JDK branches in sync if it's possible.
This change is harmless and as Sergey mentioned it would simplify
On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev wrote:
> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly
> frequent operations. When working over the network (remote X session), those
> can take several *seconds* to complete, introducing repeated freezes even
> when
Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent
operations. When working over the network (remote X session), those can take
several *seconds* to complete, introducing repeated freezes even when typing in
an editor feels only slightly sluggish.
On the other
33 matches
Mail list logo