On 13.11.18 04:00, Ty Young wrote:
>
> On 11/12/18 5:39 PM, Tom Schindl wrote:
>> Hi,
>>
>> You are supposed to interact with Nodes who are currently shown in the
>> SG only only the JavaFX Application Thread.
>
>
> I never touch the GUI in my other threads, ever. The threads simply
> change
I'm sorry that I'm the one to bring you the bad news that you need to do
the work and can't offload multi-threading to JavaFX.
I already explain why it *seems* to work one some elements (until it
breaks like shown in the bug-report I referenced) and for others it
breaks immediately because they
On 11/12/18 9:12 PM, Brian Hudson wrote:
JavaFX like every other modern UI framework is single threaded.
Which in itself is fine, running *just* the UI isn't much on modern
processors. Adding a bunch of API object updates that cause thread
slowdown to the mix that can cause UI stuttering
JavaFX like every other modern UI framework is single threaded.
The updating of your “API objects” can and should remain on a background
thread, however once updated the changes which trigger an update to your UI
(changing a value in a bound property) should occur on the JavaFX thread
via
On 11/12/18 5:39 PM, Tom Schindl wrote:
Hi,
You are supposed to interact with Nodes who are currently shown in the
SG only only the JavaFX Application Thread.
I never touch the GUI in my other threads, ever. The threads simply
change the value of a type stored in a property. The
Hi,
You are supposed to interact with Nodes who are currently shown in the
SG only only the JavaFX Application Thread.
JavaFX although is not checking each and every property (change) as this
would be too resource intensive but at sensitive cases (eg when
interacting with Glass) it does check
On 11/9/18 11:58 PM, Ty Young wrote:
Hi,
My JavaFX program updates API objects in the background via a non FX
thread that, when changed by another program, are reflected in my
JavaFX GUI's controls by property binding, specifically TableView,
Slider, TextField, and ComboBox. Problem is,
Hi,
I never used the relative version but can confirm that you have to set
the library path to the built DLLs
Tom
On 12.11.18 11:41, Nir Lisker wrote:
> I managed to solve my problem. It's actually looking for the dlls, so using
>
>
I managed to solve my problem. It's actually looking for the dlls, so using
-Djava.library.path="...\rt\modules\javafx.graphics\build\module-lib"
will start the application properly. If anyone can confirm this problem and
solution I'll add this step to the wiki.
On Wed, Nov 7, 2018 at 6:21 PM
