#Pressing start in my GUI causes short lag

1 messages · Page 1 of 1 (latest)

desert scarab
radiant vaultBOT
#

<@&987246487241105418> please have a look, thanks.

desert scarab
#

im pasting the code in pastebin. one sec

#

I think it's because the GUI thread is starting the process, so it freezes untill the process is started. But I might be wrong, any thoughts?

quartz blaze
desert scarab
#

It was resolved when I used another thread

cedar anchor
#

most GUI frameworks are single-threaded, due to a plethora of problems that come with multi-threaded UI

#

Swing has the Event Dispatch Thread, JavaFX has the FX Application Thread

#

and all UI changes are expected to occur on the UI thread

#

if you put long-running code on the UI thread, that'll cause UI events to be halted until that long-running code finishes

#

which results in your UI freezing

#

the moment you take that long-running code off the UI thread, it wont freeze anymore

desert scarab
#

Yeah I try to stay away from threads. But as long as it’s just the thread starting the process and then ending it can’t do much harm right

#

One the process is started it can run on its own

cedar anchor
#

i mean, the UI thread will always be at play, unless you explicitly use active rendering

#

its what handles render requests, event handler actions, etc..

#

when you click a button, that action gets handled on the UI thread

#

so if you have an ActionListener that tries to read a large file, its going to freeze the UI

desert scarab
#

Yeah I now just have a GUI thread that does only GUI stuff. As soon as start is clicked, another thread starts that process so that the UI can do its own thing.

#

Is that best practise or? Should I do it differently

cedar anchor
#

thats good, yes. but you gotta maintain that idea through-out your program

#

nah, that makes sense. introduce a new thread to handle the task. this is where worker threads come in

#

and where types like SwingWorker play a role

desert scarab
#

So UI sticks to doing UI things so it maintains responsive, and long tasks is for different threads.. as long its safe threading

cedar anchor
#

yup

#

thats why SwingWorker exists

#

Task for FX

desert scarab
#

Ill check that out, not sure what that means. I do know what a thread is

cedar anchor
#

a worker thread is a re-usable thread

desert scarab
#

And task async I know from c#

cedar anchor
#

so you arent constantly spawning new threads for tasks

desert scarab
#

Is it like the threadpool stuff I read about?

cedar anchor
#

yup, exactly

#

you can achieve worker threads regardless of UI

desert scarab
#

I should learn that

cedar anchor
#

with Executors

#

theres Executors.newCachedThreadPool() and what not

#

a thread pool is what allows threads to be reused

#

similar to connection pools with database operations

#

instead of spawning new threads, use a thread that exists in the pool

#

thats the idea of pools. in java, you may hear of "string pool"

#

its a way to re-use strings

desert scarab
#

Okay that makes sense

#

I just have to make sure when using them, they do not access the same data at once right?

cedar anchor
#

you gotta make sure access to the same data is thread-safe, through synchronization tools

#

thats where things get a bit more complex

#

two threads can share the same data if that data is immutable, never changes

#

but if the data may change, you need to ensure the changes are synchronized

#

thats a whole topic of concurrency and multi-threading

desert scarab
#

Aha yeah that makes sense, so you have to think it through

cedar anchor
#

yup

#

thats why multithreading is one of the more advanced topics

desert scarab
#

But for just starting a process it’s pretty straight forward. I also use a thread to log from the external process to my UI

#

But its really useful if well executed

#

So always good to try and learn

cedar anchor
#

when using active rendering, ignoring the UI's rendering system, sure, you dont need to worry about the UI thread after launching

desert scarab
#

It start the jar file, and then the process runs on its own. It’s like a 3 sec task

#

The process = the jar file

cedar anchor
#

but will the user interact with components that trigger event lieteners?

desert scarab
#

No, it does not need any interaction. I only need to send a stop signal to that process later on, which I have not figured out how to do yet. I can just kill the process, but that’s not safe for the process. I start the process through my UI , and when i stop it through my UI, it should send a signal to finish it’s current iteration and then it should stop. So still figuring that out.

#

Might be a bit confusing lol

cedar anchor
#

yeah

#

all i can say is try it

#

get a code review after

#

people can help point out any multi-threading inconsistencies

#

UI thread is usually very good or very evil

#

good in that it teaching people threading. bad that it can halt a project for those who dont know threading

#

so unless you wanna dive into the semantics of multi-threading & UI threads, your better option would be to test it yourself, see if theres any problems, then get it reviewed

desert scarab
#

So i press start in my gui and the thread starts the jar (process). The process does something every 30 sec, lets call it a iteration. Currently when I press stop in my gui it kills the process instantly with process.kill() or something which instantly kills it mid iteration. But instead when I press stop in my gui, it should send a signal to the process to finish it’s current iteration and then stop after that

#

But it shouldn’t be too complicated really

cedar anchor
#

so you are relying on event listeners

#

you are pressing a button, which fires an ActionListener

desert scarab
#

I wasn’t but I guess I do have to use it

#

I’m not familiar with the nameconventions yet

#

But yeah I guess I am using event listeners

cedar anchor
#

you can use SwingUtilities.isEventDispatchThread() to see if your code runs on the UI thread or not

desert scarab
cedar anchor
#

thatll give you some insight into whether the UI thread is at play

desert scarab
#

I’ll try that

cedar anchor
#

if it prints true, youre on the UI thread

desert scarab
#

I’ll just trial and error it and get there eventually