On Fri, 23 May 2025 11:38:32 GMT, Jayathirth D V wrote:
>> In stress based scenarios it is observed that nothing is drawn in UI content
>> when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i
>> am not able to reproduce it, but based on details in the bug it looks like
On Wed, 21 May 2025 06:11:18 GMT, Jayathirth D V wrote:
> In stress based scenarios it is observed that nothing is drawn in UI content
> when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i
> am not able to reproduce it, but based on details in the bug it looks like we
On Fri, 23 May 2025 11:38:32 GMT, Jayathirth D V wrote:
>> In stress based scenarios it is observed that nothing is drawn in UI content
>> when display wakes up from sleep in Metal pipeline of macOS. Unfortunately i
>> am not able to reproduce it, but based on details in the bug it looks like
> I do not have much background in LZW compression or in C, but I'm reasonably
> confident this resolves the problem I'm observing. It looks like the
> GifImageDecoder was not always correctly handling compression codes after the
> table reached its limit of ~4096. If anyone has suggestions for
> If there are two consecutive frames that use DISPOSAL_SAVE, but the
> transparent pixel index changed: we might accidentally send the wrong data to
> the ImageConsumer.
>
> We already had logic that submits info "the hard way" (see comment in code);
> this PR just makes sure we trigger that b
> If there are two consecutive frames that use DISPOSAL_SAVE, but the
> transparent pixel index changed: we might accidentally send the wrong data to
> the ImageConsumer.
>
> We already had logic that submits info "the hard way" (see comment in code);
> this PR just makes sure we trigger that b
> This resolves a gif parsing bug where an unwanted opaque rectangle could
> appear under these conditions:
>
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka
> "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
>
> P
> I do not have much background in LZW compression or in C, but I'm reasonably
> confident this resolves the problem I'm observing. It looks like the
> GifImageDecoder was not always correctly handling compression codes after the
> table reached its limit of ~4096. If anyone has suggestions for
> This resolves a gif parsing bug where an unwanted opaque rectangle could
> appear under these conditions:
>
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka
> "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
>
> P
On Sat, 24 May 2025 03:32:50 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Set orientation only if changed...add headful in test
>
> src/java.desktop/share/classes/javax/swing/JSplitPan
On Fri, 23 May 2025 20:59:41 GMT, Phil Race wrote:
>> Graphics copyArea overflow check bails out of copying pixels if there is
>> overflow.
>> The spec says ""If a portion of the source rectangle lies outside the bounds
>> of the component, or is obscured by another window or component, {@code
> A simple API to replace java.applet.AudioClip
>
> CSR is now created : https://bugs.openjdk.org/browse/JDK-8356200
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
8356049
-
Changes:
- all: https://git.openjdk.org/jdk/p
On Sun, 25 May 2025 04:56:14 GMT, Sergey Bylokhov wrote:
> possibly we can extend this by two group of methods `asyncPlay/play` and
> `asyncLoop/loop` to make it easy to use in a different situations?
There are probably going to be zero to a handful of apps anywhere that use this
API without a
On Thu, 22 May 2025 21:21:30 GMT, Sergey Bylokhov wrote:
> The issue was found here:
> https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>
> AWTEventListener and AWTEventListenerProxy are public classes and there's no
> assertion that EventListenerProxy.getListener() will always
The issue was found here:
https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
AWTEventListener and AWTEventListenerProxy are public classes and there's no
assertion that EventListenerProxy.getListener() will always return a non-null
value. So removeAWTEventListener method should fe
15 matches
Mail list logo
