how can i achieve multithreading in adobe air desktop for Linux?
my UI is sometimes unresponsive because of heavy computations (client/server sockets, sql updates and inserts).
I want to have a thread processing these computation in the background and in Real-Time (UI should not be interrupted with modals/dialogs saying "loading")
can a native process helps this kind of situation? i was googling for hours and i found this so-called "green threads" but it doesn't help me...
does native process actually creates a new thread?
NOTE : this is for linux
sorry for my english..
In your case I would give a try to Workers http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/Worker.html
I would recommend that you use your main app for UI display and move all "heavy" work (webservice calls, parsers, utility classes) you have implemented so far in en external worker.
A nice tutorial you can find here http://gotoandlearn.com/play.php?id=162
Good luck
just look here https://code.google.com/p/async-threading/.
AsyncThreading is an actionscript library to facilitate threading in Flex and Air applications.It is very simple, just extends AbstractAsyncThread class and implements IAsyncThreadResponder interface, or implement a class extending the IAsyncThreadResponder interface, you can do what you need.
But be carefull when you send a message to another thread, I suggest you get instance of your class but not to receive a message from it.
Related
Hi I’m currently working on a project for a videocoacher program for recording and replaying video, as well as showing delayed real-time video, and tracking placement via color.
The software is running on linux , on a 4 core odroid, and initially I started to make it multi threaded with threads implemented as a part of each new class. Each of these threads taking care of their own gui elements.
I’ve later found out that I need to show all gui elements/video in the main/gui thread. Earlier I’ve used opencv and boost. But it seems like using the Qt might be a better idea since some of the code already depends on the QT library. I am currently a novice at programming, and not very familiar with either opencv, qt, or threading.
My question is:
Is this relatively sound as a structure for the program, or is there something inherently wrong with how I am planning to do it now?
Main/GUI Thread
will show all visual & video content
will start a thread for ButtonControl object
ButtonControl
will handle all button input, controlling what happens in the program
depending on what buttons are pressed will start and end threads
like:
StoreToFile object ( starts storing video to a file, while sending a
video stream to GUI thread to show what it is storing in real-time)
ReadFromFile object ( reads the file currently stored and sends data
to display it in GUI thread
DelayedVideoStream object (stores video to buffer, and shows a
continuous delayed view of what happened 5seconds in the past)
ColorTracking object (tracks where a color placement is in the image
)
Kind regards, and thank you for taking the time to look at my question.
TLDR - is a structure where threads are implemented as classes and the image data is sent back to the gui/main thread a decent way to do a multithreaded program ?
Performance-wise, the best approach is not to deal with threads directly at all, but use QtConcurrent::run. It is safe to paint QImages that are simply passed via signals to a GUI object to display. I wrote a complete example demonstrating that approach. It leads to some very concise and easy-to-understand code thanks to related code being adjacent.
If you do want to use explicit threads, it will be much easier not to derive from QThread, but to simply move various worker objects into their threads, and have them communicate via signals and slots. I have a complete example for that approach as well.
I am in need to load files, scenes and play animations in threads..
Tried loading files via www in Android...
how to do other stuff via threads?
But how come a game engine doesn't allow us to create threads?
or my understanding is wrong?
how can one create threads in UNITY3D?
You can use threads in Unity but the engine is not thread safe. Usually you run detached threads (from the Unity UI) to do long running processes and check on results (you cannot interact with Unity from the working thread).
The common approach is to use a class which represents a threading job which will be initialized by the Unity main thread. Then you start a worker thread on a function of that class and let it do it's job (Coroutines run on the Unity main thread so are not real threads. Best article on Coroutines is here)
Here's an example of the approach described above (see accepted answer):
http://answers.unity3d.com/questions/357033/unity3d-and-c-coroutines-vs-threading.html
You might also want to try a UnityGems package that achieves the same effect but provides convenience (such as closure support). See this page
HTH.
Best!
From my own personal experience with Unity, you cannot create/run a separate thread unless the thread doesn't use any of Unity's api. So that means no gameObjects or things of similar nature.I've successfully done it myself for my own pathfinding so I know it is possible. Good Luck! I hope this helps.
A commonly used approarch in Unity3D is to use Coroutines.
IEnumerator DoSth()
{
...
yield retrun ... ;
}
To call/Consume the coroutine:
StartCoroutine(DoSth()); // OK
StartCoroutine("DoSth"); // Also fine
StopCoroutine("DoSth"); // You can stop it as well
I know that Actionscript is not multi-threaded. But, I want to address this somehow. I need to make multiple requests to the server while the UI is being rendered (UI renders multiple graphs).
I found this article and I am exploring how to make best of use of this for my situation.
Is there any alternative friends?
1) in flash ALL remote calls (like RemoteObject, URLLoader, HTTPService etc) are asynchronous. So you do not need any multi-threading for server request - UI will not be frozen!
2) In FlashPlayer 11.4 and Air 3.4 multi-treading became possible, but not really used yet in known applications...
See these:
http://helpx.adobe.com/flash-player/release-note/fp_114_air_34_release_notes.html
http://www.bytearray.org/?p=4423
3) also, it is possible to avoid UI freezing for long process operations in flash using delays and calling over timeouts, like in example of asynchronous JPEG encoder:
Fast or asynchronous AS3 JPEG encoding
http://www.switchonthecode.com/tutorials/flex-tutorial-an-asynchronous-jpeg-encoder
http://blog.inspirit.ru/?p=201
In WinForms, pretty much all your UI is thread-specific. You have to use [STAThread] so that the common dialogs will work, and you can't (safely) access a UI element from any thread other than the one that created it. From what I've heard, that's because that's just how Windows works -- window handles are thread-specific.
In WPF, these same restrictions were kept, because ultimately it's still building on top of the same Windows API, still window handles (though mostly just for top-level windows), etc. In fact, WPF even made things more restrictive, because you can't even access things like bitmaps across threads.
Now along comes WinRT, a whole new way of accessing Windows -- a fresh, clean slate. Are we still stuck with the same old threading restrictions (specifically: only being able to manipulate a UI control from the thread that created it), or have they opened this up?
I would expect it to be the same model - but much easier to use, at least from C# and VB, with the new async handling which lets you write a synchronous-looking method which just uses "await" when it needs to wait for a long-running task to complete before proceeding.
Given the emphasis on making asynchronous code easier to write, it would be surprising for MS to forsake the efficiency of requiring single-threaded access to the UI at the same time.
The threading model is identical. There is still a notion of single threaded and multi-threaded apartments (STA/MTA), it must be initialized by a call to RoInitialize. Which behaves very much like CoInitialize in name, argument and error returns. The user interface thread is single threaded, confirmed at 36:00 in this video.
The HTML/CSS UI model is inherently single threaded (until the advent of web workers recently, JS didn't support threads). Xaml is also single threaded (because it's really hard for developers to write code to a multithreaded GUI).
The underlying threading model does have some key differences. When your application starts, an ASTA (Application STA) is created to run your UI code as I showed in the talk. This ASTA does not allow reentrancy - you will not receive unrelated calls while making an outgoing call. This is a significant difference from STAs.
You are allowed to create async workitems - see the Windows.System.Threadpool namespace. These workitem threads are automatically initialized to MTA. As Larry mentioned, webworkers are the JS equivalent concept.
Your UI components are thread affined. See the Windows.UI.Core.CoreDispatcher class for information on how to execute code on the UI thread. You can check out the threading sample for some example code to update the UI from an async operation.
Things are different in pretty important ways.
While it's true the underlying threading model is the same, your question is generally related to how logical concurrency works with UI, and with respect to this what developers see in Windows 8 will be new.
As you mention most dialogs previously blocked. For Metro apps many UI components do not block all. Remember the talk of WinRT being asynchronous? It applies to UI components also.
For example this .NET 4 code will not necessarily kill your harddrive because the UI call blocks on Show (C# example):
bool formatHardDrive = true;
if (MessageBox.Show("Format your harddrive?") == NO)
formatHardDrive = false;
if (formatHardDrive == true)
Format();
With Windows 8 Metro many UI components like Windows.UI.Popups.MessageDialog, are by default Asynchronous so the Show call would immediately (logically) fall through to the next line of code before the user input is retrieved.
Of course there is an elegant solution to this based on the await/promise design patterns (Javascript example):
var md = Windows.UI.Popups.MessageDialog("Hello World!");
md.showAsync().then(function (command) {
console.log("pressed: " + command.label); });
The point is that while the threading model doesn't change, when most people mention UI and threading they are thinking about logical concurrency and how it affects the programming model.
Overall I think the asynchronous paradigm shift is a positive thing. It requires a bit of a shift in perspective, but it's consistent with the way other platforms are evolving on both the client and server sides.
I am trying to implement the Observer design pattern with wxPython.
I have a modelling application that computes vast amount of data in the background. Sometimes I would like to display the output of the model in the GUI---which is just a grid of squares of different colours. Other times I need to do the computation without displaying the GUI.
The advantage of the observer pattern is that you can plug in or not a GUI just by adding or removing one line of code, something like
self.observers.append(MyWxGui())
or similar.
Now, to do that I need my computation to run on one thread, and the wx GUI to run in a different one.
I tried doing this with wxPython but I always get a Fatal I/O error:
python: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
I read tutorials on multithreading in wxPython, such as http://wiki.wxpython.org/LongRunningTasks, but they all have the Mainloop() running in the main thread and than the long running task in a secondary thread, while I need it to be the other way round. This is because if I have the Mainloop() in the main thread, the program hangs waiting for some event from the GUI, instead of proceeding with the computation.
I also saw that I cannot manipulate Device contexts (DCs) such as ClientDC or PaintDC in a sub-thread, but I'm running the entire wx code inside the same thread.
Can the Mainloop() and all the wx GUI be run in its own thread that is not the main application's one?
Running wxPython 2.8.11.0 on Ubuntu 10.10 maverick.
If you read that wiki page, then you should know that you can communicate back to the wx thread using wx.CallAfter, wxCallLater or wx.PostEvent in a thread-safe manner. I have a simple tutorial here:
http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/
Personally, I would use something like Pubsub + one of the threadsafe methods mentioned above to communicate with the wx MainLoop. The nice thing about Pubsub is that it can listen for messages and react to them appropriately. The example above actually shows one way to do just that. Hopefully that will help you. Otherwise, I highly recommend joining the wxPython mailing list and asking there: http://groups.google.com/group/wxpython-users/topics?pli=1