Silverlight threading and Event-based-driven JavaScript engine (for track playback function) _javascript tips

Case background:
The whole function is to remove data from the database, and then play in the interface, simply to say is similar to online watching video, listening to music, but I took the string data, and they take the stream file data. Divided into 10 parts of the overall data, 10 threads at the same time to the database data (concurrent increase speed) in 10 queues, another thread from the queue to take data from the interface to play, you can drag playback progress, stop, pause, replay, control playback speed. Well, the function sounds simple, and it's not hard to do. But some of the problems found later, and digging down these issues, dug up something I thought was worth remembering.
Key things:
1. Siliverlight Background thread BackgroundWorker m_getreplaydata= new BackgroundWorker ();
2. Access interface controls across threads, this. Dispatcher.begininvoke (/Access interface UI);
3. JavaScript function pointers: var showsinglelog = function () {}; (on parent page)
4. The child page registers the parent page the event: var fatharwindow = Window.opener;;
Fatharwindow. Showsinglelog =function () {//Play Data Showtrace ()};
5.javascript engine thread, interface rendering thread, browser event triggering thread;
6. The browser engine is single-threaded, that is, everything is synchronized, there are no two threads running at the same time
The problem lies in:
Through the Silverlight thread loop to call the JS method to achieve the effect of playback interface data, because Silverlight can only call the JS method of this page, but the track playback of the page is the main page pop-up page, so I use the main page of an empty function pointer, The child page registers the event of the parent page to reach the Silverlight invoke sub-page method (the 3rd mentioned above). After my careful scrutiny and argument I am sure there is no problem, after the finish is no problem. Local test is used hundreds of thousands of data, the problem is not, stop, pause, drag progress, the problem is not very small, is the parent page interface a bit card, at first I did not pay attention to this problem. To the test over there is more than 20,000 data playback, play 5 minutes after the second interface card dead, track playback page, stop, drag progress, pause, play button all expired. The phenomenon is very strange, I once thought is the test machine problem, finally discovered is the big data quantity question. This. Dispatcher.begininvoke (/Access UI) This call seems simple, common, but has two features:
1. It is asynchronous, that is, the adjustment is not necessarily immediately executed, the first tune does not necessarily first, need to do synchronous control;
2. This method is to preempt the browser-interface rendering thread, which is mutually exclusive to the JavaScript engine thread.
More than 20,000 data, at first I control the playback speed, so just start no problem, to the back of a lot of data are stuck in this method, resulting in a constant preemption of the browser interface rendering thread, resulting in the main page is very card, until the card dies. Click on the main page, the browser event trigger thread to run, but this time the interface rendering thread running, so very card.
Solution:
This. Dispatcher.begininvoke (/Access UI), it is obvious that this thing caused, then find a workaround. The original data queue was on Silverlight and I changed it to a JavaScript queue. The playback data does not depend on the Silver Ray path, utilizes the Setimeout (this method under the IE6 memory leaks, therefore starts to be repelled by me) to regularly play the data. The result is very beautiful, the page is very smooth, there is no asynchronous problem, do not have to control the synchronization of data playback, but also relatively simple.
Analysis Reason:
Why use Silerlight to play will be very card, but setimeout to broadcast not card, two are continuously played, and Setimeout play, click the page, the page can also respond to events, the problem we want from the event to drive JavaScript engine. The reason for the page card has been said above, the main is to explain the setimeout play why not card. The JavaScript engine in the browser is event-based, and the event can be seen as a variety of tasks that the browser sends to it, from the code blocks currently executing by the JavaScript engine, such as invoking settimeout to add a task, or other threads from the browser kernel , such as interface element mouse Click event, timing trigger time arrival notification, asynchronous request status change notification, etc. from the code point of view the task entity is a variety of callback functions, and the JavaScript engine waits for the task queue to arrive. Because of single-threaded relationships, these tasks have to be queued, One after another is processed by the engine. So when playing the data, the operation interface is added to the task queue, will be implemented, the natural user angle feel the entire page is not card.