On Wed, 10 Nov 2021 05:35:12 GMT, Alexander Zuev wrote:
>> I was able to reproduce this issue locally 2 times out of 100 runs on
>> multi-monitor
>> configuration. Both times due to the screen resolution change is so slow
>> window got
>> accidentally moved to the secondary screen by the displa
On Mon, 15 Nov 2021 02:51:33 GMT, Phil Race wrote:
> We have issues running in debug mode even in headful mode -
> https://bugs.openjdk.java.net/browse/JDK-8264773 I think this PR should be
> withdrawn. We need a holistic look at making sure we run properly in debug
> builds on windows when we
On Tue, 16 Nov 2021 08:20:52 GMT, Matthias Baesken wrote:
> > We have issues running in debug mode even in headful mode -
> > https://bugs.openjdk.java.net/browse/JDK-8264773 I think this PR should be
> > withdrawn. We need a holistic look at making sure we run properly in debug
> > builds on
On Tue, 16 Nov 2021 04:46:07 GMT, Jeremy wrote:
>> This removes code that relied on consulting the Bezier control points to
>> calculate the Rectangle2D bounding box. Instead it's pretty straight-forward
>> to convert the Bezier control points into the x & y parametric equations. At
>> their m
On Fri, 12 Nov 2021 07:57:57 GMT, Matthias Baesken wrote:
>> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced
>> with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni to an
>> awt related test, and shows on Windows server 2019 the following JNI warning
On Tue, 26 Oct 2021 04:52:37 GMT, Sergey Bylokhov wrote:
>> Masanori Yano 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
>> com
BigInteger currently uses three different algorithms for multiply. The simple
quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
count and then Toom Cook 3 once we go into the several thousands of bits. Since
Toom Cook 3 is a recursive algorithm, it is trivial to parallel
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
On Tue, 16 Nov 2021 05:22:13 GMT, Jeremy wrote:
>> src/java.desktop/share/classes/java/awt/geom/Path2D.java line 2124:
>>
>>> 2122: // a box that is slightly too small. But the contract of this
>>> method
>>> 2123: // says we should err on the side of being too large.
>>> 2124:
On Tue, 16 Nov 2021 04:46:07 GMT, Jeremy wrote:
>> This removes code that relied on consulting the Bezier control points to
>> calculate the Rectangle2D bounding box. Instead it's pretty straight-forward
>> to convert the Bezier control points into the x & y parametric equations. At
>> their m
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom Cook 3 is a recursive algorithm, it is trivial to
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
On Mon, 15 Nov 2021 15:50:39 GMT, kabutz wrote:
> BigInteger currently uses three different algorithms for multiply. The simple
> quadratic algorithm, then the slightly better Karatsuba if we exceed a bit
> count and then Toom Cook 3 once we go into the several thousands of bits.
> Since Toom
On Thu, 11 Nov 2021 05:52:18 GMT, Jayathirth D V wrote:
> When JDK is built on BigSur with Xcode12.5 and used to run jtreg tests in
> macOS10.15 with Xcode <=12.4 we are getting compilation error. We dont set
> any deployment target when when we use xcrun to create .air file and this
> issue l
On Tue, 16 Nov 2021 12:48:03 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
> I was able to reproduce this issue locally 2 times out of 100 runs on
> multi-monitor
> configuration. Both times due to the screen resolution change is so slow
> window got
> accidentally moved to the secondary screen by the display driver.
> Can not reproduce this bug with ATI card at all.
>
On Mon, 1 Nov 2021 11:35:24 GMT, Alexander Zuev wrote:
> I was able to reproduce this issue locally 2 times out of 100 runs on
> multi-monitor
> configuration. Both times due to the screen resolution change is so slow
> window got
> accidentally moved to the secondary screen by the display driv
On Mon, 15 Nov 2021 17:33:09 GMT, Alisen Chung wrote:
>> Adjusted the AquaLF scrollbar to account for border inset settings when
>> dragging the thumb and clicking on the track.
>
> Alisen Chung has updated the pull request incrementally with two additional
> commits since the last revision:
>
Added implementation for all menu related protocol peers;
Native methods moved to CommonComponentAccessibility so they are called on
correct peers;
-
Commit messages:
- 8264293: Create implementation for NSAccessibilityMenu protocol peer
Changes: https://git.openjdk.java.net/jdk/pu
On Tue, 16 Nov 2021 23:53:53 GMT, Alexander Zuev wrote:
> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on
> correct peers;
@pankaj-bansal please review
@forantar please review
-
PR: https://git
Before the new JList accessibility peer implementation sending popup closed
event to the combobox popup could trigger the native memory access error due
to the events arriving in the wrong order. After new implementation is done
it is no longer the case and this workaround needs to be removed.
---
On Tue, 16 Nov 2021 07:53:46 GMT, Sergey Bylokhov wrote:
> > Please correct my understanding. Does this refined repaint logic apply even
> > for overlapping Windows? What happens when 2 windows are overlapping and we
> > move top window slowly? Any performance/power impact?
>
> Initially, this
On Wed, 10 Nov 2021 18:45:12 GMT, Sergey Bylokhov wrote:
> The bug occurs more often if initially the window is moved partly outside of
> the first screen(let's name this part as the invisible part), and then slowly
> moved to the second screen where that invisible part became visible on the
>
On Fri, 29 Oct 2021 06:43:38 GMT, Prasanta Sadhukhan
wrote:
>> As per JDK-8252813, some tests fails recurringly in CI macos system. This is
>> an attempt to fix the swing tests.
>> It was seen from the logs that we have color mismatch in these tests.
>>
>> For example, in PressedIcon test, we
On Tue, 16 Nov 2021 23:53:53 GMT, Alexander Zuev wrote:
> Added implementation for all menu related protocol peers;
> Native methods moved to CommonComponentAccessibility so they are called on
> correct peers;
Looks good to me. Menu Accessibility works fine with these changes.
-
M
30 matches
Mail list logo
