On Thu, 25 Jan 2024 17:16:51 GMT, Laurent Bourgès wrote:
>> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
>
> Laurent Bourgès has updated the pull request incrementally with one
> additional commit since the last revision:
>
> fixed test package
I fixed new test so syst
Thanks, it seems I misunderstood something fundamental here.
I always figured the memory effects are limited to the variables
accessed/mutated within a synchronized block (or *could* be limited to
just those by selectively flushing data by some advanced VM).
Apparently that's not the case, an
On Thu, 25 Jan 2024 23:44:06 GMT, Andy Goryachev wrote:
>>> Regarding other whitespace characters. Using \u2003 em space, pasting the
>>> following text
>>
>> I think we can use `Character.isWhitespace`. For the most part it aligns
>> with "is this a breaking space". It's not perfect, but we
> There are a number of tickets open related to text rendering:
>
> https://bugs.openjdk.org/browse/JDK-8314215
>
> https://bugs.openjdk.org/browse/JDK-8145496
>
> https://bugs.openjdk.org/browse/JDK-8129014
>
> They have in common that wrapped text is taking the trailing spaces on each
> wrap
> There are a number of tickets open related to text rendering:
>
> https://bugs.openjdk.org/browse/JDK-8314215
>
> https://bugs.openjdk.org/browse/JDK-8145496
>
> https://bugs.openjdk.org/browse/JDK-8129014
>
> They have in common that wrapped text is taking the trailing spaces on each
> wrap
On Thu, 25 Jan 2024 23:23:42 GMT, John Hendrikx wrote:
>> Regarding other whitespace characters.
>> Using \u2003 em space, pasting the following text
>>
>> AAABBBCCC
>>
>>
>> the results as seen with MS Word 16.78 (23100802) on macOS 14.2.1 indicate
>> that it treats em space as w
On Thu, 25 Jan 2024 16:18:37 GMT, Andy Goryachev wrote:
> Regarding other whitespace characters. Using \u2003 em space, pasting the
> following text
I think we can use `Character.isWhitespace`. For the most part it aligns with
"is this a breaking space". It's not perfect, but we can do more w
On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx wrote:
> There are a number of tickets open related to text rendering:
>
> https://bugs.openjdk.org/browse/JDK-8314215
>
> https://bugs.openjdk.org/browse/JDK-8145496
>
> https://bugs.openjdk.org/browse/JDK-8129014
>
> They have in common that w
On Tue, 23 Jan 2024 03:13:11 GMT, Alexander Matveev
wrote:
> This is regression from JDK-8262365. JDK-8262365 introduced support for
> hardware pause for audio device. For some reason we will skip ~500 ms of
> audio data after such pause. It is not noticeable for large audio files, but
> for
On Wed, 17 Jan 2024 17:10:24 GMT, Thiago Milczarek Sayao
wrote:
>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>>
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative
>> positioning on `InputMethodRequest`.
>>
On Wed, 17 Jan 2024 17:13:11 GMT, Thiago Milczarek Sayao
wrote:
>> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line
>> 163:
>>
>>> 161: g_signal_connect(im_ctx.ctx, "preedit-changed",
>>> G_CALLBACK(on_preedit_changed), this);
>>> 162: g_signal_conne
If you mean the changes proposed in Draft PR
https://github.com/openjdk/jfx/pull/1349 those are too-intrusive for
where we are in JavaFX 22. I see no chance that we will get agreement on
the approach and be able to finish the code review and CSR in the next 4
business days.
If we later get ge
Hi Kevin,
have you considered my proposal, which is basically the same approach:
it uses runLater internally to dispatch the interaction with
AbstractPrimaryTimer (instead of trying to make AbstractPrimaryTimer
work under concurrent access).
But from the point of view of the caller, the API works
Hi John, the threading restrictions are now removed.
What I mean by those seemingly contradictory stratements is the following:
This change doesn't make Animation inherently thread-safe, so if you
configure the animation on thread A, you can't just call play() on
thread B and expect it to work.
Wh
> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
Laurent Bourgès has updated the pull request incrementally with one additional
commit since the last revision:
fixed test package
-
Changes:
- all: https://git.openjdk.org/jfx/pull/1348/files
- new: https:/
On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx wrote:
> There are a number of tickets open related to text rendering:
>
> https://bugs.openjdk.org/browse/JDK-8314215
>
> https://bugs.openjdk.org/browse/JDK-8145496
>
> https://bugs.openjdk.org/browse/JDK-8129014
>
> They have in common that w
On Thu, 25 Jan 2024 13:32:21 GMT, Hima Bindu Meda wrote:
> Cherry-picked changes related to webkit-2.42.4.Verified build on all
> platforms. Sanity testing looks fine.
Code changes look fine with one suggestion in the added code under `#if
PLATFOMR(JAVA)`.
I'll test it and finish my review.
On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx wrote:
> There are a number of tickets open related to text rendering:
>
> https://bugs.openjdk.org/browse/JDK-8314215
>
> https://bugs.openjdk.org/browse/JDK-8145496
>
> https://bugs.openjdk.org/browse/JDK-8129014
>
> They have in common that w
Yes, I think you are missing something. Unless you have an animation
that just decides all on it's own to find and attach a newly discovered
node to the scene and start rendering it, there will be a
synchronization as a result of calling runLater. Consider the following
code:
Label label
And that's why the "be careful" option is not a satisfying solution.
Let's proceed with the option to change the implementation of
play/pause/stop/start to do the work in a runLater, and change the docs
accordingly. It's the only feasible option for JavaFX 22 (other than "do
nothing"), and I a
>
> Option 3 is basically document it as "be careful" and remove the thread
> restriction recently introduced, am I correct?
>
Yes :)
IMHO that can simply can't work at all, because this is what
> (theoretically) can happen:
> 1. Non-FX thread starts animation
> - Fields are manipulated in A
Cherry-picked changes related to webkit-2.42.4.Verified build on all platforms.
Sanity testing looks fine.
-
Commit messages:
- Resolve compilation error
- Cherrypick changes related to 2.42.4
Changes: https://git.openjdk.org/jfx/pull/1350/files
Webrev: https://webrevs.openjdk.or
Isn't that exactly what the Worker interface and its Task and Service
implementations are for? Service says
A Service is a non-visual component encapsulating the information required
> to perform some work on one or more background threads. As part of the
> JavaFX UI library, the Service knows abo
On Mon, 22 Jan 2024 13:45:35 GMT, Ambarish Rapte wrote:
> JDK 21.0.2 is now released : https://jdk.java.net/21/
> Did a full CI build including Webkit and executed all headful tests.
This pull request has now been integrated.
Changeset: 9e7e8e1d
Author:Ambarish Rapte
URL:
https://gi
All this threading talk has made me wonder something:
Let's say there are two threads, the FX thread and Thread 1. I do the
following:
- On thread 1: create Label
- On thread 1: set Label text to "xyz"
I now attach this label to an active Scene graph. This should be done on
the FX thread as
Hi Michael,
I'm not quite sure I see the point of this change. The PR did not
remove the threading restrictions on play/stop.
I'm also confused by the seemingly contradictory statements:
- this proposal does NOT allow Animation.play/stop/etc. to be "called on
any thread"
- It merely removes
On 24/01/2024 22:06, Nir Lisker wrote:
This is the ballpark of what I meant with "the downside might be some
surprise when these methods behave differently".
That can be documented, and basically already is (because that is what
the "asynchronous" is alluding to, the fact that after calling "pl
27 matches
Mail list logo
