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 is, again, asking for
trouble.
And how is TableView, Slider, TextField, etc all working just fine but
ComboBox freaks out? What's so special about ComboBox? Is there some
hack I can do to not trigger the exception?
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 Platform.runLater for example.
Doing all this is just messy, inefficient, and duplicating code. It
would involve creating Runnable implementations that does about 10 lines
of code with objects that get updated as fast as they can be with
different object types, resulting in more threads and garbage being
created. Using generic magic isn't really a solution either because
different API objects convert data from String to some other type
depending on the implementation.
Would it not be possible to have a runPlatformListener method that just
runs the ChangeListener on the platform thread automatically? It would
reduce the amount of garbage dramatically since JavaFX only ever fires a
change event if the object is itself different(in other words, if the
current value is 0 and the new value is 0, there is no change) which is
nice and efficient.
Also, take the attitude down a notch or two.
Brian
On Mon, Nov 12, 2018 at 10:02 PM Ty Young <youngty1...@gmail.com
<mailto:youngty1...@gmail.com>> 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 the value of a type stored in a property. The
ChangeListener that
is used is created in the GUI JavaFX 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 that you run on the
correct thread.
The update process for updating my API objects is slow(for reasons
beyond my control), so even assuming I somehow manage to magically
update everything in the GUI thread, how the hell do you fix the GUI
stuttering at that point?
Really, having an entire application do all of it's processing on one
thread in 2018 is really just idiotic and asking for trouble.
>
> Even though your TableView, ... updates seem to work you can run
into
> disasterous states - see eg
https://bugs.openjdk.java.net/browse/JDK-8198577
>
> Tom
I'm not sure what the bug is about since the description really
doesn't
give much info however I really haven't noticed anything, even
long term
with it being open for 8+ hours. These objects are update very
frequently as well.
To be clear, this isn't some business application that gets info
from a
database or something.
> On 10.11.18 06:58, 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, while JavaFX is OK with
this for
>> TableView, Slider, and TextField, it throws a Not on FX
application
>> thread exception *only* for the ComboBox.
>>
>>
>> The code for the slider looks like this:
>>
>> private class ValueListener implements
ChangeListener<Integer>
>> {
>> @Override
>> public void changed(ObservableValue<? extends Integer>
>> observable, Integer oldValue, Integer newValue)
>> {
>> slider.getSlider().setValue(newValue);
>> slider.getTextBox().setText(newValue.toString());
>> }
>> }
>>
>>
>> (the slider variable is misleading, it's actually a VBox that
contains a
>> Slider and a TextField. Need to change it but I digress.)
>>
>>
>> which works fine. However this:
>>
>>
>> private class ValueListener implements ChangeListener<E>
>> {
>> @Override
>> public void changed(ObservableValue<? extends E>
observable, E
>> oldValue, E newValue)
>> {
>> combo.setValue(newValue);
>> }
>> }
>>
>>
>> doesn't for the ComboBox.
>>
>>
>> Is this a bug or is there some legitimate invisible reason as
to why the
>> slider/textfield isn't throwing an error but the combobox one is?
>>
>>
>>
