We have developed Swing-JavaFx Integrated application for multimedia content like Image & Animations. Base Container for application is Swing JFrame. Inside, for Image we are using JFXPanel. But after continuous run of say ~12hrs and log analysis, we have observed that Task submitted to Platform.runlater is never getting executed.
PS: Platform.setImplicitExit(false) is done.
Duration of occurence is not fixed, but usually after 6hrs.
Implementation is changing images repeatedly after a defined duration.
Related
At one point in my application, I have to save a JavaFX UI which takes a long time. During this save, I have to show a Progress Dialog telling the user what is happening at that time.
I have read that heavy tasks should be ran using a Task and not the JavaFX thread. However, this is not possible for me for the 2 following reasons:
1- The heavy tasks include JavaFX confirmation dialog popups which are sometimes buggy on MAC if not called by the JavaFX thread.
2- The save method must return a boolean to tell if the save went ok or not. And this save method is triggered by the JavaFX thread. Meaning the JavaFX thread must return the boolean variable and has to wait for the Task to finish before doing that.
And sadly the JavaFX UI is integrated in a Swing UI which makes it more difficult to work with.
Task is just one implementation of the javafx.concurrent.Worker interface, which provides facilities to communicate with the GUI respectively the JavaFX thread. Other implementations are Service and ScheduledService. Basically, the difference is that Service is designed for reuse, whereas Task isn't, and ScheduledService can restart itself after execution.
So, to address your two concerns:
The heavy tasks include JavaFX confirmation dialog popups which are sometimes buggy on MAC if not called by the JavaFX thread.
As mentioned before, the Worker interface provides a nice API to update the GUI from another thread. For instance, from the JavaFX thread, you can easily bind a Labeled to the message property which gets updated from the background thread.
The save method must return a boolean to tell if the save went ok or not. And this save method is triggered by the JavaFX thread. Meaning the JavaFX thread must return the boolean variable and has to wait for the Task to finish before doing that.
For example, Task's call() method can return arbitrary objects, which includes Boolean. Moreover, the Worker interface has a getValue() method to retrieve the result from the corresponding worker.
I recommend reading the "Concurrency in JavaFX" tutorial for further information. For ProgressBar itself, have a look at the "Progress Bar and Progress Indicator" tutorial.
We have a WinForms c++/cli CAD based application that uses VTK 6.1. One of the application's features is playing a script which plays back operations the user had previously done interactively. We pop a modal progress form while the script is playing and do the non-ui work of the script in a background thread. Part of the work of the background thread is creating and deleting vtkPolyDataMappers. While the background thread is going and the progress form is showing we need to update a display in the main thread by calling vtkWin32RenderWindowInteractor::Render().
We have a timer setup so Render is called every few hundred milliseconds at most in a UserControl::OnPaint event handler. This allows the view to update while the script is playing giving the user feedback.
This used to work in VTK 5. But now an infinite loop happens upon deletion of a vtkPolyDataMapper in the background thread. The infinite loop is in vtkClearOpenGLErrors:
void vtkClearOpenGLErrors()
{
while (glGetError()!=GL_NO_ERROR){;}
}
Inside the vtkpolydatamapper is a vtkOpenGLDisplayListPainter. When this gets deleted by vtkGarbageCollectorImpl::CollectInternal we get stuck in vtkClearOpenGLErrors.
Does anyone have experience with VTK and threading that could help? Do you know anything about this? It's only an apparent problem in VTK 6.1. Is it illegal to have the main UI thread calling Render on a vtkWin32RenderWindowInteractor while a background thread is doing deletes on a vtkPolyDataMapper? It isn't a timing issue. I think it might be an OpenGL context issue but not sure how to fix it. The problem does go away if we avoid calling Render on the display while the background thread is going but we'd like to give the user feedback while the script is playing.
We fixed the problem by recompiling VTK with
VTK_REPORT_OPENGL_ERRORS
turned off.
I am using LibGDX to make a game. I want to simultaneously load/unload assets on the fly as needed. However, waiting for assets to load in the main thread causes lag. In order to remedy this, I've created a background thread that monitors which assets need to be loaded (textures, sounds, etc.) and loads/unloads them appropriately.
Unfortunately, I get the following error when calling AssetManager.update() from that thread.
com.badlogic.gdx.utils.GdxRuntimeException: java.lang.RuntimeException: No OpenGL context found in the current thread.
I've tried runing the background thread in the main thread in the beginning and just dealing with the first few screens, and everything works fine. I can also change the algorithm to just load everything into memory from the start in the same thread, and that works as well. However, neither works in the background thread.
When I run this on Android with OpenGL ES 2.0 (which is flexible in odd ways) instead of on Windows, everything runs fine, and I can even get the pixel dimensions of the images - but the textures render black.
My searches have told me that this is an issue of the OpenGL context being bound to a single thread, but not much else. This explains why everything works when I shove it in the main thread, and not when I put it in a different one. How do I fix this context problem?
First things first, you should not access the OpenGL context outside of the rendering thread.
I assume you have looked at these already, but just to make sure read up on the AssetManager wiki article, which talks a bit about how to use the AssetManager for asynchronous managing of assets. In addition to the wiki article, check out the AssetManagerTest to better understand how to use it. The asset manager test is probably your best bet into loading at how to dynamically load assets.
If you are loading a ton of stuff, you may want to look into creating a loading bar to load anything large upfront. It might work to check assets and such from another thread (and set a flag to call update), but at the end of the day you will need to call update() on the rendering thread.
Keeping in mind you have to call update() it from a different thread, I don't see why you would want another thread to check conditions and set a flag. There is probably more overhead using another thread and synchronizing the update() call than to just do it all on the rendering thread. Also, the update() method only pauses for a couple milliseconds at a time as it incrementally loads files. Typically, you would simply call load() for your asset, then check isLoaded() on your asset. If it isn't loaded you would then call update() once per frame until isLoaded() returns true. Once it returns true, you can then call get() and get whatever asset you were loading. This can all be done via the main rendering thread without having the app lag while its loading.
If you really want your other thread to call update(), you need to create a Runnable object and call postRunnable() such as how they have it described in the wiki article on multi-threading with libGDX. However, this defeats the whole point of using other threads because anything you use with postRunnable runs synchronously on the rendering thread.
I'm a complete noob with JavaFX 2 - (started this morning with a HelloWorld that I'm adapting).
I need to update a Text node with the result of a background thread. Is there anything special I need to be aware of with JavaFX2 or is it simply enough to submit a callable and update the text. A pointer to a tutorial would be appreciated.
After calculating the results, running the
Platform.runLater(new Runnable() {
#Override
public void run() {
// Update the text node with calculated results
}
});
at the end of the same background thread is enough in normal situations. This link also maybe helpful:
Execute task in background in JavaFX.
Platform.runLater() will run later on the JavaFX application thread - which is fine if the executed content is a quick running task (e.g. inexpensive computation without I/O or just a call to update the UI). Use a Timeline for animation or timer based things. Otherwise a Task or Service based solution, for which there is a tutorial. Don't ever read or write from objects involved in an active scenegraph (even updates triggered by binds) off of the JavaFX application thread. Some further discussion and examples are in this forum thread.
My UI is using QTreeView with QFileSystemModel to be able to select folders and files. The documentation for QFileSystemModel says that file structure update is done on a seperate thread which would mean the UI would not be blocked. However, this is not the case for me and I can't figure out the discreptency and how other people are not running into this issue. After debugging, I noticed that QFileSystemModel _q_fileSystemChanged slot which takes most of the time is still executed on the main UI thread which makes sense. The Questiong is how does the documentation claim than that it will not block the UI. Is there a solution? Am I misunderstanding something?
To repro
- Create a QTreeView with QFileSystemDataModel
- Set root path to "" or "/"
- Set breakpoint in QFileSystemModel _q_fileSystemChanged slot
- Expand one of the drives after app loads
Problem:
- The slot is called on the UI thread thus blocking the app until it finishes.
There are ways to make the file parser faster, but it I really need to execute on a seperate thread and notify when the data is populated and ready for QTreeView.
Thanks,
Innokenty
I think the reason for this could be the icons. Within the _q_fileSystemChanged() slot fileInfoGatherer.getInfo() gets called which - among other things - resolves the icons for the paths. In it's current design QFileIconProvider uses QIcon to represent icons and QIcon can only be used in the UI thread. QImage seems to be the only class allowed to use in other threads, but I think it may be to expensive to use QImage in the background thread and convert it to an QIcon in the UI thread.
So it is possible that the platform implementation of QFileIconProvider is slow on network paths under some circumstances and therefore slows down the UI main thread.
I don't know if this is the source of your problem, but at least this should be the reason why _q_fileSystemChanged() is called within the UI thread.